doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt

   1
   2
   3 Kerberos working group                                         M. Swift
   4                                                            U.Washington
   5 Internet Draft                                                J. Brezak
   6 Document: draft-brezak-win2k-krb-rc4-hmac-04.txt              Microsoft
   7 Category: Informational                                        May 2002
   8
   9
  10       The Microsoft Windows 2000 RC4-HMAC Kerberos encryption type
  11
  12
  13 Status of this Memo
  14
  15    This document is an Internet-Draft and is in full conformance with
  16    all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
  17    working documents of the Internet Engineering Task Force (IETF), its
  18    areas, and its working groups. Note that other groups may also
  19    distribute working documents as Internet-Drafts. Internet-Drafts are
  20    draft documents valid for a maximum of six months and may be
  21    updated, replaced, or obsoleted by other documents at any time. It
  22    is inappropriate to use Internet- Drafts as reference material or to
  23    cite them other than as "work in progress."
  24
  25    The list of current Internet-Drafts can be accessed at
  26    http://www.ietf.org/ietf/1id-abstracts.txt
  27
  28    The list of Internet-Draft Shadow Directories can be accessed at
  29    http://www.ietf.org/shadow.html.
  30
  31 1. Abstract
  32
  33    The Microsoft Windows 2000 implementation of Kerberos introduces a
  34    new encryption type based on the RC4 encryption algorithm and using
  35    an MD5 HMAC for checksum. This is offered as an alternative to using
  36    the existing DES based encryption types.
  37
  38    The RC4-HMAC encryption types are used to ease upgrade of existing
  39    Windows NT environments, provide strong crypto (128-bit key
  40    lengths), and provide exportable (meet United States government
  41    export restriction requirements) encryption.
  42
  43    The Microsoft Windows 2000 implementation of Kerberos contains new
  44    encryption and checksum types for two reasons: for export reasons
  45    early in the development process, 56 bit DES encryption could not be
  46    exported, and because upon upgrade from Windows NT 4.0 to Windows
  47    2000, accounts will not have the appropriate DES keying material to
  48    do the standard DES encryption. Furthermore, 3DES is not available
  49    for export, and there was a desire to use a single flavor of
  50    encryption in the product for both US and international products.
  51
  52    As a result, there are two new encryption types and one new checksum
  53    type introduced in Microsoft Windows 2000.
  54
  55
  56 2. Conventions used in this document
  57
  58 Swift                  Category - Informational                      1
  59
  60
  61
  62
  63
  64
  65
  66
  67                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
  68
  69
  70
  71    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  72    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
  73    this document are to be interpreted as described in RFC-2119 [2].
  74
  75 3. Key Generation
  76
  77    On upgrade from existing Windows NT domains, the user accounts would
  78    not have a DES based key available to enable the use of DES base
  79    encryption types specified in RFC 1510. The key used for RC4-HMAC is
  80    the same as the existing Windows NT key (NT Password Hash) for
  81    compatibility reasons. Once the account password is changed, the DES
  82    based keys are created and maintained. Once the DES keys are
  83    available DES based encryption types can be used with Kerberos.
  84
  85    The RC4-HMAC String to key function is defined as follow:
  86
  87    String2Key(password)
  88
  89         K = MD4(UNICODE(password))
  90
  91    The RC4-HMAC keys are generated by using the Windows UNICODE version
  92    of the password. Each Windows UNICODE character is encoded in
  93    little-endian format of 2 octets each. Then performing an MD4 [6]
  94    hash operation on just the UNICODE characters of the password (not
  95    including the terminating zero octets).
  96
  97    For an account with a password of "foo", this String2Key("foo") will
  98    return:
  99
 100         0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
 101         0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
 102
 103 4. Basic Operations
 104
 105    The MD5 HMAC function is defined in [3]. It is used in this
 106    encryption type for checksum operations. Refer to [3] for details on
 107    its operation. In this document this function is referred to as
 108    HMAC(Key, Data) returning the checksum using the specified key on
 109    the data.
 110
 111    The basic MD5 hash operation is used in this encryption type and
 112    defined in [7]. In this document this function is referred to as
 113    MD5(Data) returning the checksum of the data.
 114
 115    RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A
 116    compatible cipher is described in [8]. In this document the function
 117    is referred to as RC4(Key, Data) returning the encrypted data using
 118    the specified key on the data.
 119
 120    These encryption types use key derivation. With each message, the
 121    message type (T) is used as a component of the keying material. This
 122    table summarizes the different key derivation values used in the
 123
 124 Swift                  Category - Informational                      2
 125
 126
 127
 128
 129
 130
 131
 132
 133                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 134
 135
 136    various operations. Note that these differ from the key derivations
 137    used in other Kerberos encryption types. T = the message type,
 138    encoded as a little-endian four byte integer.
 139
 140
 141         1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
 142         the client key (T=1)
 143         2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session key
 144         or application session key), encrypted with the service key
 145         (T=2)
 146         3.  AS-REP encrypted part (includes TGS session key or
 147         application session key), encrypted with the client key (T=8)
 148         4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
 149         TGS session key (T=4)
 150         5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
 151         TGS authenticator subkey (T=5)
 152         6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
 153         with the TGS session key (T=6)
 154         7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
 155         TGS authenticator subkey), encrypted with the TGS session key
 156         (T=7)
 157         8.  TGS-REP encrypted part (includes application session key),
 158         encrypted with the TGS session key (T=8)
 159         9.  TGS-REP encrypted part (includes application session key),
 160         encrypted with the TGS authenticator subkey (T=8)
 161         10.  AP-REQ Authenticator cksum, keyed with the application
 162         session key (T=10)
 163         11.  AP-REQ Authenticator (includes application authenticator
 164         subkey), encrypted with the application session key (T=11)
 165         12.  AP-REP encrypted part (includes application session
 166         subkey), encrypted with the application session key (T=12)
 167         13.  KRB-PRIV encrypted part, encrypted with a key chosen by
 168         the application. Also for data encrypted with GSS Wrap (T=13)
 169         14.  KRB-CRED encrypted part, encrypted with a key chosen by
 170         the application (T=14)
 171         15.  KRB-SAFE cksum, keyed with a key chosen by the
 172         application. Also for data signed in GSS MIC (T=15)
 173
 174         Relative to RFC-1964 key uses:
 175
 176         T = 0 in the generation of sequence number for the MIC token
 177         T = 0 in the generation of sequence number for the WRAP token
 178         T = 0 in the generation of encrypted data for the WRAPPED token
 179
 180    All strings in this document are ASCII unless otherwise specified.
 181    The lengths of ASCII encoded character strings include the trailing
 182    terminator character (0).
 183
 184    The concat(a,b,c,...) function will return the logical concatenation
 185    (left to right) of the values of the arguments.
 186
 187    The nonce(n) function returns a pseudo-random number of "n" octets.
 188
 189
 190 Swift                  Category - Informational                      3
 191
 192
 193
 194
 195
 196
 197
 198
 199                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 200
 201
 202 5. Checksum Types
 203
 204    There is one checksum type used in this encryption type. The
 205    Kerberos constant for this type is:
 206         #define KERB_CHECKSUM_HMAC_MD5 (-138)
 207
 208    The function is defined as follows:
 209
 210    K - is the Key
 211    T - the message type, encoded as a little-endian four byte integer
 212
 213    CHKSUM(K, T, data)
 214
 215         Ksign = HMAC(K, "signaturekey")  //includes zero octet at end
 216         tmp = MD5(concat(T, data))
 217         CHKSUM = HMAC(Ksign, tmp)
 218
 219
 220 6. Encryption Types
 221
 222    There are two encryption types used in these encryption types. The
 223    Kerberos constants for these types are:
 224         #define KERB_ETYPE_RC4_HMAC             23
 225         #define KERB_ETYPE_RC4_HMAC_EXP         24
 226
 227    The basic encryption function is defined as follow:
 228
 229    T = the message type, encoded as a little-endian four byte integer.
 230
 231         OCTET L40[14] = "fortybits";
 232         OCTET SK = "signaturekey";
 233
 234    The header field on the encrypted data in KDC messages is:
 235
 236         typedef struct _RC4_MDx_HEADER {
 237             OCTET Checksum[16];
 238             OCTET Confounder[8];
 239         } RC4_MDx_HEADER, *PRC4_MDx_HEADER;
 240
 241
 242         ENCRYPT (K, export, T, data)
 243         {
 244             struct EDATA {
 245                 struct HEADER {
 246                         OCTET Checksum[16];
 247                         OCTET Confounder[8];
 248                 } Header;
 249                 OCTET Data[0];
 250             } edata;
 251
 252             if (export){
 253                 *((DWORD *)(L40+10)) = T;
 254                 HMAC (K, L40, 10 + 4, K1);
 255
 256 Swift                  Category - Informational                      4
 257
 258
 259
 260
 261
 262
 263
 264
 265                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 266
 267
 268             }
 269             else
 270             {
 271                 HMAC (K, &T, 4, K1);
 272             }
 273             memcpy (K2, K1, 16);
 274             if (export) memset (K1+7, 0xAB, 9);
 275
 276             nonce (edata.Confounder, 8);
 277             memcpy (edata.Data, data);
 278
 279             edata.Checksum = HMAC (K2, edata);
 280             K3 = HMAC (K1, edata.Checksum);
 281
 282             RC4 (K3, edata.Confounder);
 283             RC4 (K3, data.Data);
 284         }
 285
 286         DECRYPT (K, export, T, edata)
 287         {
 288             // edata looks like
 289             struct EDATA {
 290                 struct HEADER {
 291                         OCTET Checksum[16];
 292                         OCTET Confounder[8];
 293                 } Header;
 294                 OCTET Data[0];
 295             } edata;
 296
 297             if (export){
 298                 *((DWORD *)(L40+10)) = T;
 299                 HMAC (K, L40, 14, K1);
 300             }
 301             else
 302             {
 303                 HMAC (K, &T, 4, K1);
 304             }
 305             memcpy (K2, K1, 16);
 306             if (export) memset (K1+7, 0xAB, 9);
 307
 308             K3 = HMAC (K1, edata.Checksum);
 309
 310             RC4 (K3, edata.Confounder);
 311             RC4 (K3, edata.Data);
 312
 313
 314             // verify generated and received checksums
 315             checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
 316             if (checksum != edata.Checksum)
 317                 printf("CHECKSUM ERROR  !!!!!!\n");
 318         }
 319
 320
 321
 322 Swift                  Category - Informational                      5
 323
 324
 325
 326
 327
 328
 329
 330
 331                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 332
 333
 334    The KDC message is encrypted using the ENCRYPT function not
 335    including the Checksum in the RC4_MDx_HEADER.
 336
 337    The character constant "fortybits" evolved from the time when a 40-
 338    bit key length was all that was exportable from the United States.
 339    It is now used to recognize that the key length is of "exportable"
 340    length. In this description, the key size is actually 56-bits.
 341
 342 7. Key Strength Negotiation
 343
 344    A Kerberos client and server can negotiate over key length if they
 345    are using mutual authentication. If the client is unable to perform
 346    full strength encryption, it may propose a key in the "subkey" field
 347    of the authenticator, using a weaker encryption type. The server
 348    must then either return the same key or suggest its own key in the
 349    subkey field of the AP reply message. The key used to encrypt data
 350    is derived from the key returned by the server. If the client is
 351    able to perform strong encryption but the server is not, it may
 352    propose a subkey in the AP reply without first being sent a subkey
 353    in the authenticator.
 354
 355 8. GSSAPI Kerberos V5 Mechanism Type
 356
 357 8.1 Mechanism Specific Changes
 358
 359    The GSSAPI per-message tokens also require new checksum and
 360    encryption types. The GSS-API per-message tokens are adapted to
 361    support these new encryption types (See [5] Section 1.2.2).
 362
 363    The only support quality of protection is:
 364         #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0
 365
 366    When using this RC4 based encryption type, the sequence number is
 367    always sent in big-endian rather than little-endian order.
 368
 369    The Windows 2000 implementation also defines new GSSAPI flags in the
 370    initial token passed when initializing a security context. These
 371    flags are passed in the checksum field of the authenticator (See [5]
 372    Section 1.1.1).
 373
 374    GSS_C_DCE_STYLE - This flag was added for use with Microsoft's
 375    implementation of DCE RPC, which initially expected three legs of
 376    authentication. Setting this flag causes an extra AP reply to be
 377    sent from the client back to the server after receiving the serverÆs
 378    AP reply. In addition, the context negotiation tokens do not have
 379    GSSAPI per message tokens - they are raw AP messages that do not
 380    include object identifiers.
 381         #define GSS_C_DCE_STYLE                 0x1000
 382
 383    GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
 384    server that it should only allow the server application to identify
 385    the client by name and ID, but not to impersonate the client.
 386         #define GSS_C_IDENTIFY_FLAG             0x2000
 387
 388 Swift                  Category - Informational                      6
 389
 390
 391
 392
 393
 394
 395
 396
 397                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 398
 399
 400
 401    GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
 402    client wants to be informed of extended error information. In
 403    particular, Windows 2000 status codes may be returned in the data
 404    field of a Kerberos error message. This allows the client to
 405    understand a server failure more precisely. In addition, the server
 406    may return errors to the client that are normally handled at the
 407    application layer in the server, in order to let the client try to
 408    recover. After receiving an error message, the client may attempt to
 409    resubmit an AP request.
 410         #define GSS_C_EXTENDED_ERROR_FLAG       0x4000
 411
 412    These flags are only used if a client is aware of these conventions
 413    when using the SSPI on the Windows platform; they are not generally
 414    used by default.
 415
 416    When NetBIOS addresses are used in the GSSAPI, they are identified
 417    by the GSS_C_AF_NETBIOS value. This value is defined as:
 418         #define GSS_C_AF_NETBIOS                0x14
 419    NetBios addresses are 16-octet addresses typically composed of 1 to
 420    15 characters, trailing blank (ASCII char 20) filled, with a 16-th
 421    octet of 0x0.
 422
 423 8.2 GSSAPI MIC Semantics
 424
 425    The GSSAPI checksum type and algorithm is defined in Section 5. Only
 426    the first 8 octets of the checksum are used. The resulting checksum
 427    is stored in the SGN_CKSUM field (See [5] Section 1.2) for
 428    GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
 429
 430    The GSS_GetMIC token has the following format:
 431
 432       Byte no         Name       Description
 433        0..1           TOK_ID     Identification field.
 434                                  Tokens emitted by GSS_GetMIC() contain
 435                                  the hex value 01 01 in this field.
 436        2..3           SGN_ALG    Integrity algorithm indicator.
 437                                  11 00 - HMAC
 438        4..7           Filler     Contains ff ff ff ff
 439        8..15          SND_SEQ    Sequence number field.
 440        16..23         SGN_CKSUM  Checksum of "to-be-signed data",
 441                                  calculated according to algorithm
 442                                  specified in SGN_ALG field.
 443
 444    The MIC mechanism used for GSS MIC based messages is as follow:
 445
 446         GetMIC(Kss, direction, export, seq_num, data)
 447         {
 448                 struct Token {
 449                        struct Header {
 450                               OCTET TOK_ID[2];
 451                               OCTET SGN_ALG[2];
 452                               OCTET Filler[4];
 453
 454 Swift                  Category - Informational                      7
 455
 456
 457
 458
 459
 460
 461
 462
 463                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 464
 465
 466                        };
 467                        OCTET SND_SEQ[8];
 468                        OCTET SGN_CKSUM[8];
 469                 } Token;
 470
 471
 472                 Token.TOK_ID = 01 01;
 473                 Token.SGN_SLG = 11 00;
 474                 Token.Filler = ff ff ff ff;
 475
 476                 // Create the sequence number
 477
 478                 if (direction == sender_is_initiator)
 479                 {
 480                         memset(Token.SEND_SEQ+4, 0xff, 4)
 481                 }
 482                 else if (direction == sender_is_acceptor)
 483                 {
 484                         memset(Token.SEND_SEQ+4, 0, 4)
 485                 }
 486                 Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
 487                 Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
 488                 Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
 489                 Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
 490
 491                 // Derive signing key from session key
 492
 493                 Ksign = HMAC(Kss, "signaturekey");
 494                                   // length includes terminating null
 495
 496                 // Generate checksum of message - SGN_CKSUM
 497                 //   Key derivation salt = 15
 498
 499                 Sgn_Cksum = MD5((int32)15, Token.Header, data);
 500
 501                 // Save first 8 octets of HMAC Sgn_Cksum
 502
 503                 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
 504                 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
 505
 506                 // Encrypt the sequence number
 507
 508                 // Derive encryption key for the sequence number
 509                 //   Key derivation salt = 0
 510
 511                 if (exportable)
 512                 {
 513                         Kseq = HMAC(Kss, "fortybits", (int32)0);
 514                                      // len includes terminating null
 515                         memset(Kseq+7, 0xab, 7)
 516                 }
 517                 else
 518                 {
 519
 520 Swift                  Category - Informational                      8
 521
 522
 523
 524
 525
 526
 527
 528
 529                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 530
 531
 532                         Kseq = HMAC(Kss, (int32)0);
 533                 }
 534                 Kseq = HMAC(Kseq, Token.SGN_CKSUM);
 535
 536                 // Encrypt the sequence number
 537
 538                 RC4(Kseq, Token.SND_SEQ);
 539         }
 540
 541 8.3 GSSAPI WRAP Semantics
 542
 543    There are two encryption keys for GSSAPI message tokens, one that is
 544    128 bits in strength, and one that is 56 bits in strength as defined
 545    in Section 6.
 546
 547    All padding is rounded up to 1 byte. One byte is needed to say that
 548    there is 1 byte of padding. The DES based mechanism type uses 8 byte
 549    padding. See [5] Section 1.2.2.3.
 550
 551    The RC4-HMAC GSS_Wrap() token has the following format:
 552
 553    Byte no            Name         Description
 554        0..1           TOK_ID       Identification field.
 555                                    Tokens emitted by GSS_Wrap() contain
 556                                    the hex value 02 01 in this field.
 557        2..3           SGN_ALG      Checksum algorithm indicator.
 558                                    11 00 - HMAC
 559        4..5           SEAL_ALG     ff ff - none
 560                                    00 00 - DES-CBC
 561                                    10 00 - RC4
 562        6..7           Filler       Contains ff ff
 563        8..15          SND_SEQ      Encrypted sequence number field.
 564        16..23         SGN_CKSUM    Checksum of plaintext padded data,
 565                                    calculated according to algorithm
 566                                    specified in SGN_ALG field.
 567        24..31         Confounder   Random confounder
 568        32..last       Data         encrypted or plaintext padded data
 569
 570    The encryption mechanism used for GSS wrap based messages is as
 571    follow:
 572
 573
 574         WRAP(Kss, encrypt, direction, export, seq_num, data)
 575         {
 576                 struct Token {          // 32 octets
 577                        struct Header {
 578                               OCTET TOK_ID[2];
 579                               OCTET SGN_ALG[2];
 580                               OCTET SEAL_ALG[2];
 581                               OCTET Filler[2];
 582                        };
 583                        OCTET SND_SEQ[8];
 584                        OCTET SGN_CKSUM[8];
 585
 586 Swift                  Category - Informational                      9
 587
 588
 589
 590
 591
 592
 593
 594
 595                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 596
 597
 598                        OCTET Confounder[8];
 599                 } Token;
 600
 601
 602                 Token.TOK_ID = 02 01;
 603                 Token.SGN_SLG = 11 00;
 604                 Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
 605                 Token.Filler = ff ff;
 606
 607                 // Create the sequence number
 608
 609                 if (direction == sender_is_initiator)
 610                 {
 611                         memset(&Token.SEND_SEQ[4], 0xff, 4)
 612                 }
 613                 else if (direction == sender_is_acceptor)
 614                 {
 615                         memset(&Token.SEND_SEQ[4], 0, 4)
 616                 }
 617                 Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
 618                 Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
 619                 Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
 620                 Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
 621
 622                 // Generate random confounder
 623
 624                 nonce(&Token.Confounder, 8);
 625
 626                 // Derive signing key from session key
 627
 628                 Ksign = HMAC(Kss, "signaturekey");
 629
 630                 // Generate checksum of message -
 631                 //  SGN_CKSUM + Token.Confounder
 632                 //   Key derivation salt = 15
 633
 634                 Sgn_Cksum = MD5((int32)15, Token.Header,
 635                                 Token.Confounder);
 636
 637                 // Derive encryption key for data
 638                 //   Key derivation salt = 0
 639
 640                 for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
 641         // XOR
 642                 if (exportable)
 643                 {
 644                         Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
 645                                     // len includes terminating null
 646                         memset(Kcrypt+7, 0xab, 7);
 647                 }
 648                 else
 649                 {
 650                         Kcrypt = HMAC(Klocal, (int32)0);
 651
 652 Swift                  Category - Informational                     10
 653
 654
 655
 656
 657
 658
 659
 660
 661                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 662
 663
 664                 }
 665
 666                 // new encryption key salted with seq
 667
 668                 Kcrypt = HMAC(Kcrypt, (int32)seq);
 669
 670                 // Encrypt confounder (if encrypting)
 671
 672                 if (encrypt)
 673                         RC4(Kcrypt, Token.Confounder);
 674
 675                 // Sum the data buffer
 676
 677                 Sgn_Cksum += MD5(data);         // Append to checksum
 678
 679                 // Encrypt the data (if encrypting)
 680
 681                 if (encrypt)
 682                         RC4(Kcrypt, data);
 683
 684                 // Save first 8 octets of HMAC Sgn_Cksum
 685
 686                 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
 687                 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
 688
 689                 // Derive encryption key for the sequence number
 690                 //   Key derivation salt = 0
 691
 692                 if (exportable)
 693                 {
 694                         Kseq = HMAC(Kss, "fortybits", (int32)0);
 695                                       // len includes terminating null
 696                         memset(Kseq+7, 0xab, 7)
 697                 }
 698                 else
 699                 {
 700                         Kseq = HMAC(Kss, (int32)0);
 701                 }
 702                 Kseq = HMAC(Kseq, Token.SGN_CKSUM);
 703
 704                 // Encrypt the sequence number
 705
 706                 RC4(Kseq, Token.SND_SEQ);
 707
 708                 // Encrypted message = Token + Data
 709         }
 710
 711    The character constant "fortybits" evolved from the time when a 40-
 712    bit key length was all that was exportable from the United States.
 713    It is now used to recognize that the key length is of "exportable"
 714    length. In this description, the key size is actually 56-bits.
 715
 716 9. Security Considerations
 717
 718 Swift                  Category - Informational                     11
 719
 720
 721
 722
 723
 724
 725
 726
 727                 Windows 2000 RC4-HMAC Kerberos E-Type        May 2002
 728
 729
 730
 731    Care must be taken in implementing this encryption type because it
 732    uses a stream cipher. If a different IV isn't used in each direction
 733    when using a session key, the encryption is weak. By using the
 734    sequence number as an IV, this is avoided.
 735
 736 10. Acknowledgements
 737
 738    We would like to thank Salil Dangi and Sam Hartman for the valuable
 739    input in refining the descriptions of the functions and their input.
 740
 741 11. References
 742
 743    1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
 744       9, RFC 2026, October 1996.
 745
 746    2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 747       Levels", BCP 14, RFC 2119, March 1997
 748
 749    3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for
 750       Message Authentication", RFC 2104, February 1997
 751
 752    4  Kohl, J., Neuman, C., "The Kerberos Network Authentication
 753       Service (V5)", RFC 1510, September 1993
 754
 755    5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964,
 756       June 1996
 757
 758    6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April
 759       1992
 760
 761    7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April
 762       1992
 763
 764    8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption
 765       Algorithm", Work in Progress.
 766
 767    9  RC4 is a proprietary encryption algorithm available under license
 768       from RSA Data Security Inc.  For licensing information, contact:
 769
 770          RSA Data Security, Inc.
 771          100 Marine Parkway
 772          Redwood City, CA 94065-1031
 773
 774    10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
 775       Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
 776       04.txt, June 25, 1999
 777
 778
 779 12. Author's Addresses
 780
 781    Mike Swift
 782    Dept. of Computer Science
 783
 784 Swift                  Category - Informational                     12
 785
 786
 787
 788
 789
 790
 791
 792
 793                 Windows 2000 RC4-HMAC Kerberos E-Type    October 1999
 794
 795
 796    Sieg Hall
 797    University of Washington
 798    Seattle, WA 98105
 799    Email: mikesw@cs.washington.edu
 800
 801    John Brezak
 802    Microsoft
 803    One Microsoft Way
 804    Redmond, Washington
 805    Email: jbrezak@microsoft.com
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850 Swift                  Category - Informational                     13
 851
 852
 853
 854
 855
 856
 857
 858
 859                 Windows 2000 RC4-HMAC Kerberos E-Type    October 1999
 860
 861
 862
 863 13. Full Copyright Statement
 864
 865    "Copyright (C) The Internet Society (2000). All Rights Reserved.
 866
 867    This document and translations of it may be copied and
 868    furnished to others, and derivative works that comment on or
 869    otherwise explain it or assist in its implementation may be
 870    prepared, copied, published and distributed, in whole or in
 871    part, without restriction of any kind, provided that the above
 872    copyright notice and this paragraph are included on all such
 873    copies and derivative works.  However, this document itself may
 874    not be modified in any way, such as by removing the copyright
 875    notice or references to the Internet Society or other Internet
 876    organizations, except as needed for the purpose of developing
 877    Internet standards in which case the procedures for copyrights
 878    defined in the Internet Standards process must be followed, or
 879    as required to translate it into languages other than English.
 880
 881    The limited permissions granted above are perpetual and will
 882    not be revoked by the Internet Society or its successors or
 883    assigns.
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916 Swift                  Category - Informational                     14
 917
 918
 919
 920
 921
 922
 923