diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt | 412 |
1 files changed, 412 insertions, 0 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt new file mode 100644 index 0000000..a97ef9d --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt @@ -0,0 +1,412 @@ +CAT working group M. Swift +Internet Draft J. Brezak +Document: draft-brezak-win2k-krb-rc4-hmac-01.txt Microsoft +Category: Informational October 1999 + + + The 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 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. + + +2. Conventions used in this document + + + +Swift Category - Informational 1 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + 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). + +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. + + The basic RC4 encryption operation is used in this encryption type + and defined 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. + + 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. + +Swift Category - Informational 2 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + + The nonce(n) function returns a pseudo-random number of "n" octets. + +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, "signature key") //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. + + ENCRYPT(K, T, data) + if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) + L = concat("fortybits", T) //includes zero octet at + //end of string constant + Else + L = T + Ksign = HMAC(K,L) + Confounder = nonce(8) // get an 8 octet nonce for a confounder + Checksum = HMAC(Ksign, concat(Confounder, data)) + Ke = Ksign + if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) + memset(&Ke[7], 0x0ab, 9) + Ke2 = HMAC(Ke, Checksum) + data = RC4(Ke2, data) + + 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; + +Swift Category - Informational 3 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + + 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 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. + +8.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). + +8.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. + + + +Swift Category - Informational 4 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + 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 based messages is as follow: + + T = the message type, encoded as a little-endian four byte integer. + + GSS-ENCRYPT(K, T, data) + IV = SND_SEQ + K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0) + if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) + L = concat("fortybits", T) //includes zero octet at end + else + L = T + Ksign = HMAC(K, L) + Ke = Ksign + if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) + memset(&Ke[7], 0x0ab, 9) + Ke2 = HMAC(Ke, IV) + Data = RC4(Ke2, data) + SND_SEQ = RC4(Ke, seq#) + + The sequence number (SND_SEQ) and IV are used as defined in [5] + Section 1.2.2. + + 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. + +8. 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. + +9. 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 + + + +Swift Category - Informational 5 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + + 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 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 + + 9 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network + Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- + 04.txt, June 25, 1999 + + +10. Author's Addresses + + Mike Swift + Microsoft + One Microsoft Way + Redmond, Washington + Email: mikesw@microsoft.com + + John Brezak + Microsoft + One Microsoft Way + Redmond, Washington + Email: jbrezak@microsoft.com + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 6 + + Windows 2000 RC4-HMAC Kerberos E-Type October 1999 + + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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." + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift Category - Informational 7 +
\ No newline at end of file |
