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, 0 insertions, 412 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 deleted file mode 100644 index a97ef9d191e0..000000000000 --- a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt +++ /dev/null @@ -1,412 +0,0 @@ -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 |