1 2 3 4Internet Engineering Task Force K. Jaganathan 5Internet-Draft L. Zhu 6Expires: January 19, 2006 J. Brezak 7 Microsoft Corporation 8 July 18, 2005 9 10 11 The RC4-HMAC Kerberos encryption type 12 draft-jaganathan-rc4-hmac-01.txt 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on January 19, 2006. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2005). 42 43Abstract 44 45 The Microsoft Windows 2000 implementation of Kerberos introduces a 46 new encryption type based on the RC4 encryption algorithm and using 47 an MD5 HMAC for checksum. This is offered as an alternative to using 48 the existing DES based encryption types. 49 50 The RC4-HMAC encryption types are used to ease upgrade of existing 51 Windows NT environments, provide strong crypto (128-bit key lengths), 52 53 54 55Jaganathan, et al. Expires January 19, 2006 [Page 1] 56 57Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 58 59 60 and provide exportable (meet United States government export 61 restriction requirements) encryption. This document describes the 62 implementation of those encryption types 63 64Table of Contents 65 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 68 3. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Checksum Types . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Encryption Types . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 11 73 8. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 12 74 8.1 Mechanism Specific Changes . . . . . . . . . . . . . . . . 12 75 8.2 GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 13 76 8.3 GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 15 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 10. Normative References . . . . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 80 Intellectual Property and Copyright Statements . . . . . . . . 21 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Jaganathan, et al. Expires January 19, 2006 [Page 2] 112 113Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 114 115 1161. Introduction 117 118 The Microsoft Windows 2000 implementation of Kerberos contains new 119 encryption and checksum types for two reasons: for export reasons 120 early in the development process, 56 bit DES encryption could not be 121 exported, and because upon upgrade from Windows NT 4.0 to Windows 122 2000, accounts will not have the appropriate DES keying material to 123 do the standard DES encryption. Furthermore, 3DES is not available 124 for export, and there was a desire to use a single flavor of 125 encryption in the product for both US and international products. 126 127 As a result, there are two new encryption types and one new checksum 128 type introduced in Microsoft Windows 2000. 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Jaganathan, et al. Expires January 19, 2006 [Page 3] 168 169Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 170 171 1722. Conventions Used in This Document 173 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Jaganathan, et al. Expires January 19, 2006 [Page 4] 224 225Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 226 227 2283. Key Generation 229 230 On upgrade from existing Windows NT domains, the user accounts would 231 not have a DES based key available to enable the use of DES base 232 encryption types specified in RFC 4120. The key used for RC4-HMAC is 233 the same as the existing Windows NT key (NT Password Hash) for 234 compatibility reasons. Once the account password is changed, the DES 235 based keys are created and maintained. Once the DES keys are 236 available DES based encryption types can be used with Kerberos. 237 238 The RC4-HMAC String to key function is defined as follow: 239 240 String2Key(password) 241 242 K = MD4(UNICODE(password)) 243 244 The RC4-HMAC keys are generated by using the Windows UNICODE version 245 of the password. Each Windows UNICODE character is encoded in 246 little-endian format of 2 octets each. Then performing an MD4 247 [RFC1320] hash operation on just the UNICODE characters of the 248 password (not including the terminating zero octets). 249 250 For an account with a password of "foo", this String2Key("foo") will 251 return: 252 253 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 254 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Jaganathan, et al. Expires January 19, 2006 [Page 5] 280 281Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 282 283 2844. Basic Operations 285 286 The MD5 HMAC function is defined in [RFC2104]. It is used in this 287 encryption type for checksum operations. Refer to[RFC2104]for 288 details on its operation. In this document this function is referred 289 to as HMAC(Key, Data) returning the checksum using the specified key 290 on the data. 291 292 The basic MD5 hash operation is used in this encryption type and 293 defined in [RFC1321]. In this document this function is referred to 294 as MD5(Data) returning the checksum of the data. 295 296 RC4 is a stream cipher licensed by RSA Data Security . In this 297 document the function is referred to as RC4(Key, Data) returning the 298 encrypted data using the specified key on the data. 299 300 These encryption types use key derivation. With each message, the 301 message type (T) is used as a component of the keying material. This 302 table summarizes the different key derivation values used in the 303 various operations. Note that these differ from the key derivations 304 used in other Kerberos encryption types. T = the message type, 305 encoded as a little-endian four byte integer. 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Jaganathan, et al. Expires January 19, 2006 [Page 6] 336 337Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 338 339 340 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with 341 the client key (T=1) 342 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key 343 or application session key), encrypted with the service key 344 (T=2) 345 3. AS-REP encrypted part (includes TGS session key or 346 application session key), encrypted with the client key (T=8) 347 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the 348 TGS session key (T=4) 349 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the 350 TGS authenticator subkey (T=5) 351 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, 352 keyed with the TGS session key (T=6) 353 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes 354 TGS authenticator subkey), encrypted with the TGS session key 355 T=7) 356 8. TGS-REP encrypted part (includes application session key), 357 encrypted with the TGS session key (T=8) 358 9. TGS-REP encrypted part (includes application session key), 359 encrypted with the TGS authenticator subkey (T=8) 360 10. AP-REQ Authenticator cksum, keyed with the application 361 session key (T=10) 362 11. AP-REQ Authenticator (includes application authenticator 363 subkey), encrypted with the application session key (T=11) 364 12. AP-REP encrypted part (includes application session 365 subkey), encrypted with the application session key (T=12) 366 13. KRB-PRIV encrypted part, encrypted with a key chosen by 367 the application. Also for data encrypted with GSS Wrap (T=13) 368 14. KRB-CRED encrypted part, encrypted with a key chosen by 369 the application (T=14) 370 15. KRB-SAFE cksum, keyed with a key chosen by the 371 application. Also for data signed in GSS MIC (T=15) 372 373 Relative to RFC-4121 key uses: 374 375 T = 0 in the generation of sequence number for the MIC token 376 T = 0 in the generation of sequence number for the WRAP token 377 T = 0 in the generation of encrypted data for the WRAPPED token 378 379 All strings in this document are ASCII unless otherwise specified. 380 The lengths of ASCII encoded character strings include the trailing 381 terminator character (0). The concat(a,b,c,...) function will return 382 the logical concatenation (left to right) of the values of the 383 arguments. The nonce(n) function returns a pseudo-random number of 384 "n" octets. 385 386 387 388 389 390 391Jaganathan, et al. Expires January 19, 2006 [Page 7] 392 393Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 394 395 3965. Checksum Types 397 398 There is one checksum type used in this encryption type. The 399 Kerberos constant for this type is: 400 401 #define KERB_CHECKSUM_HMAC_MD5 (-138) 402 403 The function is defined as follows: 404 405 K - is the Key 406 T - the message type, encoded as a little-endian four byte integer 407 408 CHKSUM(K, T, data) 409 410 Ksign = HMAC(K, "signaturekey") //includes zero octet at end 411 tmp = MD5(concat(T, data)) 412 CHKSUM = HMAC(Ksign, tmp) 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Jaganathan, et al. Expires January 19, 2006 [Page 8] 448 449Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 450 451 4526. Encryption Types 453 454 There are two encryption types used in these encryption types. The 455 Kerberos constants for these types are: 456 457 #define KERB_ETYPE_RC4_HMAC 23 458 #define KERB_ETYPE_RC4_HMAC_EXP 24 459 460 The basic encryption function is defined as follow: 461 462 T = the message type, encoded as a little-endian four byte integer. 463 464 OCTET L40[14] = "fortybits"; 465 OCTET SK = "signaturekey"; 466 467 The header field on the encrypted data in KDC messages is: 468 469 typedef struct _RC4_MDx_HEADER { 470 OCTET Checksum[16]; 471 OCTET Confounder[8]; 472 } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 473 474 475 ENCRYPT (K, export, T, data) 476 { 477 struct EDATA { 478 struct HEADER { 479 OCTET Checksum[16]; 480 OCTET Confounder[8]; 481 } Header; 482 OCTET Data[0]; 483 } edata; 484 485 if (export){ 486 *((DWORD *)(L40+10)) = T; 487 HMAC (K, L40, 10 + 4, K1); 488 } 489 else 490 { 491 HMAC (K, "&"T, 4, K1); 492 } 493 memcpy (K2, K1, 16); 494 if (export) memset (K1+7, 0xAB, 9); 495 496 nonce (edata.Confounder, 8); 497 memcpy (edata.Data, data); 498 499 edata.Checksum = HMAC (K2, edata); 500 501 502 503Jaganathan, et al. Expires January 19, 2006 [Page 9] 504 505Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 506 507 508 K3 = HMAC (K1, edata.Checksum); 509 510 RC4 (K3, edata.Confounder); 511 RC4 (K3, data.Data); 512 } 513 514 DECRYPT (K, export, T, edata) 515 { 516 // edata looks like 517 struct EDATA { 518 struct HEADER { 519 OCTET Checksum[16]; 520 OCTET Confounder[8]; 521 } Header; 522 OCTET Data[0]; 523 } edata; 524 525 if (export){ 526 *((DWORD *)(L40+10)) = T; 527 HMAC (K, L40, 14, K1); 528 } 529 else 530 { 531 HMAC (K, "&"T, 4, K1); 532 } 533 memcpy (K2, K1, 16); 534 if (export) memset (K1+7, 0xAB, 9); 535 536 K3 = HMAC (K1, edata.Checksum); 537 538 RC4 (K3, edata.Confounder); 539 RC4 (K3, edata.Data); 540 541 542 // verify generated and received checksums 543 checksum = HMAC (K2, concat(edata.Confounder, edata.Data)); 544 if (checksum != edata.Checksum) 545 printf("CHECKSUM ERROR !!!!!!\n"); 546 } 547 548 The KDC message is encrypted using the ENCRYPT function not including 549 the Checksum in the RC4_MDx_HEADER. 550 551 The character constant "fortybits" evolved from the time when a 40- 552 bit key length was all that was exportable from the United States. 553 It is now used to recognize that the key length is of "exportable" 554 length. In this description, the key size is actually 56-bits. 555 556 557 558 559Jaganathan, et al. Expires January 19, 2006 [Page 10] 560 561Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 562 563 5647. Key Strength Negotiation 565 566 TA Kerberos client and server can negotiate over key length if they 567 are using mutual authentication. If the client is unable to perform 568 full strength encryption, it may propose a key in the "subkey" field 569 of the authenticator, using a weaker encryption type. The server 570 must then either return the same key or suggest its own key in the 571 subkey field of the AP reply message. The key used to encrypt data 572 is derived from the key returned by the server. If the client is 573 able to perform strong encryption but the server is not, it may 574 propose a subkey in the AP reply without first being sent a subkey in 575 the authenticator. 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Jaganathan, et al. Expires January 19, 2006 [Page 11] 616 617Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 618 619 6208. GSSAPI Kerberos V5 Mechanism Type 621 6228.1 Mechanism Specific Changes 623 624 The GSSAPI per-message tokens also require new checksum and 625 encryption types. The GSS-API per-message tokens are adapted to 626 support these new encryption types . See [RFC4121] . 627 628 The only support quality of protection is: 629 630 #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 631 632 When using this RC4 based encryption type, the sequence number is 633 always sent in big-endian rather than little-endian order. 634 635 The Windows 2000 implementation also defines new GSSAPI flags in the 636 initial token passed when initializing a security context. These 637 flags are passed in the checksum field of the authenticator. See 638 [RFC4121] . 639 640 GSS_C_DCE_STYLE - This flag was added for use with Microsoft's 641 implementation of DCE RPC, which initially expected three legs of 642 authentication. Setting this flag causes an extra AP reply to be 643 sent from the client back to the server after receiving the serverAEs 644 AP reply. In addition, the context negotiation tokens do not have 645 GSSAPI per message tokens - they are raw AP messages that do not 646 include object identifiers. 647 648 #define GSS_C_DCE_STYLE 0x1000 649 650 GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 651 server that it should only allow the server application to identify 652 the client by name and ID, but not to impersonate the client. 653 654 #define GSS_C_IDENTIFY_FLAG 0x2000 655 656 GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 657 client wants to be informed of extended error information. In 658 particular, Windows 2000 status codes may be returned in the data 659 field of a Kerberos error message. This allows the client to 660 understand a server failure more precisely. In addition, the server 661 may return errors to the client that are normally handled at the 662 application layer in the server, in order to let the client try to 663 recover. After receiving an error message, the client may attempt to 664 resubmit an AP request. 665 666 #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 667 668 669 670 671Jaganathan, et al. Expires January 19, 2006 [Page 12] 672 673Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 674 675 676 These flags are only used if a client is aware of these conventions 677 when using the SSPI on the Windows platform; they are not generally 678 used by default. 679 680 When NetBIOS addresses are used in the GSSAPI, they are identified by 681 the GSS_C_AF_NETBIOS value. This value is defined as: 682 683 #define GSS_C_AF_NETBIOS 0x14 684 685 NetBios addresses are 16-octet addresses typically composed of 1 to 686 15 characters, trailing blank (ASCII char 20) filled, with a 16-th 687 octet of 0x0. 688 6898.2 GSSAPI MIC Semantics 690 691 The GSSAPI checksum type and algorithm is defined in Section 5. Only 692 the first 8 octets of the checksum are used. The resulting checksum 693 is stored in the SGN_CKSUM field . See [RFC4121] for GSS_GetMIC() 694 and GSS_Wrap(conf_flag=FALSE). 695 696 The GSS_GetMIC token has the following format: 697 698 Byte no Name Description 699 0..1 TOK_ID Identification field. 700 Tokens emitted by GSS_GetMIC() contain 701 the hex value 01 01 in this field. 702 2..3 SGN_ALG Integrity algorithm indicator. 703 11 00 - HMAC 704 4..7 Filler Contains ff ff ff ff 705 8..15 SND_SEQ Sequence number field. 706 6..23 SGN_CKSUM Checksum of "to-be-signed data", 707 calculated according to algorithm 708 specified in SGN_ALG field. 709 710 The MIC mechanism used for GSS MIC based messages is as follow: 711 712 GetMIC(Kss, direction, export, seq_num, data) 713 { 714 struct Token { 715 struct Header { 716 OCTET TOK_ID[2]; 717 OCTET SGN_ALG[2]; 718 OCTET Filler[4]; 719 }; 720 OCTET SND_SEQ[8]; 721 OCTET SGN_CKSUM[8]; 722 } Token; 723 724 725 726 727Jaganathan, et al. Expires January 19, 2006 [Page 13] 728 729Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 730 731 732 Token.TOK_ID = 01 01; 733 Token.SGN_SLG = 11 00; 734 Token.Filler = ff ff ff ff; 735 736 // Create the sequence number 737 738 if (direction == sender_is_initiator) 739 { 740 memset(Token.SEND_SEQ+4, 0xff, 4) 741 } 742 else if (direction == sender_is_acceptor) 743 { 744 memset(Token.SEND_SEQ+4, 0, 4) 745 } 746 Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24; 747 Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16; 748 Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8; 749 Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff); 750 751 // Derive signing key from session key 752 753 Ksign = HMAC(Kss, "signaturekey"); 754 // length includes terminating null 755 756 // Generate checksum of message - SGN_CKSUM 757 // Key derivation salt = 15 758 759 Sgn_Cksum = MD5((int32)15, Token.Header, data); 760 761 // Save first 8 octets of HMAC Sgn_Cksum 762 763 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 764 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 765 766 // Encrypt the sequence number 767 768 // Derive encryption key for the sequence number 769 // Key derivation salt = 0 770 771 if (exportable) 772 { 773 Kseq = HMAC(Kss, "fortybits", (int32)0); 774 // len includes terminating null 775 memset(Kseq+7, 0xab, 7) 776 } 777 else 778 { 779 Kseq = HMAC(Kss, (int32)0); 780 781 782 783Jaganathan, et al. Expires January 19, 2006 [Page 14] 784 785Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 786 787 788 } 789 Kseq = HMAC(Kseq, Token.SGN_CKSUM); 790 791 // Encrypt the sequence number 792 793 RC4(Kseq, Token.SND_SEQ); 794 } 795 796 7978.3 GSSAPI WRAP Semantics 798 799 There are two encryption keys for GSSAPI message tokens, one that is 800 128 bits in strength, and one that is 56 bits in strength as defined 801 in Section 6. 802 803 All padding is rounded up to 1 byte. One byte is needed to say that 804 there is 1 byte of padding. The DES based mechanism type uses 8 byte 805 padding. See [RFC4121] . 806 807 The RC4-HMAC GSS_Wrap() token has the following format: 808 809 810 Byte no Name Description 811 0..1 TOK_ID Identification field. 812 Tokens emitted by GSS_Wrap() contain 813 the hex value 02 01 in this field. 814 2..3 SGN_ALG Checksum algorithm indicator. 815 11 00 - HMAC 816 4..5 SEAL_ALG ff ff - none 817 00 00 - DES-CBC 818 10 00 - RC4 819 6..7 Filler Contains ff ff 820 8..15 SND_SEQ Encrypted sequence number field. 821 16..23 SGN_CKSUM Checksum of plaintext padded data, 822 calculated according to algorithm 823 specified in SGN_ALG field. 824 24..31 Confounder Random confounder 825 32..last Data encrypted or plaintext padded data 826 827 The encryption mechanism used for GSS wrap based messages is as 828 follow: 829 830 831 WRAP(Kss, encrypt, direction, export, seq_num, data) 832 { 833 struct Token { // 32 octets 834 struct Header { 835 OCTET TOK_ID[2]; 836 837 838 839Jaganathan, et al. Expires January 19, 2006 [Page 15] 840 841Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 842 843 844 OCTET SGN_ALG[2]; 845 OCTET SEAL_ALG[2]; 846 OCTET Filler[2]; 847 }; 848 OCTET SND_SEQ[8]; 849 OCTET SGN_CKSUM[8]; 850 OCTET Confounder[8]; 851 } Token; 852 853 854 Token.TOK_ID = 02 01; 855 Token.SGN_SLG = 11 00; 856 Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00; 857 Token.Filler = ff ff; 858 859 // Create the sequence number 860 861 if (direction == sender_is_initiator) 862 { 863 memset("&"Token.SEND_SEQ[4], 0xff, 4) 864 } 865 else if (direction == sender_is_acceptor) 866 { 867 memset("&"Token.SEND_SEQ[4], 0, 4) 868 } 869 Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24; 870 Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16; 871 Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8; 872 Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff); 873 874 // Generate random confounder 875 876 nonce("&"Token.Confounder, 8); 877 878 // Derive signing key from session key 879 880 Ksign = HMAC(Kss, "signaturekey"); 881 882 // Generate checksum of message - 883 // SGN_CKSUM + Token.Confounder 884 // Key derivation salt = 15 885 886 Sgn_Cksum = MD5((int32)15, Token.Header, 887 Token.Confounder); 888 889 // Derive encryption key for data 890 // Key derivation salt = 0 891 892 893 894 895Jaganathan, et al. Expires January 19, 2006 [Page 16] 896 897Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 898 899 900 for (i = 0; i "<" 16; i++) Klocal[i] = Kss[i] ^ 0xF0; 901 // XOR 902 if (exportable) 903 { 904 Kcrypt = HMAC(Klocal, "fortybits", (int32)0); 905 // len includes terminating null 906 memset(Kcrypt+7, 0xab, 7); 907 } 908 else 909 { 910 Kcrypt = HMAC(Klocal, (int32)0); 911 } 912 913 // new encryption key salted with seq 914 915 Kcrypt = HMAC(Kcrypt, (int32)seq); 916 917 // Encrypt confounder (if encrypting) 918 919 if (encrypt) 920 RC4(Kcrypt, Token.Confounder); 921 922 // Sum the data buffer 923 924 Sgn_Cksum += MD5(data); // Append to checksum 925 926 // Encrypt the data (if encrypting) 927 928 if (encrypt) 929 RC4(Kcrypt, data); 930 931 // Save first 8 octets of HMAC Sgn_Cksum 932 933 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 934 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 935 936 // Derive encryption key for the sequence number 937 // Key derivation salt = 0 938 939 if (exportable) 940 { 941 Kseq = HMAC(Kss, "fortybits", (int32)0); 942 // len includes terminating null 943 memset(Kseq+7, 0xab, 7) 944 } 945 else 946 { 947 Kseq = HMAC(Kss, (int32)0); 948 949 950 951Jaganathan, et al. Expires January 19, 2006 [Page 17] 952 953Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 954 955 956 } 957 Kseq = HMAC(Kseq, Token.SGN_CKSUM); 958 959 // Encrypt the sequence number 960 961 RC4(Kseq, Token.SND_SEQ); 962 963 // Encrypted message = Token + Data 964 } 965 966 The character constant "fortybits" evolved from the time when a 40- 967 bit key length was all that was exportable from the United States. 968 It is now used to recognize that the key length is of "exportable" 969 length. In this description, the key size is actually 56-bits. 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007Jaganathan, et al. Expires January 19, 2006 [Page 18] 1008 1009Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 1010 1011 10129. Security Considerations 1013 1014 Care must be taken in implementing this encryption type because it 1015 uses a stream cipher. If a different IV isn't used in each direction 1016 when using a session key, the encryption is weak. By using the 1017 sequence number as an IV, this is avoided. The Windows 1018 implementation of Kerberos uses a minimum RC4 key strength of 128 1019 bits. A discussion of the security considerations when using HMACs 1020 is present in [RFC2104] . 1021 102210. Normative References 1023 1024 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 1025 April 1992. 1026 1027 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1028 April 1992. 1029 1030 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1031 Hashing for Message Authentication", RFC 2104, 1032 February 1997. 1033 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, March 1997. 1036 1037 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1038 Kerberos Network Authentication Service (V5)", RFC 4120, 1039 July 2005. 1040 1041 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1042 Version 5 Generic Security Service Application Program 1043 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1044 July 2005. 1045 1046 1047Authors' Addresses 1048 1049 Karthik Jaganathan 1050 Microsoft Corporation 1051 One Microsoft Way 1052 Redmond, WA 98052 1053 US 1054 1055 Email: karthikj@microsoft.com 1056 1057 1058 1059 1060 1061 1062 1063Jaganathan, et al. Expires January 19, 2006 [Page 19] 1064 1065Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 1066 1067 1068 Larry Zhu 1069 Microsoft Corporation 1070 One Microsoft Way 1071 Redmond, WA 98052 1072 US 1073 1074 Email: lzhu@microsoft.com 1075 1076 1077 John Brezak 1078 Microsoft Corporation 1079 One Microsoft Way 1080 Redmond, WA 98052 1081 US 1082 1083 Email: jbrezak@microsoft.com 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119Jaganathan, et al. Expires January 19, 2006 [Page 20] 1120 1121Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 1122 1123 1124Intellectual Property Statement 1125 1126 The IETF takes no position regarding the validity or scope of any 1127 Intellectual Property Rights or other rights that might be claimed to 1128 pertain to the implementation or use of the technology described in 1129 this document or the extent to which any license under such rights 1130 might or might not be available; nor does it represent that it has 1131 made any independent effort to identify any such rights. Information 1132 on the procedures with respect to rights in RFC documents can be 1133 found in BCP 78 and BCP 79. 1134 1135 Copies of IPR disclosures made to the IETF Secretariat and any 1136 assurances of licenses to be made available, or the result of an 1137 attempt made to obtain a general license or permission for the use of 1138 such proprietary rights by implementers or users of this 1139 specification can be obtained from the IETF on-line IPR repository at 1140 http://www.ietf.org/ipr. 1141 1142 The IETF invites any interested party to bring to its attention any 1143 copyrights, patents or patent applications, or other proprietary 1144 rights that may cover technology that may be required to implement 1145 this standard. Please address the information to the IETF at 1146 ietf-ipr@ietf.org. 1147 1148 1149Disclaimer of Validity 1150 1151 This document and the information contained herein are provided on an 1152 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1153 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1154 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1155 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1156 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1157 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1158 1159 1160Copyright Statement 1161 1162 Copyright (C) The Internet Society (2005). This document is subject 1163 to the rights, licenses and restrictions contained in BCP 78, and 1164 except as set forth therein, the authors retain all their rights. 1165 1166 1167Acknowledgment 1168 1169 Funding for the RFC Editor function is currently provided by the 1170 Internet Society. 1171 1172 1173 1174 1175Jaganathan, et al. Expires January 19, 2006 [Page 21] 1176 1177 1178