X-Git-Url: http://git.samba.org/?p=samba.git;a=blobdiff_plain;f=source4%2Fheimdal%2Fdoc%2Fstandardisation%2Fdraft-jaganathan-rc4-hmac-00.txt;fp=source4%2Fheimdal%2Fdoc%2Fstandardisation%2Fdraft-jaganathan-rc4-hmac-00.txt;h=8956003025d9a7c909347612c042d97ca4789d20;hp=0000000000000000000000000000000000000000;hb=40b65c840e03bd5eb7f3b02fe80144650c63c005;hpb=d2a3016a9c59f93f89cf4bb86d40938d56400453 diff --git a/source4/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt b/source4/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt new file mode 100644 index 00000000000..8956003025d --- /dev/null +++ b/source4/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt @@ -0,0 +1,1233 @@ + + + +Internet Engineering Task Force K. Jaganathan +Internet-Draft L. Zhu +Expires: January 9, 2006 J. Brezak + Microsoft Corporation + July 8, 2005 + + + The RC4-HMAC Kerberos encryption type + draft-jaganathan-rc4-hmac-00.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 9, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The Microsoft Windows 2000 implementation of Kerberos introduces a + new encryption type based on the RC4 encryption algorithm and using + an MD5 HMAC for checksum. This is offered as an alternative to using + the existing DES based encryption types. + + The RC4-HMAC encryption types are used to ease upgrade of existing + Windows NT environments, provide strong crypto (128-bit key lengths), + + + +Jaganathan, et al. Expires January 9, 2006 [Page 1] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + and provide exportable (meet United States government export + restriction requirements) encryption. This document describes the + implementation of those encryption types. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 + 3. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Checksum Types . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Encryption Types . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 12 + 8. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 13 + 8.1 Mechanism Specific Changes . . . . . . . . . . . . . . . . 13 + 8.2 GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 14 + 8.3 GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 16 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 10. Normative References . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . 22 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 2] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +1. Introduction + + The Microsoft Windows 2000 implementation of Kerberos contains new + encryption and checksum types for two reasons: for export reasons + early in the development process, 56 bit DES encryption could not be + exported, and because upon upgrade from Windows NT 4.0 to Windows + 2000, accounts will not have the appropriate DES keying material to + do the standard DES encryption. Furthermore, 3DES is not available + for export, and there was a desire to use a single flavor of + encryption in the product for both US and international products. + + As a result, there are two new encryption types and one new checksum + type introduced in Microsoft Windows 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 3] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 4] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +3. Key Generation + + On upgrade from existing Windows NT domains, the user accounts would + not have a DES based key available to enable the use of DES base + encryption types specified in RFC 1510. The key used for RC4-HMAC is + the same as the existing Windows NT key (NT Password Hash) for + compatibility reasons. Once the account password is changed, the DES + based keys are created and maintained. Once the DES keys are + available DES based encryption types can be used with Kerberos. + + The RC4-HMAC String to key function is defined as follow: + + String2Key(password) + + K = MD4(UNICODE(password)) + + The RC4-HMAC keys are generated by using the Windows UNICODE version + of the password. Each Windows UNICODE character is encoded in + little-endian format of 2 octets each. Then performing an MD4 + [RFC1320] hash operation on just the UNICODE characters of the + password (not including the terminating zero octets). + + For an account with a password of "foo", this String2Key("foo") will + return: + + 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, + 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 5] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +4. Basic Operations + + The MD5 HMAC function is defined in [RFC2104]. It is used in this + encryption type for checksum operations. Refer to [RFC2104] for + details on its operation. In this document this function is referred + to as HMAC(Key, Data) returning the checksum using the specified key + on the data. + + The basic MD5 hash operation is used in this encryption type and + defined in [RFC1321]. In this document this function is referred to + as MD5(Data) returning the checksum of the data. + + RC4 is a stream cipher licensed by RSA Data Security . In this + document the function is referred to as RC4(Key, Data) returning the + encrypted data using the specified key on the data. + + These encryption types use key derivation. With each message, the + message type (T) is used as a component of the keying material. This + table summarizes the different key derivation values used in the + various operations. Note that these differ from the key derivations + used in other Kerberos encryption types. T = the message type, + encoded as a little-endian four byte integer. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 6] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with + the client key (T=1) + 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key + or application session key), encrypted with the service key + (T=2) + 3. AS-REP encrypted part (includes TGS session key or + application session key), encrypted with the client key (T=8) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the + TGS session key (T=4) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the + TGS authenticator subkey (T=5) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, + keyed with the TGS session key (T=6) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes + TGS authenticator subkey), encrypted with the TGS session key + T=7) + 8. TGS-REP encrypted part (includes application session key), + encrypted with the TGS session key (T=8) + 9. TGS-REP encrypted part (includes application session key), + encrypted with the TGS authenticator subkey (T=8) + 10. AP-REQ Authenticator cksum, keyed with the application + session key (T=10) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (T=11) + 12. AP-REP encrypted part (includes application session + subkey), encrypted with the application session key (T=12) + 13. KRB-PRIV encrypted part, encrypted with a key chosen by + the application. Also for data encrypted with GSS Wrap (T=13) + 14. KRB-CRED encrypted part, encrypted with a key chosen by + the application (T=14) + 15. KRB-SAFE cksum, keyed with a key chosen by the + application. Also for data signed in GSS MIC (T=15) + + Relative to RFC-1964 key uses: + + T = 0 in the generation of sequence number for the MIC token + T = 0 in the generation of sequence number for the WRAP token + T = 0 in the generation of encrypted data for the WRAPPED token + + All strings in this document are ASCII unless otherwise specified. + The lengths of ASCII encoded character strings include the trailing + terminator character (0). The concat(a,b,c,...) function will return + the logical concatenation (left to right) of the values of the + arguments. The nonce(n) function returns a pseudo-random number of + "n" octets. + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 7] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +5. Checksum Types + + There is one checksum type used in this encryption type. The + Kerberos constant for this type is: + + #define KERB_CHECKSUM_HMAC_MD5 (-138) + + The function is defined as follows: + + K - is the Key + T - the message type, encoded as a little-endian four byte integer + + CHKSUM(K, T, data) + + Ksign = HMAC(K, "signaturekey") //includes zero octet at end + tmp = MD5(concat(T, data)) + CHKSUM = HMAC(Ksign, tmp) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 8] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +6. Encryption Types + + There are two encryption types used in these encryption types. The + Kerberos constants for these types are: + + #define KERB_ETYPE_RC4_HMAC 23 + #define KERB_ETYPE_RC4_HMAC_EXP 24 + + The basic encryption function is defined as follow: + + T = the message type, encoded as a little-endian four byte integer. + + OCTET L40[14] = "fortybits"; + OCTET SK = "signaturekey"; + + The header field on the encrypted data in KDC messages is: + + typedef struct _RC4_MDx_HEADER { + OCTET Checksum[16]; + OCTET Confounder[8]; + } RC4_MDx_HEADER, *PRC4_MDx_HEADER; + + + ENCRYPT (K, export, T, data) + { + struct EDATA { + struct HEADER { + OCTET Checksum[16]; + OCTET Confounder[8]; + } Header; + OCTET Data[0]; + } edata; + + if (export){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 10 + 4, K1); + } + else + { + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (export) memset (K1+7, 0xAB, 9); + + nonce (edata.Confounder, 8); + memcpy (edata.Data, data); + + edata.Checksum = HMAC (K2, edata); + + + +Jaganathan, et al. Expires January 9, 2006 [Page 9] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + K3 = HMAC (K1, edata.Checksum); + + RC4 (K3, edata.Confounder); + RC4 (K3, data.Data); + } + + DECRYPT (K, export, T, edata) + { + // edata looks like + struct EDATA { + struct HEADER { + OCTET Checksum[16]; + OCTET Confounder[8]; + } Header; + OCTET Data[0]; + } edata; + + if (export){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K1); + } + else + { + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (export) memset (K1+7, 0xAB, 9); + + K3 = HMAC (K1, edata.Checksum); + + RC4 (K3, edata.Confounder); + RC4 (K3, edata.Data); + + + // verify generated and received checksums + checksum = HMAC (K2, concat(edata.Confounder, edata.Data)); + if (checksum != edata.Checksum) + printf("CHECKSUM ERROR !!!!!!\n"); + } + + The KDC message is encrypted using the ENCRYPT function not including + the Checksum in the RC4_MDx_HEADER. + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 10] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + The pseudo-random operation [RFC3961] for both enctypes above is + defined as follows: + + pseudo-random(K, S) = HMAC-SHA1(K, S) + + where K is the protocol key and S is the input octet string. HMAC- + SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20- + octet digest. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 11] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +7. Key Strength Negotiation + + A Kerberos client and server can negotiate over key length if they + are using mutual authentication. If the client is unable to perform + full strength encryption, it may propose a key in the "subkey" field + of the authenticator, using a weaker encryption type. The server + must then either return the same key or suggest its own key in the + subkey field of the AP reply message. The key used to encrypt data + is derived from the key returned by the server. If the client is + able to perform strong encryption but the server is not, it may + propose a subkey in the AP reply without first being sent a subkey in + the authenticator. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 12] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +8. GSSAPI Kerberos V5 Mechanism Type + +8.1 Mechanism Specific Changes + + The GSSAPI per-message tokens also require new checksum and + encryption types. The GSS-API per-message tokens are adapted to + support these new encryption types. See [RFC1964] Section 1.2.2. + + The only support quality of protection is: + + #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 + + When using this RC4 based encryption type, the sequence number is + always sent in big-endian rather than little-endian order. + + The Windows 2000 implementation also defines new GSSAPI flags in the + initial token passed when initializing a security context. These + flags are passed in the checksum field of the authenticator. See + [RFC1964] Section 1.1.1. + + GSS_C_DCE_STYLE - This flag was added for use with Microsoft's + implementation of DCE RPC, which initially expected three legs of + authentication. Setting this flag causes an extra AP reply to be + sent from the client back to the server after receiving the server's + AP reply. In addition, the context negotiation tokens do not have + GSSAPI per message tokens - they are raw AP messages that do not + include object identifiers. + + #define GSS_C_DCE_STYLE 0x1000 + + GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the + server that it should only allow the server application to identify + the client by name and ID, but not to impersonate the client. + + #define GSS_C_IDENTIFY_FLAG 0x2000 + + GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the + client wants to be informed of extended error information. In + particular, Windows 2000 status codes may be returned in the data + field of a Kerberos error message. This allows the client to + understand a server failure more precisely. In addition, the server + may return errors to the client that are normally handled at the + application layer in the server, in order to let the client try to + recover. After receiving an error message, the client may attempt to + resubmit an AP request. + + #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 13] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + These flags are only used if a client is aware of these conventions + when using the SSPI on the Windows platform; they are not generally + used by default. + + When NetBIOS addresses are used in the GSSAPI, they are identified by + the GSS_C_AF_NETBIOS value. This value is defined as: + + #define GSS_C_AF_NETBIOS 0x14 + + NetBios addresses are 16-octet addresses typically composed of 1 to + 15 characters, trailing blank (ASCII char 20) filled, with a 16-th + octet of 0x0. + +8.2 GSSAPI MIC Semantics + + The GSSAPI checksum type and algorithm is defined in Section 5. Only + the first 8 octets of the checksum are used. The resulting checksum + is stored in the SGN_CKSUM field . See [RFC1964] Section 1.2 for + GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). + + The GSS_GetMIC token has the following format: + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_GetMIC() contain + the hex value 01 01 in this field. + 2..3 SGN_ALG Integrity algorithm indicator. + 11 00 - HMAC + 4..7 Filler Contains ff ff ff ff + 8..15 SND_SEQ Sequence number field. + 16..23 SGN_CKSUM Checksum of "to-be-signed data", + calculated according to algorithm + specified in SGN_ALG field. + + The MIC mechanism used for GSS MIC based messages is as follow: + + GetMIC(Kss, direction, export, seq_num, data) + { + struct Token { + struct Header { + OCTET TOK_ID[2]; + OCTET SGN_ALG[2]; + OCTET Filler[4]; + }; + OCTET SND_SEQ[8]; + OCTET SGN_CKSUM[8]; + } Token; + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 14] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + Token.TOK_ID = 01 01; + Token.SGN_SLG = 11 00; + Token.Filler = ff ff ff ff; + + // Create the sequence number + + if (direction == sender_is_initiator) + { + memset(Token.SEND_SEQ+4, 0xff, 4) + } + else if (direction == sender_is_acceptor) + { + memset(Token.SEND_SEQ+4, 0, 4) + } + Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; + Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; + Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; + Token.SEND_SEQ[3] = (seq_num & 0x000000ff); + + // Derive signing key from session key + + Ksign = HMAC(Kss, "signaturekey"); + // length includes terminating null + + // Generate checksum of message - SGN_CKSUM + // Key derivation salt = 15 + + Sgn_Cksum = MD5((int32)15, Token.Header, data); + + // Save first 8 octets of HMAC Sgn_Cksum + + Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); + memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); + + // Encrypt the sequence number + + // Derive encryption key for the sequence number + // Key derivation salt = 0 + + if (exportable) + { + Kseq = HMAC(Kss, "fortybits", (int32)0); + // len includes terminating null + memset(Kseq+7, 0xab, 7) + } + else + { + Kseq = HMAC(Kss, (int32)0); + + + +Jaganathan, et al. Expires January 9, 2006 [Page 15] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + } + Kseq = HMAC(Kseq, Token.SGN_CKSUM); + + // Encrypt the sequence number + + RC4(Kseq, Token.SND_SEQ); + } + + +8.3 GSSAPI WRAP Semantics + + There are two encryption keys for GSSAPI message tokens, one that is + 128 bits in strength, and one that is 56 bits in strength as defined + in Section 6. + + All padding is rounded up to 1 byte. One byte is needed to say that + there is 1 byte of padding. The DES based mechanism type uses 8 byte + padding. See [RFC1964] Section 1.2.2.3. + + The RC4-HMAC GSS_Wrap() token has the following format: + + + Byte no Name Description + 0..1 TOK_ID Identification field. + Tokens emitted by GSS_Wrap() contain + the hex value 02 01 in this field. + 2..3 SGN_ALG Checksum algorithm indicator. + 11 00 - HMAC + 4..5 SEAL_ALG ff ff - none + 00 00 - DES-CBC + 10 00 - RC4 + 6..7 Filler Contains ff ff + 8..15 SND_SEQ Encrypted sequence number field. + 16..23 SGN_CKSUM Checksum of plaintext padded data, + calculated according to algorithm + specified in SGN_ALG field. + 24..31 Confounder Random confounder + 32..last Data encrypted or plaintext padded data + + The encryption mechanism used for GSS wrap based messages is as + follow: + + + WRAP(Kss, encrypt, direction, export, seq_num, data) + { + struct Token { // 32 octets + struct Header { + OCTET TOK_ID[2]; + + + +Jaganathan, et al. Expires January 9, 2006 [Page 16] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + OCTET SGN_ALG[2]; + OCTET SEAL_ALG[2]; + OCTET Filler[2]; + }; + OCTET SND_SEQ[8]; + OCTET SGN_CKSUM[8]; + OCTET Confounder[8]; + } Token; + + + Token.TOK_ID = 02 01; + Token.SGN_SLG = 11 00; + Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00; + Token.Filler = ff ff; + + // Create the sequence number + + if (direction == sender_is_initiator) + { + memset(&Token.SEND_SEQ[4], 0xff, 4) + } + else if (direction == sender_is_acceptor) + { + memset(&Token.SEND_SEQ[4], 0, 4) + } + Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; + Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; + Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; + Token.SEND_SEQ[3] = (seq_num & 0x000000ff); + + // Generate random confounder + + nonce(&Token.Confounder, 8); + + // Derive signing key from session key + + Ksign = HMAC(Kss, "signaturekey"); + + // Generate checksum of message - + // SGN_CKSUM + Token.Confounder + // Key derivation salt = 15 + + Sgn_Cksum = MD5((int32)15, Token.Header, + Token.Confounder); + + // Derive encryption key for data + // Key derivation salt = 0 + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 17] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0; + // XOR + if (exportable) + { + Kcrypt = HMAC(Klocal, "fortybits", (int32)0); + // len includes terminating null + memset(Kcrypt+7, 0xab, 7); + } + else + { + Kcrypt = HMAC(Klocal, (int32)0); + } + + // new encryption key salted with seq + + Kcrypt = HMAC(Kcrypt, (int32)seq); + + // Encrypt confounder (if encrypting) + + if (encrypt) + RC4(Kcrypt, Token.Confounder); + + // Sum the data buffer + + Sgn_Cksum += MD5(data); // Append to checksum + + // Encrypt the data (if encrypting) + + if (encrypt) + RC4(Kcrypt, data); + + // Save first 8 octets of HMAC Sgn_Cksum + + Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); + memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); + + // Derive encryption key for the sequence number + // Key derivation salt = 0 + + if (exportable) + { + Kseq = HMAC(Kss, "fortybits", (int32)0); + // len includes terminating null + memset(Kseq+7, 0xab, 7) + } + else + { + Kseq = HMAC(Kss, (int32)0); + + + +Jaganathan, et al. Expires January 9, 2006 [Page 18] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + } + Kseq = HMAC(Kseq, Token.SGN_CKSUM); + + // Encrypt the sequence number + + RC4(Kseq, Token.SND_SEQ); + + // Encrypted message = Token + Data + } + + The character constant "fortybits" evolved from the time when a 40- + bit key length was all that was exportable from the United States. + It is now used to recognize that the key length is of "exportable" + length. In this description, the key size is actually 56-bits. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 19] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +9. Security Considerations + + Care must be taken in implementing this encryption type because it + uses a stream cipher. If a different IV isn't used in each direction + when using a session key, the encryption is weak. By using the + sequence number as an IV, this is avoided. + +10. Normative References + + [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, + April 1992. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September 1993. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June 1996. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + +Authors' Addresses + + Karthik Jaganathan + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: karthikj@microsoft.com + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 20] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + John Brezak + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: jbrezak@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 21] + +Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Jaganathan, et al. Expires January 9, 2006 [Page 22] + +