588 lines
21 KiB
Plaintext
588 lines
21 KiB
Plaintext
CAT working group M. Swift
|
||
Internet Draft J. Brezak
|
||
Document: draft-brezak-win2k-krb-rc4-hmac-03.txt Microsoft
|
||
Category: Informational June 2000
|
||
|
||
|
||
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 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].
|
||
|
||
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).
|
||
|
||
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
|
||
|
||
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.
|
||
|
||
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
|
||
|
||
Swift 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.
|
||
|
||
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, "signaturekey") //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.
|
||
|
||
Swift 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.
|
||
|
||
|
||
Swift 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.
|
||
|
||
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.
|
||
|
||
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<66>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<65>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
|
||
|
||
|
||
|
||
Swift 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.
|
||
|
||
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).
|
||
|
||
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);
|
||
|
||
Swift 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);
|
||
}
|
||
|
||
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.
|
||
|
||
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
|
||
|
||
Swift 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.
|
||
|
||
9. 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.
|
||
|
||
10. Acknowledgements
|
||
|
||
We would like to thank Salil Dangi for the valuable input in
|
||
refining the descriptions of the functions and review input.
|
||
|
||
11. 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 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
|
||
|
||
|
||
12. 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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Swift Category - Informational 9
|
||
|
||
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
|
||
|
||
|
||
|
||
13. 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Swift Category - Informational 10
|
||
|