crypto/heimdal-0.6.3/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt

   1 CAT working group                                              M. Swift
   2 Internet Draft                                                J. Brezak
   3 Document: draft-brezak-win2k-krb-rc4-hmac-01.txt              Microsoft
   4 Category: Informational                                    October 1999
   5
   6
   7            The Windows 2000 RC4-HMAC Kerberos encryption type
   8
   9
  10 Status 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
  28 1. 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
  53 2. Conventions used in this document
  54
  55
  56
  57 Swift                  Category - Informational                      1
  58 \f
  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
  66 3. 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
  88 4. 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
 116 Swift                  Category - Informational                      2
 117 \f
 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
 124 5. 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
 142 6. 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
 175 Swift                  Category - Informational                      3
 176 \f
 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
 186 7. 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
 199 8. GSSAPI Kerberos V5 Mechanism Type
 200
 201 8.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
 219 8.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
 226 8.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
 234 Swift                  Category - Informational                      4
 235 \f
 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
 270 8. 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
 277 9. 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
 293 Swift                  Category - Informational                      5
 294 \f
 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
 320 10. 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
 352 Swift                  Category - Informational                      6
 353 \f
 354                 Windows 2000 RC4-HMAC Kerberos E-Type    October 1999
 355
 356
 357
 358 11. 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
 411 Swift                  Category - Informational                      7
 412 \f