diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt | 592 |
1 files changed, 588 insertions, 4 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt index 85d7456..1fc9927 100644 --- a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt +++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt @@ -1,5 +1,589 @@ -This Internet-Draft has expired and is no longer available. -Unrevised documents placed in the Internet-Drafts directories have a -maximum life of six months. After that time, they must be updated, or -they will be deleted. This document was deleted on July 17, 2000. + +CAT working group M. Swift +Internet Draft J. Brezak +Document: draft-brezak-win2k-krb-rc4-hmac-02.txt Microsoft +Category: Informational November 2000 + + + The Windows 2000 RC4-HMAC Kerberos encryption type + + +tatus 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. + +. Abstract + + The 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 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 Windows 2000. + + +. Conventions used in this document + + + +wift Category - Informational 1 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + 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]. + +. 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 + +. 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 as defined in [9] (RFC- + 1510BIS) in Section titled "Key Derivation". With each message, the + message type (T) is used as a component of the keying material. This + summarizes the different key derivation values used in the various + +wift Category - Informational 2 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + operations. Note that these differ from the key derivations used in + other Kerberos encryption types. + + T = 1 for TS-ENC-TS in the AS-Request + T = 8 for the AS-Reply + T = 7 for the Authenticator in the TGS-Request + T = 8 for the TGS-Reply + T = 2 for the Server Ticket in the AP-Request + T = 11 for the Authenticator in the AP-Request + T = 12 for the Server returned AP-Reply + T = 15 in the generation of checksum for the MIC token + T = 0 in the generation of sequence number for the MIC token + T = 13 in the generation of checksum for the WRAP 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. + +. 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) + + +. 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. + +wift Category - Informational 3 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + BYTE L40[14] = "fortybits"; + BYTE SK = "signaturekey"; + + ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 10 + 4, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + add_8_random_bytes(data, data_len, conf_plus_data); + HMAC (K2, conf_plus_data, 8 + data_len, checksum); + HMAC (K1, checksum, 16, K3); + RC4(K3, conf_plus_data, 8 + data_len, edata + 16); + memcpy (edata, checksum, 16); + edata_len = 16 + 8 + data_len; + } + + DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) + { + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K1); + }else{ + HMAC (K, &T, 4, K1); + } + memcpy (K2, K1, 16); + if (fRC4_EXP) memset (K1+7, 0xAB, 9); + HMAC (K1, edata, 16, K3); // checksum is at edata + RC4(K3, edata + 16, edata_len - 16, edata + 16); + data_len = edata_len - 16 - 8; + memcpy (data, edata + 16 + 8, data_len); + + // verify generated and received checksums + HMAC (K2, edata + 16, edata_len - 16, checksum); + if (memcmp(edata, checksum, 16) != 0) + printf("CHECKSUM ERROR !!!!!!\n"); + } + + The header field on the encrypted data in KDC messages is: + + typedef struct _RC4_MDx_HEADER { + UCHAR Checksum[16]; + UCHAR Confounder[8]; + } RC4_MDx_HEADER, *PRC4_MDx_HEADER; + + The KDC message is encrypted using the ENCRYPT function not + including the Checksum in the RC4_MDx_HEADER. + + +wift Category - Informational 4 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + 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. + +. 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. + +. GSSAPI Kerberos V5 Mechanism Type + +.1 Mechanism Specific Changes + + The GSSAPI per-message tokens also require new checksum and + encryption types. The GSS-API per-message tokens must be changed to + support these new encryption types (See [5] Section 1.2.2). The + sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption + is: + Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 + + The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: + Byte 2..3 SGN ALG 0x11 0x00 - HMAC + + The only support quality of protection is: + #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 + + In addition, when using an RC4 based encryption type, the sequence + number is 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 framing - they are raw AP message and do not include object + identifiers. + #define GSS_C_DCE_STYLE 0x1000 + + + +wift Category - Informational 5 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + 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 + + 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 th 15 characters, trailing blank (ascii char 20) filled, with a 16 + octet of 0x0. + +.2 GSSAPI Checksum Type + + 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). + + MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, + MIC_seq, MIC_checksum) + { + HMAC (K, SK, 13, K4); + T = 15; + memcpy (T_plus_hdr_plus_msg + 00, &T, 4); + memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8); + // 0101 1100 FFFFFFFF + memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); + MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); + HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); + memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K5); + }else{ + HMAC (K, &T, 4, K5); + +wift Category - Informational 6 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + } + if (fRC4_EXP) memset(K5+7, 0xAB, 9); + HMAC(K5, MIT_checksum, 8, K6); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K6, seq_plus_direction, 8, MIC_seq); + } + +.3 GSSAPI Encryption Types + + There are two encryption types 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 encryption mechanism used for GSS wrap based messages is as + follow: + + + WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, + WRAP_seq, WRAP_checksum, edata, edata_len) + { + HMAC (K, SK, 13, K7); + T = 13; + PAD = 1; + memcpy (T_hdr_conf_msg_pad + 00, &T, 4); + memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 + FFFFFFFF + memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); + memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); + MD5 (T_hdr_conf_msg_pad, + 4 + 8 + 8 + msg_len + 1, + MD5_of_T_hdr_conf_msg_pad); + HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); + memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 + bytes + + T = 0; + if (fRC4_EXP){ + *((DWORD *)(L40+10)) = T; + HMAC (K, L40, 14, K8); + }else{ + HMAC (K, &T, 4, K8); + } + if (fRC4_EXP) memset(K8+7, 0xAB, 9); + HMAC(K8, WRAP_checksum, 8, K9); + copy_seq_num_in_big_endian(seq_num, seq_plus_direction); + //0x12345678 + +wift Category - Informational 7 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + copy_direction_flag (direction_flag, seq_plus_direction + + 4); //0x12345678FFFFFFFF + RC4(K9, seq_plus_direction, 8, WRAP_seq); + + for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte + of key with 0xF0 + T = 0; + if (fRC4_EXP){ + *(DWORD *)(L40+10) = T; + HMAC(K10, L40, 14, K11); + memset(K11+7, 0xAB, 9); + }else{ + HMAC(K10, &T, 4, K11); + } + HMAC(K11, seq_num, 4, K12); + RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, + edata); /* skip T & hdr */ + edata_len = 8 + msg_len + 1; // conf + msg_len + pad + } + + + 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. + +. 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. + +0. Acknowledgements + + We would like to thank Salil Dangi for the valuable input in + refining the descriptions of the functions and review input. + +1. 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 + + + +wift Category - Informational 8 + + Windows 2000 RC4-HMAC Kerberos E-Type June 2000 + + + + 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 + + +2. Author's Addresses + + Mike Swift + Dept. of Computer Science + 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 + + + + + + + + + + + + + + + +wift Category - Informational 9 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + +3. 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +wift Category - Informational 10 + |
