412 lines
14 KiB
Plaintext
412 lines
14 KiB
Plaintext
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<73>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
|
||
|