| blob | 8956003025d9a7c909347612c042d97ca4789d20 |
4 Internet Engineering Task Force K. Jaganathan
5 Internet-Draft L. Zhu
6 Expires: January 9, 2006 J. Brezak
7 Microsoft Corporation
8 July 8, 2005
11 The RC4-HMAC Kerberos encryption type
12 draft-jaganathan-rc4-hmac-00.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 9, 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 9, 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 . . . . . . . . . . . . . . . . . . . 12
73 8. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 13
74 8.1 Mechanism Specific Changes . . . . . . . . . . . . . . . . 13
75 8.2 GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 14
76 8.3 GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 16
77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
78 10. Normative References . . . . . . . . . . . . . . . . . . . . 20
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
80 Intellectual Property and Copyright Statements . . . . . . . . 22
111 Jaganathan, et al. Expires January 9, 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 9, 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 9, 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 1510. 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 9, 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 9, 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-1964 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 9, 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 9, 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 9, 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 9, 2006 [Page 10]
560 \f
561 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
564 The pseudo-random operation [RFC3961] for both enctypes above is
565 defined as follows:
567 pseudo-random(K, S) = HMAC-SHA1(K, S)
569 where K is the protocol key and S is the input octet string. HMAC-
570 SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20-
571 octet digest.
615 Jaganathan, et al. Expires January 9, 2006 [Page 11]
616 \f
617 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
620 7. Key Strength Negotiation
622 A Kerberos client and server can negotiate over key length if they
623 are using mutual authentication. If the client is unable to perform
624 full strength encryption, it may propose a key in the "subkey" field
625 of the authenticator, using a weaker encryption type. The server
626 must then either return the same key or suggest its own key in the
627 subkey field of the AP reply message. The key used to encrypt data
628 is derived from the key returned by the server. If the client is
629 able to perform strong encryption but the server is not, it may
630 propose a subkey in the AP reply without first being sent a subkey in
631 the authenticator.
671 Jaganathan, et al. Expires January 9, 2006 [Page 12]
672 \f
673 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
676 8. GSSAPI Kerberos V5 Mechanism Type
678 8.1 Mechanism Specific Changes
680 The GSSAPI per-message tokens also require new checksum and
681 encryption types. The GSS-API per-message tokens are adapted to
682 support these new encryption types. See [RFC1964] Section 1.2.2.
684 The only support quality of protection is:
686 #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0
688 When using this RC4 based encryption type, the sequence number is
689 always sent in big-endian rather than little-endian order.
691 The Windows 2000 implementation also defines new GSSAPI flags in the
692 initial token passed when initializing a security context. These
693 flags are passed in the checksum field of the authenticator. See
694 [RFC1964] Section 1.1.1.
696 GSS_C_DCE_STYLE - This flag was added for use with Microsoft's
697 implementation of DCE RPC, which initially expected three legs of
698 authentication. Setting this flag causes an extra AP reply to be
699 sent from the client back to the server after receiving the server's
700 AP reply. In addition, the context negotiation tokens do not have
701 GSSAPI per message tokens - they are raw AP messages that do not
702 include object identifiers.
704 #define GSS_C_DCE_STYLE 0x1000
706 GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
707 server that it should only allow the server application to identify
708 the client by name and ID, but not to impersonate the client.
710 #define GSS_C_IDENTIFY_FLAG 0x2000
712 GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
713 client wants to be informed of extended error information. In
714 particular, Windows 2000 status codes may be returned in the data
715 field of a Kerberos error message. This allows the client to
716 understand a server failure more precisely. In addition, the server
717 may return errors to the client that are normally handled at the
718 application layer in the server, in order to let the client try to
719 recover. After receiving an error message, the client may attempt to
720 resubmit an AP request.
722 #define GSS_C_EXTENDED_ERROR_FLAG 0x4000
727 Jaganathan, et al. Expires January 9, 2006 [Page 13]
728 \f
729 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
732 These flags are only used if a client is aware of these conventions
733 when using the SSPI on the Windows platform; they are not generally
734 used by default.
736 When NetBIOS addresses are used in the GSSAPI, they are identified by
737 the GSS_C_AF_NETBIOS value. This value is defined as:
739 #define GSS_C_AF_NETBIOS 0x14
741 NetBios addresses are 16-octet addresses typically composed of 1 to
742 15 characters, trailing blank (ASCII char 20) filled, with a 16-th
743 octet of 0x0.
745 8.2 GSSAPI MIC Semantics
747 The GSSAPI checksum type and algorithm is defined in Section 5. Only
748 the first 8 octets of the checksum are used. The resulting checksum
749 is stored in the SGN_CKSUM field . See [RFC1964] Section 1.2 for
750 GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
752 The GSS_GetMIC token has the following format:
754 Byte no Name Description
755 0..1 TOK_ID Identification field.
756 Tokens emitted by GSS_GetMIC() contain
757 the hex value 01 01 in this field.
758 2..3 SGN_ALG Integrity algorithm indicator.
759 11 00 - HMAC
760 4..7 Filler Contains ff ff ff ff
761 8..15 SND_SEQ Sequence number field.
762 16..23 SGN_CKSUM Checksum of "to-be-signed data",
763 calculated according to algorithm
764 specified in SGN_ALG field.
766 The MIC mechanism used for GSS MIC based messages is as follow:
768 GetMIC(Kss, direction, export, seq_num, data)
769 {
770 struct Token {
771 struct Header {
772 OCTET TOK_ID[2];
773 OCTET SGN_ALG[2];
774 OCTET Filler[4];
775 };
776 OCTET SND_SEQ[8];
777 OCTET SGN_CKSUM[8];
778 } Token;
783 Jaganathan, et al. Expires January 9, 2006 [Page 14]
784 \f
785 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
788 Token.TOK_ID = 01 01;
789 Token.SGN_SLG = 11 00;
790 Token.Filler = ff ff ff ff;
792 // Create the sequence number
794 if (direction == sender_is_initiator)
795 {
796 memset(Token.SEND_SEQ+4, 0xff, 4)
797 }
798 else if (direction == sender_is_acceptor)
799 {
800 memset(Token.SEND_SEQ+4, 0, 4)
801 }
802 Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
803 Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
804 Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
805 Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
807 // Derive signing key from session key
809 Ksign = HMAC(Kss, "signaturekey");
810 // length includes terminating null
812 // Generate checksum of message - SGN_CKSUM
813 // Key derivation salt = 15
815 Sgn_Cksum = MD5((int32)15, Token.Header, data);
817 // Save first 8 octets of HMAC Sgn_Cksum
819 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
820 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
822 // Encrypt the sequence number
824 // Derive encryption key for the sequence number
825 // Key derivation salt = 0
827 if (exportable)
828 {
829 Kseq = HMAC(Kss, "fortybits", (int32)0);
830 // len includes terminating null
831 memset(Kseq+7, 0xab, 7)
832 }
833 else
834 {
835 Kseq = HMAC(Kss, (int32)0);
839 Jaganathan, et al. Expires January 9, 2006 [Page 15]
840 \f
841 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
844 }
845 Kseq = HMAC(Kseq, Token.SGN_CKSUM);
847 // Encrypt the sequence number
849 RC4(Kseq, Token.SND_SEQ);
850 }
853 8.3 GSSAPI WRAP Semantics
855 There are two encryption keys for GSSAPI message tokens, one that is
856 128 bits in strength, and one that is 56 bits in strength as defined
857 in Section 6.
859 All padding is rounded up to 1 byte. One byte is needed to say that
860 there is 1 byte of padding. The DES based mechanism type uses 8 byte
861 padding. See [RFC1964] Section 1.2.2.3.
863 The RC4-HMAC GSS_Wrap() token has the following format:
866 Byte no Name Description
867 0..1 TOK_ID Identification field.
868 Tokens emitted by GSS_Wrap() contain
869 the hex value 02 01 in this field.
870 2..3 SGN_ALG Checksum algorithm indicator.
871 11 00 - HMAC
872 4..5 SEAL_ALG ff ff - none
873 00 00 - DES-CBC
874 10 00 - RC4
875 6..7 Filler Contains ff ff
876 8..15 SND_SEQ Encrypted sequence number field.
877 16..23 SGN_CKSUM Checksum of plaintext padded data,
878 calculated according to algorithm
879 specified in SGN_ALG field.
880 24..31 Confounder Random confounder
881 32..last Data encrypted or plaintext padded data
883 The encryption mechanism used for GSS wrap based messages is as
884 follow:
887 WRAP(Kss, encrypt, direction, export, seq_num, data)
888 {
889 struct Token { // 32 octets
890 struct Header {
891 OCTET TOK_ID[2];
895 Jaganathan, et al. Expires January 9, 2006 [Page 16]
896 \f
897 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
900 OCTET SGN_ALG[2];
901 OCTET SEAL_ALG[2];
902 OCTET Filler[2];
903 };
904 OCTET SND_SEQ[8];
905 OCTET SGN_CKSUM[8];
906 OCTET Confounder[8];
907 } Token;
910 Token.TOK_ID = 02 01;
911 Token.SGN_SLG = 11 00;
912 Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
913 Token.Filler = ff ff;
915 // Create the sequence number
917 if (direction == sender_is_initiator)
918 {
919 memset(&Token.SEND_SEQ[4], 0xff, 4)
920 }
921 else if (direction == sender_is_acceptor)
922 {
923 memset(&Token.SEND_SEQ[4], 0, 4)
924 }
925 Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
926 Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
927 Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
928 Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
930 // Generate random confounder
932 nonce(&Token.Confounder, 8);
934 // Derive signing key from session key
936 Ksign = HMAC(Kss, "signaturekey");
938 // Generate checksum of message -
939 // SGN_CKSUM + Token.Confounder
940 // Key derivation salt = 15
942 Sgn_Cksum = MD5((int32)15, Token.Header,
943 Token.Confounder);
945 // Derive encryption key for data
946 // Key derivation salt = 0
951 Jaganathan, et al. Expires January 9, 2006 [Page 17]
952 \f
953 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
956 for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
957 // XOR
958 if (exportable)
959 {
960 Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
961 // len includes terminating null
962 memset(Kcrypt+7, 0xab, 7);
963 }
964 else
965 {
966 Kcrypt = HMAC(Klocal, (int32)0);
967 }
969 // new encryption key salted with seq
971 Kcrypt = HMAC(Kcrypt, (int32)seq);
973 // Encrypt confounder (if encrypting)
975 if (encrypt)
976 RC4(Kcrypt, Token.Confounder);
978 // Sum the data buffer
980 Sgn_Cksum += MD5(data); // Append to checksum
982 // Encrypt the data (if encrypting)
984 if (encrypt)
985 RC4(Kcrypt, data);
987 // Save first 8 octets of HMAC Sgn_Cksum
989 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
990 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
992 // Derive encryption key for the sequence number
993 // Key derivation salt = 0
995 if (exportable)
996 {
997 Kseq = HMAC(Kss, "fortybits", (int32)0);
998 // len includes terminating null
999 memset(Kseq+7, 0xab, 7)
1000 }
1001 else
1002 {
1003 Kseq = HMAC(Kss, (int32)0);
1007 Jaganathan, et al. Expires January 9, 2006 [Page 18]
1008 \f
1009 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1012 }
1013 Kseq = HMAC(Kseq, Token.SGN_CKSUM);
1015 // Encrypt the sequence number
1017 RC4(Kseq, Token.SND_SEQ);
1019 // Encrypted message = Token + Data
1020 }
1022 The character constant "fortybits" evolved from the time when a 40-
1023 bit key length was all that was exportable from the United States.
1024 It is now used to recognize that the key length is of "exportable"
1025 length. In this description, the key size is actually 56-bits.
1063 Jaganathan, et al. Expires January 9, 2006 [Page 19]
1064 \f
1065 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1068 9. Security Considerations
1070 Care must be taken in implementing this encryption type because it
1071 uses a stream cipher. If a different IV isn't used in each direction
1072 when using a session key, the encryption is weak. By using the
1073 sequence number as an IV, this is avoided.
1075 10. Normative References
1077 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
1078 April 1992.
1080 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1081 April 1992.
1083 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
1084 Authentication Service (V5)", RFC 1510, September 1993.
1086 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
1087 RFC 1964, June 1996.
1089 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1090 Hashing for Message Authentication", RFC 2104,
1091 February 1997.
1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1094 Requirement Levels", BCP 14, RFC 2119, March 1997.
1096 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1097 Kerberos 5", RFC 3961, February 2005.
1100 Authors' Addresses
1102 Karthik Jaganathan
1103 Microsoft Corporation
1104 One Microsoft Way
1105 Redmond, WA 98052
1106 US
1108 Email: karthikj@microsoft.com
1119 Jaganathan, et al. Expires January 9, 2006 [Page 20]
1120 \f
1121 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1124 Larry Zhu
1125 Microsoft Corporation
1126 One Microsoft Way
1127 Redmond, WA 98052
1128 US
1130 Email: lzhu@microsoft.com
1133 John Brezak
1134 Microsoft Corporation
1135 One Microsoft Way
1136 Redmond, WA 98052
1137 US
1139 Email: jbrezak@microsoft.com
1175 Jaganathan, et al. Expires January 9, 2006 [Page 21]
1176 \f
1177 Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1180 Intellectual Property Statement
1182 The IETF takes no position regarding the validity or scope of any
1183 Intellectual Property Rights or other rights that might be claimed to
1184 pertain to the implementation or use of the technology described in
1185 this document or the extent to which any license under such rights
1186 might or might not be available; nor does it represent that it has
1187 made any independent effort to identify any such rights. Information
1188 on the procedures with respect to rights in RFC documents can be
1189 found in BCP 78 and BCP 79.
1191 Copies of IPR disclosures made to the IETF Secretariat and any
1192 assurances of licenses to be made available, or the result of an
1193 attempt made to obtain a general license or permission for the use of
1194 such proprietary rights by implementers or users of this
1195 specification can be obtained from the IETF on-line IPR repository at
1196 http://www.ietf.org/ipr.
1198 The IETF invites any interested party to bring to its attention any
1199 copyrights, patents or patent applications, or other proprietary
1200 rights that may cover technology that may be required to implement
1201 this standard. Please address the information to the IETF at
1202 ietf-ipr@ietf.org.
1205 Disclaimer of Validity
1207 This document and the information contained herein are provided on an
1208 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1209 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1210 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1211 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1212 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1216 Copyright Statement
1218 Copyright (C) The Internet Society (2005). This document is subject
1219 to the rights, licenses and restrictions contained in BCP 78, and
1220 except as set forth therein, the authors retain all their rights.
1223 Acknowledgment
1225 Funding for the RFC Editor function is currently provided by the
1226 Internet Society.
1231 Jaganathan, et al. Expires January 9, 2006 [Page 22]
1232 \f