1CAT working group M. Swift 2Internet Draft J. Brezak 3Document: draft-brezak-win2k-krb-rc4-hmac-01.txt Microsoft 4Category: Informational October 1999 5 6 7 The Windows 2000 RC4-HMAC Kerberos encryption type 8 9 10Status of this Memo 11 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. Internet-Drafts are 17 draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet- Drafts as reference material or to 20 cite them other than as "work in progress." 21 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 27 281. Abstract 29 30 The Windows 2000 implementation of Kerberos introduces a new 31 encryption type based on the RC4 encryption algorithm and using an 32 MD5 HMAC for checksum. This is offered as an alternative to using 33 the existing DES based encryption types. 34 35 The RC4-HMAC encryption types are used to ease upgrade of existing 36 Windows NT environments, provide strong crypto (128-bit key 37 lengths), and provide exportable (meet United States government 38 export restriction requirements) encryption. 39 40 The Windows 2000 implementation of Kerberos contains new encryption 41 and checksum types for two reasons: for export reasons early in the 42 development process, 56 bit DES encryption could not be exported, 43 and because upon upgrade from Windows NT 4.0 to Windows 2000, 44 accounts will not have the appropriate DES keying material to do the 45 standard DES encryption. Furthermore, 3DES is not available for 46 export, and there was a desire to use a single flavor of encryption 47 in the product for both US and international products. 48 49 As a result, there are two new encryption types and one new checksum 50 type introduced in Windows 2000. 51 52 532. Conventions used in this document 54 55 56 57Swift Category - Informational 1 58 59 Windows 2000 RC4-HMAC Kerberos E-Type October 1999 60 61 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 64 this document are to be interpreted as described in RFC-2119 [2]. 65 663. Key Generation 67 68 On upgrade from existing Windows NT domains, the user accounts would 69 not have a DES based key available to enable the use of DES base 70 encryption types specified in RFC 1510. The key used for RC4-HMAC is 71 the same as the existing Windows NT key (NT Password Hash) for 72 compatibility reasons. Once the account password is changed, the DES 73 based keys are created and maintained. Once the DES keys are 74 available DES based encryption types can be used with Kerberos. 75 76 The RC4-HMAC String to key function is defined as follow: 77 78 String2Key(password) 79 80 K = MD4(UNICODE(password)) 81 82 The RC4-HMAC keys are generated by using the Windows UNICODE version 83 of the password. Each Windows UNICODE character is encoded in 84 little-endian format of 2 octets each. Then performing an MD4 [6] 85 hash operation on just the UNICODE characters of the password (not 86 including the terminating zero octets). 87 884. Basic Operations 89 90 The MD5 HMAC function is defined in [3]. It is used in this 91 encryption type for checksum operations. Refer to [3] for details on 92 its operation. In this document this function is referred to as 93 HMAC(Key, Data) returning the checksum using the specified key on 94 the data. 95 96 The basic MD5 hash operation is used in this encryption type and 97 defined in [7]. In this document this function is referred to as 98 MD5(Data) returning the checksum of the data. 99 100 The basic RC4 encryption operation is used in this encryption type 101 and defined in [8]. In this document the function is referred to as 102 RC4(Key, Data) returning the encrypted data using the specified key 103 on the data. 104 105 These encryption types use key derivation as defined in [9] (RFC- 106 1510BIS) in Section titled "Key Derivation". With each message, the 107 message type (T) is used as a component of the keying material. 108 109 All strings in this document are ASCII unless otherwise specified. 110 The lengths of ASCII encoded character strings include the trailing 111 terminator character (0). 112 113 The concat(a,b,c,...) function will return the logical concatenation 114 (left to right) of the values of the arguments. 115 116Swift Category - Informational 2 117 118 Windows 2000 RC4-HMAC Kerberos E-Type October 1999 119 120 121 122 The nonce(n) function returns a pseudo-random number of "n" octets. 123 1245. Checksum Types 125 126 There is one checksum type used in this encryption type. The 127 Kerberos constant for this type is: 128 #define KERB_CHECKSUM_HMAC_MD5 (-138) 129 130 The function is defined as follows: 131 132 K - is the Key 133 T - the message type, encoded as a little-endian four byte integer 134 135 CHKSUM(K, T, data) 136 137 Ksign = HMAC(K, "signature key") //includes zero octet at end 138 tmp = MD5(concat(T, data)) 139 CHKSUM = HMAC(Ksign, tmp) 140 141 1426. Encryption Types 143 144 There are two encryption types used in these encryption types. The 145 Kerberos constants for these types are: 146 #define KERB_ETYPE_RC4_HMAC 23 147 #define KERB_ETYPE_RC4_HMAC_EXP 24 148 149 The basic encryption function is defined as follow: 150 151 T = the message type, encoded as a little-endian four byte integer. 152 153 ENCRYPT(K, T, data) 154 if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 155 L = concat("fortybits", T) //includes zero octet at 156 //end of string constant 157 Else 158 L = T 159 Ksign = HMAC(K,L) 160 Confounder = nonce(8) // get an 8 octet nonce for a confounder 161 Checksum = HMAC(Ksign, concat(Confounder, data)) 162 Ke = Ksign 163 if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 164 memset(&Ke[7], 0x0ab, 9) 165 Ke2 = HMAC(Ke, Checksum) 166 data = RC4(Ke2, data) 167 168 The header field on the encrypted data in KDC messages is: 169 170 typedef struct _RC4_MDx_HEADER { 171 UCHAR Checksum[16]; 172 UCHAR Confounder[8]; 173 } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 174 175Swift Category - Informational 3 176 177 Windows 2000 RC4-HMAC Kerberos E-Type October 1999 178 179 180 181 The character constant "fortybits" evolved from the time when a 40- 182 bit key length was all that was exportable from the United States. 183 It is now used to recognize that the key length is of "exportable" 184 length. In this description, the key size is actually 56-bits. 185 1867. Key Strength Negotiation 187 188 A Kerberos client and server can negotiate over key length if they 189 are using mutual authentication. If the client is unable to perform 190 full strength encryption, it may propose a key in the "subkey" field 191 of the authenticator, using a weaker encryption type. The server 192 must then either return the same key or suggest its own key in the 193 subkey field of the AP reply message. The key used to encrypt data 194 is derived from the key returned by the server. If the client is 195 able to perform strong encryption but the server is not, it may 196 propose a subkey in the AP reply without first being sent a subkey 197 in the authenticator. 198 1998. GSSAPI Kerberos V5 Mechanism Type 200 2018.1 Mechanism Specific Changes 202 203 The GSSAPI per-message tokens also require new checksum and 204 encryption types. The GSS-API per-message tokens must be changed to 205 support these new encryption types (See [5] Section 1.2.2). The 206 sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 207 is: 208 Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 209 210 The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 211 Byte 2..3 SGN ALG 0x11 0x00 - HMAC 212 213 The only support quality of protection is: 214 #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 215 216 In addition, when using an RC4 based encryption type, the sequence 217 number is sent in big-endian rather than little-endian order. 218 2198.2 GSSAPI Checksum Type 220 221 The GSSAPI checksum type and algorithm is defined in Section 5. Only 222 the first 8 octets of the checksum are used. The resulting checksum 223 is stored in the SGN_CKSUM field (See [5] Section 1.2) for 224 GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 225 2268.3 GSSAPI Encryption Types 227 228 There are two encryption types for GSSAPI message tokens, one that 229 is 128 bits in strength, and one that is 56 bits in strength as 230 defined in Section 6. 231 232 233 234Swift Category - Informational 4 235 236 Windows 2000 RC4-HMAC Kerberos E-Type October 1999 237 238 239 All padding is rounded up to 1 byte. One byte is needed to say that 240 there is 1 byte of padding. The DES based mechanism type uses 8 byte 241 padding. See [5] Section 1.2.2.3. 242 243 The encryption mechanism used for GSS based messages is as follow: 244 245 T = the message type, encoded as a little-endian four byte integer. 246 247 GSS-ENCRYPT(K, T, data) 248 IV = SND_SEQ 249 K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0) 250 if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 251 L = concat("fortybits", T) //includes zero octet at end 252 else 253 L = T 254 Ksign = HMAC(K, L) 255 Ke = Ksign 256 if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 257 memset(&Ke[7], 0x0ab, 9) 258 Ke2 = HMAC(Ke, IV) 259 Data = RC4(Ke2, data) 260 SND_SEQ = RC4(Ke, seq#) 261 262 The sequence number (SND_SEQ) and IV are used as defined in [5] 263 Section 1.2.2. 264 265 The character constant "fortybits" evolved from the time when a 40- 266 bit key length was all that was exportable from the United States. 267 It is now used to recognize that the key length is of "exportable" 268 length. In this description, the key size is actually 56-bits. 269 2708. Security Considerations 271 272 Care must be taken in implementing this encryption type because it 273 uses a stream cipher. If a different IV isn�t used in each direction 274 when using a session key, the encryption is weak. By using the 275 sequence number as an IV, this is avoided. 276 2779. References 278 279 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 280 9, RFC 2026, October 1996. 281 282 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 283 Levels", BCP 14, RFC 2119, March 1997 284 285 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 286 Message Authentication", RFC 2104, February 1997 287 288 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication 289 Service (V5)", RFC 1510, September 1993 290 291 292 293Swift Category - Informational 5 294 295 Windows 2000 RC4-HMAC Kerberos E-Type October 1999 296 297 298 299 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 300 June 1996 301 302 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 303 1992 304 305 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 306 1992 307 308 8 RC4 is a proprietary encryption algorithm available under license 309 from RSA Data Security Inc. For licensing information, 310 contact: 311 RSA Data Security, Inc. 312 100 Marine Parkway 313 Redwood City, CA 94065-1031 314 315 9 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 316 Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- 317 04.txt, June 25, 1999 318 319 32010. Author's Addresses 321 322 Mike Swift 323 Microsoft 324 One Microsoft Way 325 Redmond, Washington 326 Email: mikesw@microsoft.com 327 328 John Brezak 329 Microsoft 330 One Microsoft Way 331 Redmond, Washington 332 Email: jbrezak@microsoft.com 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352Swift Category - Informational 6 353 354 Windows 2000 RC4-HMAC Kerberos E-Type October 1999 355 356 357 35811. Full Copyright Statement 359 360 Copyright (C) The Internet Society (1999). All Rights Reserved. 361 362 This document and translations of it may be copied and furnished to 363 others, and derivative works that comment on or otherwise explain it 364 or assist in its implementation may be prepared, copied, published 365 and distributed, in whole or in part, without restriction of any 366 kind, provided that the above copyright notice and this paragraph 367 are included on all such copies and derivative works. However, this 368 document itself may not be modified in any way, such as by removing 369 the copyright notice or references to the Internet Society or other 370 Internet organizations, except as needed for the purpose of 371 developing Internet standards in which case the procedures for 372 copyrights defined in the Internet Standards process must be 373 followed, or as required to translate it into languages other than 374 English. 375 376 The limited permissions granted above are perpetual and will not be 377 revoked by the Internet Society or its successors or assigns. 378 379 This document and the information contained herein is provided on an 380 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 381 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 382 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 383 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 384 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411Swift Category - Informational 7 412