| blob | 1550e35deecfdd4f023831f98bedf728015ce0ff |
4 Internet Engineering Task Force K. Jaganathan
5 Internet-Draft L. Zhu
6 Expires: January 19, 2006 J. Brezak
7 Microsoft Corporation
8 July 18, 2005
11 The RC4-HMAC Kerberos encryption type
12 draft-jaganathan-rc4-hmac-01.txt
14 Status of this Memo
16 By submitting this Internet-Draft, each author represents that any
17 applicable patent or other IPR claims of which he or she is aware
18 have been or will be disclosed, and any of which he or she becomes
19 aware will be disclosed, in accordance with Section 6 of BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on January 19, 2006.
39 Copyright Notice
41 Copyright (C) The Internet Society (2005).
43 Abstract
45 The Microsoft Windows 2000 implementation of Kerberos introduces a
46 new encryption type based on the RC4 encryption algorithm and using
47 an MD5 HMAC for checksum. This is offered as an alternative to using
48 the existing DES based encryption types.
50 The RC4-HMAC encryption types are used to ease upgrade of existing
51 Windows NT environments, provide strong crypto (128-bit key lengths),
55 Jaganathan, et al. Expires January 19, 2006 [Page 1]
56 \f
57 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
60 and provide exportable (meet United States government export
61 restriction requirements) encryption. This document describes the
62 implementation of those encryption types
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
68 3. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 5
69 4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 6
70 5. Checksum Types . . . . . . . . . . . . . . . . . . . . . . . . 8
71 6. Encryption Types . . . . . . . . . . . . . . . . . . . . . . . 9
72 7. Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 11
73 8. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 12
74 8.1 Mechanism Specific Changes . . . . . . . . . . . . . . . . 12
75 8.2 GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 13
76 8.3 GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 15
77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
78 10. Normative References . . . . . . . . . . . . . . . . . . . . 19
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
80 Intellectual Property and Copyright Statements . . . . . . . . 21
111 Jaganathan, et al. Expires January 19, 2006 [Page 2]
112 \f
113 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
116 1. Introduction
118 The Microsoft Windows 2000 implementation of Kerberos contains new
119 encryption and checksum types for two reasons: for export reasons
120 early in the development process, 56 bit DES encryption could not be
121 exported, and because upon upgrade from Windows NT 4.0 to Windows
122 2000, accounts will not have the appropriate DES keying material to
123 do the standard DES encryption. Furthermore, 3DES is not available
124 for export, and there was a desire to use a single flavor of
125 encryption in the product for both US and international products.
127 As a result, there are two new encryption types and one new checksum
128 type introduced in Microsoft Windows 2000.
167 Jaganathan, et al. Expires January 19, 2006 [Page 3]
168 \f
169 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
172 2. Conventions Used in This Document
174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
176 document are to be interpreted as described in [RFC2119].
223 Jaganathan, et al. Expires January 19, 2006 [Page 4]
224 \f
225 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
228 3. Key Generation
230 On upgrade from existing Windows NT domains, the user accounts would
231 not have a DES based key available to enable the use of DES base
232 encryption types specified in RFC 4120. The key used for RC4-HMAC is
233 the same as the existing Windows NT key (NT Password Hash) for
234 compatibility reasons. Once the account password is changed, the DES
235 based keys are created and maintained. Once the DES keys are
236 available DES based encryption types can be used with Kerberos.
238 The RC4-HMAC String to key function is defined as follow:
240 String2Key(password)
242 K = MD4(UNICODE(password))
244 The RC4-HMAC keys are generated by using the Windows UNICODE version
245 of the password. Each Windows UNICODE character is encoded in
246 little-endian format of 2 octets each. Then performing an MD4
247 [RFC1320] hash operation on just the UNICODE characters of the
248 password (not including the terminating zero octets).
250 For an account with a password of "foo", this String2Key("foo") will
251 return:
253 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
254 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
279 Jaganathan, et al. Expires January 19, 2006 [Page 5]
280 \f
281 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
284 4. Basic Operations
286 The MD5 HMAC function is defined in [RFC2104]. It is used in this
287 encryption type for checksum operations. Refer to[RFC2104]for
288 details on its operation. In this document this function is referred
289 to as HMAC(Key, Data) returning the checksum using the specified key
290 on the data.
292 The basic MD5 hash operation is used in this encryption type and
293 defined in [RFC1321]. In this document this function is referred to
294 as MD5(Data) returning the checksum of the data.
296 RC4 is a stream cipher licensed by RSA Data Security . In this
297 document the function is referred to as RC4(Key, Data) returning the
298 encrypted data using the specified key on the data.
300 These encryption types use key derivation. With each message, the
301 message type (T) is used as a component of the keying material. This
302 table summarizes the different key derivation values used in the
303 various operations. Note that these differ from the key derivations
304 used in other Kerberos encryption types. T = the message type,
305 encoded as a little-endian four byte integer.
335 Jaganathan, et al. Expires January 19, 2006 [Page 6]
336 \f
337 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
340 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
341 the client key (T=1)
342 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key
343 or application session key), encrypted with the service key
344 (T=2)
345 3. AS-REP encrypted part (includes TGS session key or
346 application session key), encrypted with the client key (T=8)
347 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
348 TGS session key (T=4)
349 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
350 TGS authenticator subkey (T=5)
351 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
352 keyed with the TGS session key (T=6)
353 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
354 TGS authenticator subkey), encrypted with the TGS session key
355 T=7)
356 8. TGS-REP encrypted part (includes application session key),
357 encrypted with the TGS session key (T=8)
358 9. TGS-REP encrypted part (includes application session key),
359 encrypted with the TGS authenticator subkey (T=8)
360 10. AP-REQ Authenticator cksum, keyed with the application
361 session key (T=10)
362 11. AP-REQ Authenticator (includes application authenticator
363 subkey), encrypted with the application session key (T=11)
364 12. AP-REP encrypted part (includes application session
365 subkey), encrypted with the application session key (T=12)
366 13. KRB-PRIV encrypted part, encrypted with a key chosen by
367 the application. Also for data encrypted with GSS Wrap (T=13)
368 14. KRB-CRED encrypted part, encrypted with a key chosen by
369 the application (T=14)
370 15. KRB-SAFE cksum, keyed with a key chosen by the
371 application. Also for data signed in GSS MIC (T=15)
373 Relative to RFC-4121 key uses:
375 T = 0 in the generation of sequence number for the MIC token
376 T = 0 in the generation of sequence number for the WRAP token
377 T = 0 in the generation of encrypted data for the WRAPPED token
379 All strings in this document are ASCII unless otherwise specified.
380 The lengths of ASCII encoded character strings include the trailing
381 terminator character (0). The concat(a,b,c,...) function will return
382 the logical concatenation (left to right) of the values of the
383 arguments. The nonce(n) function returns a pseudo-random number of
384 "n" octets.
391 Jaganathan, et al. Expires January 19, 2006 [Page 7]
392 \f
393 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
396 5. Checksum Types
398 There is one checksum type used in this encryption type. The
399 Kerberos constant for this type is:
401 #define KERB_CHECKSUM_HMAC_MD5 (-138)
403 The function is defined as follows:
405 K - is the Key
406 T - the message type, encoded as a little-endian four byte integer
408 CHKSUM(K, T, data)
410 Ksign = HMAC(K, "signaturekey") //includes zero octet at end
411 tmp = MD5(concat(T, data))
412 CHKSUM = HMAC(Ksign, tmp)
447 Jaganathan, et al. Expires January 19, 2006 [Page 8]
448 \f
449 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
452 6. Encryption Types
454 There are two encryption types used in these encryption types. The
455 Kerberos constants for these types are:
457 #define KERB_ETYPE_RC4_HMAC 23
458 #define KERB_ETYPE_RC4_HMAC_EXP 24
460 The basic encryption function is defined as follow:
462 T = the message type, encoded as a little-endian four byte integer.
464 OCTET L40[14] = "fortybits";
465 OCTET SK = "signaturekey";
467 The header field on the encrypted data in KDC messages is:
469 typedef struct _RC4_MDx_HEADER {
470 OCTET Checksum[16];
471 OCTET Confounder[8];
472 } RC4_MDx_HEADER, *PRC4_MDx_HEADER;
475 ENCRYPT (K, export, T, data)
476 {
477 struct EDATA {
478 struct HEADER {
479 OCTET Checksum[16];
480 OCTET Confounder[8];
481 } Header;
482 OCTET Data[0];
483 } edata;
485 if (export){
486 *((DWORD *)(L40+10)) = T;
487 HMAC (K, L40, 10 + 4, K1);
488 }
489 else
490 {
491 HMAC (K, "&"T, 4, K1);
492 }
493 memcpy (K2, K1, 16);
494 if (export) memset (K1+7, 0xAB, 9);
496 nonce (edata.Confounder, 8);
497 memcpy (edata.Data, data);
499 edata.Checksum = HMAC (K2, edata);
503 Jaganathan, et al. Expires January 19, 2006 [Page 9]
504 \f
505 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
508 K3 = HMAC (K1, edata.Checksum);
510 RC4 (K3, edata.Confounder);
511 RC4 (K3, data.Data);
512 }
514 DECRYPT (K, export, T, edata)
515 {
516 // edata looks like
517 struct EDATA {
518 struct HEADER {
519 OCTET Checksum[16];
520 OCTET Confounder[8];
521 } Header;
522 OCTET Data[0];
523 } edata;
525 if (export){
526 *((DWORD *)(L40+10)) = T;
527 HMAC (K, L40, 14, K1);
528 }
529 else
530 {
531 HMAC (K, "&"T, 4, K1);
532 }
533 memcpy (K2, K1, 16);
534 if (export) memset (K1+7, 0xAB, 9);
536 K3 = HMAC (K1, edata.Checksum);
538 RC4 (K3, edata.Confounder);
539 RC4 (K3, edata.Data);
542 // verify generated and received checksums
543 checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
544 if (checksum != edata.Checksum)
545 printf("CHECKSUM ERROR !!!!!!\n");
546 }
548 The KDC message is encrypted using the ENCRYPT function not including
549 the Checksum in the RC4_MDx_HEADER.
551 The character constant "fortybits" evolved from the time when a 40-
552 bit key length was all that was exportable from the United States.
553 It is now used to recognize that the key length is of "exportable"
554 length. In this description, the key size is actually 56-bits.
559 Jaganathan, et al. Expires January 19, 2006 [Page 10]
560 \f
561 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
564 7. Key Strength Negotiation
566 TA Kerberos client and server can negotiate over key length if they
567 are using mutual authentication. If the client is unable to perform
568 full strength encryption, it may propose a key in the "subkey" field
569 of the authenticator, using a weaker encryption type. The server
570 must then either return the same key or suggest its own key in the
571 subkey field of the AP reply message. The key used to encrypt data
572 is derived from the key returned by the server. If the client is
573 able to perform strong encryption but the server is not, it may
574 propose a subkey in the AP reply without first being sent a subkey in
575 the authenticator.
615 Jaganathan, et al. Expires January 19, 2006 [Page 11]
616 \f
617 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
620 8. GSSAPI Kerberos V5 Mechanism Type
622 8.1 Mechanism Specific Changes
624 The GSSAPI per-message tokens also require new checksum and
625 encryption types. The GSS-API per-message tokens are adapted to
626 support these new encryption types . See [RFC4121] .
628 The only support quality of protection is:
630 #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0
632 When using this RC4 based encryption type, the sequence number is
633 always sent in big-endian rather than little-endian order.
635 The Windows 2000 implementation also defines new GSSAPI flags in the
636 initial token passed when initializing a security context. These
637 flags are passed in the checksum field of the authenticator. See
638 [RFC4121] .
640 GSS_C_DCE_STYLE - This flag was added for use with Microsoft's
641 implementation of DCE RPC, which initially expected three legs of
642 authentication. Setting this flag causes an extra AP reply to be
643 sent from the client back to the server after receiving the serverAEs
644 AP reply. In addition, the context negotiation tokens do not have
645 GSSAPI per message tokens - they are raw AP messages that do not
646 include object identifiers.
648 #define GSS_C_DCE_STYLE 0x1000
650 GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
651 server that it should only allow the server application to identify
652 the client by name and ID, but not to impersonate the client.
654 #define GSS_C_IDENTIFY_FLAG 0x2000
656 GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
657 client wants to be informed of extended error information. In
658 particular, Windows 2000 status codes may be returned in the data
659 field of a Kerberos error message. This allows the client to
660 understand a server failure more precisely. In addition, the server
661 may return errors to the client that are normally handled at the
662 application layer in the server, in order to let the client try to
663 recover. After receiving an error message, the client may attempt to
664 resubmit an AP request.
666 #define GSS_C_EXTENDED_ERROR_FLAG 0x4000
671 Jaganathan, et al. Expires January 19, 2006 [Page 12]
672 \f
673 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
676 These flags are only used if a client is aware of these conventions
677 when using the SSPI on the Windows platform; they are not generally
678 used by default.
680 When NetBIOS addresses are used in the GSSAPI, they are identified by
681 the GSS_C_AF_NETBIOS value. This value is defined as:
683 #define GSS_C_AF_NETBIOS 0x14
685 NetBios addresses are 16-octet addresses typically composed of 1 to
686 15 characters, trailing blank (ASCII char 20) filled, with a 16-th
687 octet of 0x0.
689 8.2 GSSAPI MIC Semantics
691 The GSSAPI checksum type and algorithm is defined in Section 5. Only
692 the first 8 octets of the checksum are used. The resulting checksum
693 is stored in the SGN_CKSUM field . See [RFC4121] for GSS_GetMIC()
694 and GSS_Wrap(conf_flag=FALSE).
696 The GSS_GetMIC token has the following format:
698 Byte no Name Description
699 0..1 TOK_ID Identification field.
700 Tokens emitted by GSS_GetMIC() contain
701 the hex value 01 01 in this field.
702 2..3 SGN_ALG Integrity algorithm indicator.
703 11 00 - HMAC
704 4..7 Filler Contains ff ff ff ff
705 8..15 SND_SEQ Sequence number field.
706 6..23 SGN_CKSUM Checksum of "to-be-signed data",
707 calculated according to algorithm
708 specified in SGN_ALG field.
710 The MIC mechanism used for GSS MIC based messages is as follow:
712 GetMIC(Kss, direction, export, seq_num, data)
713 {
714 struct Token {
715 struct Header {
716 OCTET TOK_ID[2];
717 OCTET SGN_ALG[2];
718 OCTET Filler[4];
719 };
720 OCTET SND_SEQ[8];
721 OCTET SGN_CKSUM[8];
722 } Token;
727 Jaganathan, et al. Expires January 19, 2006 [Page 13]
728 \f
729 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
732 Token.TOK_ID = 01 01;
733 Token.SGN_SLG = 11 00;
734 Token.Filler = ff ff ff ff;
736 // Create the sequence number
738 if (direction == sender_is_initiator)
739 {
740 memset(Token.SEND_SEQ+4, 0xff, 4)
741 }
742 else if (direction == sender_is_acceptor)
743 {
744 memset(Token.SEND_SEQ+4, 0, 4)
745 }
746 Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24;
747 Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16;
748 Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8;
749 Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff);
751 // Derive signing key from session key
753 Ksign = HMAC(Kss, "signaturekey");
754 // length includes terminating null
756 // Generate checksum of message - SGN_CKSUM
757 // Key derivation salt = 15
759 Sgn_Cksum = MD5((int32)15, Token.Header, data);
761 // Save first 8 octets of HMAC Sgn_Cksum
763 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
764 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
766 // Encrypt the sequence number
768 // Derive encryption key for the sequence number
769 // Key derivation salt = 0
771 if (exportable)
772 {
773 Kseq = HMAC(Kss, "fortybits", (int32)0);
774 // len includes terminating null
775 memset(Kseq+7, 0xab, 7)
776 }
777 else
778 {
779 Kseq = HMAC(Kss, (int32)0);
783 Jaganathan, et al. Expires January 19, 2006 [Page 14]
784 \f
785 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
788 }
789 Kseq = HMAC(Kseq, Token.SGN_CKSUM);
791 // Encrypt the sequence number
793 RC4(Kseq, Token.SND_SEQ);
794 }
797 8.3 GSSAPI WRAP Semantics
799 There are two encryption keys for GSSAPI message tokens, one that is
800 128 bits in strength, and one that is 56 bits in strength as defined
801 in Section 6.
803 All padding is rounded up to 1 byte. One byte is needed to say that
804 there is 1 byte of padding. The DES based mechanism type uses 8 byte
805 padding. See [RFC4121] .
807 The RC4-HMAC GSS_Wrap() token has the following format:
810 Byte no Name Description
811 0..1 TOK_ID Identification field.
812 Tokens emitted by GSS_Wrap() contain
813 the hex value 02 01 in this field.
814 2..3 SGN_ALG Checksum algorithm indicator.
815 11 00 - HMAC
816 4..5 SEAL_ALG ff ff - none
817 00 00 - DES-CBC
818 10 00 - RC4
819 6..7 Filler Contains ff ff
820 8..15 SND_SEQ Encrypted sequence number field.
821 16..23 SGN_CKSUM Checksum of plaintext padded data,
822 calculated according to algorithm
823 specified in SGN_ALG field.
824 24..31 Confounder Random confounder
825 32..last Data encrypted or plaintext padded data
827 The encryption mechanism used for GSS wrap based messages is as
828 follow:
831 WRAP(Kss, encrypt, direction, export, seq_num, data)
832 {
833 struct Token { // 32 octets
834 struct Header {
835 OCTET TOK_ID[2];
839 Jaganathan, et al. Expires January 19, 2006 [Page 15]
840 \f
841 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
844 OCTET SGN_ALG[2];
845 OCTET SEAL_ALG[2];
846 OCTET Filler[2];
847 };
848 OCTET SND_SEQ[8];
849 OCTET SGN_CKSUM[8];
850 OCTET Confounder[8];
851 } Token;
854 Token.TOK_ID = 02 01;
855 Token.SGN_SLG = 11 00;
856 Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
857 Token.Filler = ff ff;
859 // Create the sequence number
861 if (direction == sender_is_initiator)
862 {
863 memset("&"Token.SEND_SEQ[4], 0xff, 4)
864 }
865 else if (direction == sender_is_acceptor)
866 {
867 memset("&"Token.SEND_SEQ[4], 0, 4)
868 }
869 Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24;
870 Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16;
871 Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8;
872 Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff);
874 // Generate random confounder
876 nonce("&"Token.Confounder, 8);
878 // Derive signing key from session key
880 Ksign = HMAC(Kss, "signaturekey");
882 // Generate checksum of message -
883 // SGN_CKSUM + Token.Confounder
884 // Key derivation salt = 15
886 Sgn_Cksum = MD5((int32)15, Token.Header,
887 Token.Confounder);
889 // Derive encryption key for data
890 // Key derivation salt = 0
895 Jaganathan, et al. Expires January 19, 2006 [Page 16]
896 \f
897 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
900 for (i = 0; i "<" 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
901 // XOR
902 if (exportable)
903 {
904 Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
905 // len includes terminating null
906 memset(Kcrypt+7, 0xab, 7);
907 }
908 else
909 {
910 Kcrypt = HMAC(Klocal, (int32)0);
911 }
913 // new encryption key salted with seq
915 Kcrypt = HMAC(Kcrypt, (int32)seq);
917 // Encrypt confounder (if encrypting)
919 if (encrypt)
920 RC4(Kcrypt, Token.Confounder);
922 // Sum the data buffer
924 Sgn_Cksum += MD5(data); // Append to checksum
926 // Encrypt the data (if encrypting)
928 if (encrypt)
929 RC4(Kcrypt, data);
931 // Save first 8 octets of HMAC Sgn_Cksum
933 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
934 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
936 // Derive encryption key for the sequence number
937 // Key derivation salt = 0
939 if (exportable)
940 {
941 Kseq = HMAC(Kss, "fortybits", (int32)0);
942 // len includes terminating null
943 memset(Kseq+7, 0xab, 7)
944 }
945 else
946 {
947 Kseq = HMAC(Kss, (int32)0);
951 Jaganathan, et al. Expires January 19, 2006 [Page 17]
952 \f
953 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
956 }
957 Kseq = HMAC(Kseq, Token.SGN_CKSUM);
959 // Encrypt the sequence number
961 RC4(Kseq, Token.SND_SEQ);
963 // Encrypted message = Token + Data
964 }
966 The character constant "fortybits" evolved from the time when a 40-
967 bit key length was all that was exportable from the United States.
968 It is now used to recognize that the key length is of "exportable"
969 length. In this description, the key size is actually 56-bits.
1007 Jaganathan, et al. Expires January 19, 2006 [Page 18]
1008 \f
1009 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1012 9. Security Considerations
1014 Care must be taken in implementing this encryption type because it
1015 uses a stream cipher. If a different IV isn't used in each direction
1016 when using a session key, the encryption is weak. By using the
1017 sequence number as an IV, this is avoided. The Windows
1018 implementation of Kerberos uses a minimum RC4 key strength of 128
1019 bits. A discussion of the security considerations when using HMACs
1020 is present in [RFC2104] .
1022 10. Normative References
1024 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
1025 April 1992.
1027 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1028 April 1992.
1030 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1031 Hashing for Message Authentication", RFC 2104,
1032 February 1997.
1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1035 Requirement Levels", BCP 14, RFC 2119, March 1997.
1037 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1038 Kerberos Network Authentication Service (V5)", RFC 4120,
1039 July 2005.
1041 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1042 Version 5 Generic Security Service Application Program
1043 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
1044 July 2005.
1047 Authors' Addresses
1049 Karthik Jaganathan
1050 Microsoft Corporation
1051 One Microsoft Way
1052 Redmond, WA 98052
1053 US
1055 Email: karthikj@microsoft.com
1063 Jaganathan, et al. Expires January 19, 2006 [Page 19]
1064 \f
1065 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1068 Larry Zhu
1069 Microsoft Corporation
1070 One Microsoft Way
1071 Redmond, WA 98052
1072 US
1074 Email: lzhu@microsoft.com
1077 John Brezak
1078 Microsoft Corporation
1079 One Microsoft Way
1080 Redmond, WA 98052
1081 US
1083 Email: jbrezak@microsoft.com
1119 Jaganathan, et al. Expires January 19, 2006 [Page 20]
1120 \f
1121 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1124 Intellectual Property Statement
1126 The IETF takes no position regarding the validity or scope of any
1127 Intellectual Property Rights or other rights that might be claimed to
1128 pertain to the implementation or use of the technology described in
1129 this document or the extent to which any license under such rights
1130 might or might not be available; nor does it represent that it has
1131 made any independent effort to identify any such rights. Information
1132 on the procedures with respect to rights in RFC documents can be
1133 found in BCP 78 and BCP 79.
1135 Copies of IPR disclosures made to the IETF Secretariat and any
1136 assurances of licenses to be made available, or the result of an
1137 attempt made to obtain a general license or permission for the use of
1138 such proprietary rights by implementers or users of this
1139 specification can be obtained from the IETF on-line IPR repository at
1140 http://www.ietf.org/ipr.
1142 The IETF invites any interested party to bring to its attention any
1143 copyrights, patents or patent applications, or other proprietary
1144 rights that may cover technology that may be required to implement
1145 this standard. Please address the information to the IETF at
1146 ietf-ipr@ietf.org.
1149 Disclaimer of Validity
1151 This document and the information contained herein are provided on an
1152 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1153 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1154 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1155 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1156 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1157 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1160 Copyright Statement
1162 Copyright (C) The Internet Society (2005). This document is subject
1163 to the rights, licenses and restrictions contained in BCP 78, and
1164 except as set forth therein, the authors retain all their rights.
1167 Acknowledgment
1169 Funding for the RFC Editor function is currently provided by the
1170 Internet Society.
1175 Jaganathan, et al. Expires January 19, 2006 [Page 21]
1176 \f