+++ /dev/null
-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
-\f
- 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
-\f
- 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
-\f
- 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
-\f
- 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
-\f
- 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
-\f
- 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
-\f
\ No newline at end of file
git.samba.org / samba.git / blobdiff