1CAT working group M. Swift 2Internet Draft J. Brezak 3Document: draft-brezak-win2k-krb-rc4-hmac-00.txt Microsoft 4Category: Informational September, 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 desired 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 July 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 for compatibility reasons. 72 Once the account password is changed, the DES based keys are created 73 and maintained. Once the DES keys are available DES based encryption 74 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(Key, Data) returning the checksum using the specified key on the 99 data. 100 101 The basic RC4 encryption operation is used in this encryption type 102 and defined in [8]. In this document the function is referred to as 103 RC4(Key, Data) returning the encrypted data using the specified key 104 on the data. 105 106 These encryption types use key derivation as defined in [9] (RFC- 107 1510BIS) in Section titled "Key Derivation". With each message, the 108 message type (T) is used as a component of the keying material. 109 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 July 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(Ksign, concat(T, data)) 139 CHKSUM = HMAC(K, 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 = "fiftysixbits" //includes zero octet at end 156 Else 157 L = "" // one octet of zero 158 Ksign = HMAC(K, concat(L, T)) 159 Confounder = nonce(8) // get an 8 octet nonce for a confounder 160 Checksum = HMAC(Ksign, concat(Confounder, data)) 161 Ke = Ksign 162 if (L == "fiftysixbits") memset(&Ke[7], 0x0ab, 9) 163 Ke2 = HMAC(Ke, Checksum) 164 data = RC4(Ke2, data) 165 166 The header field on the encrypted data in KDC messages is: 167 168 typedef struct _RC4_MDx_HEADER { 169 UCHAR Checksum[16]; 170 UCHAR Confounder[8]; 171 } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 172 173 174 175Swift Category - Informational 3 176 177 Windows 2000 RC4-HMAC Kerberos E-Type July 1999 178 179 180 The character constant "fiftysixbits" evolved from the time when a 181 56-bit key length was all that was exportable from the United 182 States. It is now used to recognize that the key length is of 183 "exportable" length. 184 1857. Key Strength Negotiation 186 187 A Kerberos client and server can negotiate over key length if they 188 are using mutual authentication. If the client is unable to perform 189 full strength encryption, it may propose a key in the "subkey" field 190 of the authenticator, using a weaker encryption type. The server 191 must then either return the same key or suggest its own key in the 192 subkey field of the AP reply message. The key used to encrypt data 193 is derived from the key returned by the server. If the client is 194 able to perform strong encryption but the server is not, it may 195 propose a subkey in the AP reply without first being sent a subkey 196 in the authenticator. 197 1988. GSSAPI Kerberos V5 Mechanism Type 199 2008.1 Mechanism Specific Changes 201 202 The GSSAPI per-message tokens also require new checksum and 203 encryption types. The GSS-API per-message tokens must be changed to 204 support these new encryption types (See [5] Section 1.2.2). The 205 sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 206 is: 207 Byte 4..5 SEAL_ALG 0x10 0x00 - RC4 208 209 The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 210 Byte 2..3 SGN ALG 0x11 0x00 - HMAC 211 212 The only support quality of protection is: 213 #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 214 215 In addition, when using an RC4 based encryption type, the sequence 216 number is sent in big-endian rather than little-endian order. 217 2188.2 GSSAPI Checksum Type 219 220 The GSSAPI checksum type and algorithm is defined in Section 5. Only 221 the first 8 octets of the checksum are used. The resulting checksum 222 is stored in the SGN_CKSUM field (See [5] Section 1.2) for 223 GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 224 2258.3 GSSAPI Encryption Types 226 227 There are two encryption types for GSSAPI message tokens, one that 228 is 128 bits in strength, and one that is 56 bits in strength as 229 defined in Section 6. 230 231 232 233 234Swift Category - Informational 4 235 236 Windows 2000 RC4-HMAC Kerberos E-Type July 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 GSS-ENCRYPT(K, T, data) 246 IV = SND_SEQ 247 K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0) 248 if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 249 L = "fortybits" //includes zero octet at end 250 else 251 L = "" // one octet of zero 252 Ksign = HMAC(K, concat(L, T)) 253 Ke = Ksign 254 if (L == "fortybits") memset(&Ke[7], 0x0ab, 9) 255 Ke2 = HMAC(Ke, IV) 256 Data = RC4(Ke2, data) 257 SND_SEQ = RC4(Ke, seq#) 258 259 The sequence number (SND_SEQ) and IV are used as defined in [5] 260 Section 1.2.2. 261 262 The character constant "fortybits" evolved from the time when a 40- 263 bit key length was all that was exportable from the United States. 264 It is now used to recognize that the key length is of "exportable" 265 length. 266 2678. Security Considerations 268 269 Care must be taken in implementing this encryption type because it 270 uses a stream cipher. If a different IV isn�t used in each direction 271 when using a session key, the encryption is weak. By using the 272 sequence number as an IV, this is avoided. 273 2749. References 275 276 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 277 9, RFC 2026, October 1996. 278 279 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 280 Levels", BCP 14, RFC 2119, March 1997 281 282 3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 283 Message Authentication", RFC 2104, February 1997 284 285 4 Kohl, J., Neuman, C., "The Kerberos Network Authentication 286 Service (V5)", RFC 1510, September 1993 287 288 5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 289 June 1996 290 291 292 293Swift Category - Informational 5 294 295 Windows 2000 RC4-HMAC Kerberos E-Type July 1999 296 297 298 299 6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 300 1992 301 302 7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 303 1992 304 305 8 RC4 is a proprietary encryption algorithm available under license 306 from RSA Data Security Inc. For licensing information, 307 contact: 308 RSA Data Security, Inc. 309 100 Marine Parkway 310 Redwood City, CA 94065-1031 311 312 9 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 313 Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- 314 04.txt, June 25, 1999 315 316 31710. Author's Addresses 318 319 Mike Swift 320 Microsoft 321 One Microsoft Way 322 Redmond, Washington 323 Email: mikesw@microsoft.com 324 325 John Brezak 326 Microsoft 327 One Microsoft Way 328 Redmond, Washington 329 Email: jbrezak@microsoft.com 330 331 332 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 July 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