diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt | 923 |
1 files changed, 923 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt new file mode 100644 index 00000000000..9887873ef06 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt @@ -0,0 +1,923 @@ + + +Kerberos working group M. Swift + U.Washington +Internet Draft J. Brezak +Document: draft-brezak-win2k-krb-rc4-hmac-04.txt Microsoft +Category: Informational May 2002 + + + The Microsoft Windows 2000 RC4-HMAC Kerberos encryption type + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. 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. + +1. 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), and provide exportable (meet United States government + export restriction requirements) encryption. + + 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. + + +2. Conventions used in this document + +Swift Category - Informational 1 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + + 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 RFC-2119 [2]. + +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 [6] + 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 + +4. Basic Operations + + The MD5 HMAC function is defined in [3]. It is used in this + encryption type for checksum operations. Refer to [3] 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 [7]. 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 [RSADSI]. A + compatible cipher is described in [8]. 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 + +Swift Category - Informational 2 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + 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. + + + 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. + + +Swift Category - Informational 3 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + +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) + + +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); + +Swift Category - Informational 4 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + } + 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); + 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"); + } + + + +Swift Category - Informational 5 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + 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. + +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. + +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 [5] 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 [5] + 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 + +Swift Category - Informational 6 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + + 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 + + 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 [5] 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]; + +Swift Category - Informational 7 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + }; + OCTET SND_SEQ[8]; + OCTET SGN_CKSUM[8]; + } Token; + + + 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 + { + +Swift Category - Informational 8 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + Kseq = HMAC(Kss, (int32)0); + } + 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 [5] 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]; + OCTET SGN_ALG[2]; + OCTET SEAL_ALG[2]; + OCTET Filler[2]; + }; + OCTET SND_SEQ[8]; + OCTET SGN_CKSUM[8]; + +Swift Category - Informational 9 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + 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 + + 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); + +Swift Category - Informational 10 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + } + + // 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); + } + 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. + +9. Security Considerations + +Swift Category - Informational 11 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type May 2002 + + + + 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. Acknowledgements + + We would like to thank Salil Dangi and Sam Hartman for the valuable + input in refining the descriptions of the functions and their input. + +11. References + + 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997 + + 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993 + + 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, + June 1996 + + 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April + 1992 + + 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April + 1992 + + 8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption + Algorithm", Work in Progress. + + 9 RC4 is a proprietary encryption algorithm available under license + from RSA Data Security Inc. For licensing information, contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + 10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 04.txt, June 25, 1999 + + +12. Author's Addresses + + Mike Swift + Dept. of Computer Science + +Swift Category - Informational 12 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + Sieg Hall + University of Washington + Seattle, WA 98105 + Email: mikesw@cs.washington.edu + + John Brezak + Microsoft + One Microsoft Way + Redmond, Washington + Email: jbrezak@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 13 + + + + + + + + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + +13. Full Copyright Statement + + "Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and + furnished to others, and derivative works that comment on or + otherwise explain it or assist in its implementation may be + prepared, copied, published and distributed, in whole or in + part, without restriction of any kind, provided that the above + copyright notice and this paragraph are included on all such + copies and derivative works. However, this document itself may + not be modified in any way, such as by removing the copyright + notice or references to the Internet Society or other Internet + organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or + as required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will + not be revoked by the Internet Society or its successors or + assigns. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 14 + + + + + + + |