1 2 3 4Internet Engineering Task Force K. Jaganathan 5Internet-Draft L. Zhu 6Expires: January 9, 2006 J. Brezak 7 Microsoft Corporation 8 July 8, 2005 9 10 11 The RC4-HMAC Kerberos encryption type 12 draft-jaganathan-rc4-hmac-00.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 9, 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 9, 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 . . . . . . . . . . . . . . . . . . . 12 73 8. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 13 74 8.1 Mechanism Specific Changes . . . . . . . . . . . . . . . . 13 75 8.2 GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 14 76 8.3 GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 16 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 10. Normative References . . . . . . . . . . . . . . . . . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 80 Intellectual Property and Copyright Statements . . . . . . . . 22 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 9, 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 9, 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 9, 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 1510. 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 9, 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 9, 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-1964 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 9, 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 9, 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 9, 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 9, 2006 [Page 10] 560 561Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 562 563 564 The pseudo-random operation [RFC3961] for both enctypes above is 565 defined as follows: 566 567 pseudo-random(K, S) = HMAC-SHA1(K, S) 568 569 where K is the protocol key and S is the input octet string. HMAC- 570 SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20- 571 octet digest. 572 573 574 575 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 9, 2006 [Page 11] 616 617Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 618 619 6207. Key Strength Negotiation 621 622 A Kerberos client and server can negotiate over key length if they 623 are using mutual authentication. If the client is unable to perform 624 full strength encryption, it may propose a key in the "subkey" field 625 of the authenticator, using a weaker encryption type. The server 626 must then either return the same key or suggest its own key in the 627 subkey field of the AP reply message. The key used to encrypt data 628 is derived from the key returned by the server. If the client is 629 able to perform strong encryption but the server is not, it may 630 propose a subkey in the AP reply without first being sent a subkey in 631 the authenticator. 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Jaganathan, et al. Expires January 9, 2006 [Page 12] 672 673Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 674 675 6768. GSSAPI Kerberos V5 Mechanism Type 677 6788.1 Mechanism Specific Changes 679 680 The GSSAPI per-message tokens also require new checksum and 681 encryption types. The GSS-API per-message tokens are adapted to 682 support these new encryption types. See [RFC1964] Section 1.2.2. 683 684 The only support quality of protection is: 685 686 #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 687 688 When using this RC4 based encryption type, the sequence number is 689 always sent in big-endian rather than little-endian order. 690 691 The Windows 2000 implementation also defines new GSSAPI flags in the 692 initial token passed when initializing a security context. These 693 flags are passed in the checksum field of the authenticator. See 694 [RFC1964] Section 1.1.1. 695 696 GSS_C_DCE_STYLE - This flag was added for use with Microsoft's 697 implementation of DCE RPC, which initially expected three legs of 698 authentication. Setting this flag causes an extra AP reply to be 699 sent from the client back to the server after receiving the server's 700 AP reply. In addition, the context negotiation tokens do not have 701 GSSAPI per message tokens - they are raw AP messages that do not 702 include object identifiers. 703 704 #define GSS_C_DCE_STYLE 0x1000 705 706 GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 707 server that it should only allow the server application to identify 708 the client by name and ID, but not to impersonate the client. 709 710 #define GSS_C_IDENTIFY_FLAG 0x2000 711 712 GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 713 client wants to be informed of extended error information. In 714 particular, Windows 2000 status codes may be returned in the data 715 field of a Kerberos error message. This allows the client to 716 understand a server failure more precisely. In addition, the server 717 may return errors to the client that are normally handled at the 718 application layer in the server, in order to let the client try to 719 recover. After receiving an error message, the client may attempt to 720 resubmit an AP request. 721 722 #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 723 724 725 726 727Jaganathan, et al. Expires January 9, 2006 [Page 13] 728 729Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 730 731 732 These flags are only used if a client is aware of these conventions 733 when using the SSPI on the Windows platform; they are not generally 734 used by default. 735 736 When NetBIOS addresses are used in the GSSAPI, they are identified by 737 the GSS_C_AF_NETBIOS value. This value is defined as: 738 739 #define GSS_C_AF_NETBIOS 0x14 740 741 NetBios addresses are 16-octet addresses typically composed of 1 to 742 15 characters, trailing blank (ASCII char 20) filled, with a 16-th 743 octet of 0x0. 744 7458.2 GSSAPI MIC Semantics 746 747 The GSSAPI checksum type and algorithm is defined in Section 5. Only 748 the first 8 octets of the checksum are used. The resulting checksum 749 is stored in the SGN_CKSUM field . See [RFC1964] Section 1.2 for 750 GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 751 752 The GSS_GetMIC token has the following format: 753 754 Byte no Name Description 755 0..1 TOK_ID Identification field. 756 Tokens emitted by GSS_GetMIC() contain 757 the hex value 01 01 in this field. 758 2..3 SGN_ALG Integrity algorithm indicator. 759 11 00 - HMAC 760 4..7 Filler Contains ff ff ff ff 761 8..15 SND_SEQ Sequence number field. 762 16..23 SGN_CKSUM Checksum of "to-be-signed data", 763 calculated according to algorithm 764 specified in SGN_ALG field. 765 766 The MIC mechanism used for GSS MIC based messages is as follow: 767 768 GetMIC(Kss, direction, export, seq_num, data) 769 { 770 struct Token { 771 struct Header { 772 OCTET TOK_ID[2]; 773 OCTET SGN_ALG[2]; 774 OCTET Filler[4]; 775 }; 776 OCTET SND_SEQ[8]; 777 OCTET SGN_CKSUM[8]; 778 } Token; 779 780 781 782 783Jaganathan, et al. Expires January 9, 2006 [Page 14] 784 785Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 786 787 788 Token.TOK_ID = 01 01; 789 Token.SGN_SLG = 11 00; 790 Token.Filler = ff ff ff ff; 791 792 // Create the sequence number 793 794 if (direction == sender_is_initiator) 795 { 796 memset(Token.SEND_SEQ+4, 0xff, 4) 797 } 798 else if (direction == sender_is_acceptor) 799 { 800 memset(Token.SEND_SEQ+4, 0, 4) 801 } 802 Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; 803 Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; 804 Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; 805 Token.SEND_SEQ[3] = (seq_num & 0x000000ff); 806 807 // Derive signing key from session key 808 809 Ksign = HMAC(Kss, "signaturekey"); 810 // length includes terminating null 811 812 // Generate checksum of message - SGN_CKSUM 813 // Key derivation salt = 15 814 815 Sgn_Cksum = MD5((int32)15, Token.Header, data); 816 817 // Save first 8 octets of HMAC Sgn_Cksum 818 819 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 820 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 821 822 // Encrypt the sequence number 823 824 // Derive encryption key for the sequence number 825 // Key derivation salt = 0 826 827 if (exportable) 828 { 829 Kseq = HMAC(Kss, "fortybits", (int32)0); 830 // len includes terminating null 831 memset(Kseq+7, 0xab, 7) 832 } 833 else 834 { 835 Kseq = HMAC(Kss, (int32)0); 836 837 838 839Jaganathan, et al. Expires January 9, 2006 [Page 15] 840 841Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 842 843 844 } 845 Kseq = HMAC(Kseq, Token.SGN_CKSUM); 846 847 // Encrypt the sequence number 848 849 RC4(Kseq, Token.SND_SEQ); 850 } 851 852 8538.3 GSSAPI WRAP Semantics 854 855 There are two encryption keys for GSSAPI message tokens, one that is 856 128 bits in strength, and one that is 56 bits in strength as defined 857 in Section 6. 858 859 All padding is rounded up to 1 byte. One byte is needed to say that 860 there is 1 byte of padding. The DES based mechanism type uses 8 byte 861 padding. See [RFC1964] Section 1.2.2.3. 862 863 The RC4-HMAC GSS_Wrap() token has the following format: 864 865 866 Byte no Name Description 867 0..1 TOK_ID Identification field. 868 Tokens emitted by GSS_Wrap() contain 869 the hex value 02 01 in this field. 870 2..3 SGN_ALG Checksum algorithm indicator. 871 11 00 - HMAC 872 4..5 SEAL_ALG ff ff - none 873 00 00 - DES-CBC 874 10 00 - RC4 875 6..7 Filler Contains ff ff 876 8..15 SND_SEQ Encrypted sequence number field. 877 16..23 SGN_CKSUM Checksum of plaintext padded data, 878 calculated according to algorithm 879 specified in SGN_ALG field. 880 24..31 Confounder Random confounder 881 32..last Data encrypted or plaintext padded data 882 883 The encryption mechanism used for GSS wrap based messages is as 884 follow: 885 886 887 WRAP(Kss, encrypt, direction, export, seq_num, data) 888 { 889 struct Token { // 32 octets 890 struct Header { 891 OCTET TOK_ID[2]; 892 893 894 895Jaganathan, et al. Expires January 9, 2006 [Page 16] 896 897Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 898 899 900 OCTET SGN_ALG[2]; 901 OCTET SEAL_ALG[2]; 902 OCTET Filler[2]; 903 }; 904 OCTET SND_SEQ[8]; 905 OCTET SGN_CKSUM[8]; 906 OCTET Confounder[8]; 907 } Token; 908 909 910 Token.TOK_ID = 02 01; 911 Token.SGN_SLG = 11 00; 912 Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00; 913 Token.Filler = ff ff; 914 915 // Create the sequence number 916 917 if (direction == sender_is_initiator) 918 { 919 memset(&Token.SEND_SEQ[4], 0xff, 4) 920 } 921 else if (direction == sender_is_acceptor) 922 { 923 memset(&Token.SEND_SEQ[4], 0, 4) 924 } 925 Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; 926 Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; 927 Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; 928 Token.SEND_SEQ[3] = (seq_num & 0x000000ff); 929 930 // Generate random confounder 931 932 nonce(&Token.Confounder, 8); 933 934 // Derive signing key from session key 935 936 Ksign = HMAC(Kss, "signaturekey"); 937 938 // Generate checksum of message - 939 // SGN_CKSUM + Token.Confounder 940 // Key derivation salt = 15 941 942 Sgn_Cksum = MD5((int32)15, Token.Header, 943 Token.Confounder); 944 945 // Derive encryption key for data 946 // Key derivation salt = 0 947 948 949 950 951Jaganathan, et al. Expires January 9, 2006 [Page 17] 952 953Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 954 955 956 for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0; 957 // XOR 958 if (exportable) 959 { 960 Kcrypt = HMAC(Klocal, "fortybits", (int32)0); 961 // len includes terminating null 962 memset(Kcrypt+7, 0xab, 7); 963 } 964 else 965 { 966 Kcrypt = HMAC(Klocal, (int32)0); 967 } 968 969 // new encryption key salted with seq 970 971 Kcrypt = HMAC(Kcrypt, (int32)seq); 972 973 // Encrypt confounder (if encrypting) 974 975 if (encrypt) 976 RC4(Kcrypt, Token.Confounder); 977 978 // Sum the data buffer 979 980 Sgn_Cksum += MD5(data); // Append to checksum 981 982 // Encrypt the data (if encrypting) 983 984 if (encrypt) 985 RC4(Kcrypt, data); 986 987 // Save first 8 octets of HMAC Sgn_Cksum 988 989 Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 990 memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 991 992 // Derive encryption key for the sequence number 993 // Key derivation salt = 0 994 995 if (exportable) 996 { 997 Kseq = HMAC(Kss, "fortybits", (int32)0); 998 // len includes terminating null 999 memset(Kseq+7, 0xab, 7) 1000 } 1001 else 1002 { 1003 Kseq = HMAC(Kss, (int32)0); 1004 1005 1006 1007Jaganathan, et al. Expires January 9, 2006 [Page 18] 1008 1009Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 1010 1011 1012 } 1013 Kseq = HMAC(Kseq, Token.SGN_CKSUM); 1014 1015 // Encrypt the sequence number 1016 1017 RC4(Kseq, Token.SND_SEQ); 1018 1019 // Encrypted message = Token + Data 1020 } 1021 1022 The character constant "fortybits" evolved from the time when a 40- 1023 bit key length was all that was exportable from the United States. 1024 It is now used to recognize that the key length is of "exportable" 1025 length. In this description, the key size is actually 56-bits. 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063Jaganathan, et al. Expires January 9, 2006 [Page 19] 1064 1065Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 1066 1067 10689. Security Considerations 1069 1070 Care must be taken in implementing this encryption type because it 1071 uses a stream cipher. If a different IV isn't used in each direction 1072 when using a session key, the encryption is weak. By using the 1073 sequence number as an IV, this is avoided. 1074 107510. Normative References 1076 1077 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 1078 April 1992. 1079 1080 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1081 April 1992. 1082 1083 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 1084 Authentication Service (V5)", RFC 1510, September 1993. 1085 1086 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1087 RFC 1964, June 1996. 1088 1089 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1090 Hashing for Message Authentication", RFC 2104, 1091 February 1997. 1092 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1095 1096 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1097 Kerberos 5", RFC 3961, February 2005. 1098 1099 1100Authors' Addresses 1101 1102 Karthik Jaganathan 1103 Microsoft Corporation 1104 One Microsoft Way 1105 Redmond, WA 98052 1106 US 1107 1108 Email: karthikj@microsoft.com 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119Jaganathan, et al. Expires January 9, 2006 [Page 20] 1120 1121Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 1122 1123 1124 Larry Zhu 1125 Microsoft Corporation 1126 One Microsoft Way 1127 Redmond, WA 98052 1128 US 1129 1130 Email: lzhu@microsoft.com 1131 1132 1133 John Brezak 1134 Microsoft Corporation 1135 One Microsoft Way 1136 Redmond, WA 98052 1137 US 1138 1139 Email: jbrezak@microsoft.com 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175Jaganathan, et al. Expires January 9, 2006 [Page 21] 1176 1177Internet-Draft The RC4-HMAC Kerberos encryption type July 2005 1178 1179 1180Intellectual Property Statement 1181 1182 The IETF takes no position regarding the validity or scope of any 1183 Intellectual Property Rights or other rights that might be claimed to 1184 pertain to the implementation or use of the technology described in 1185 this document or the extent to which any license under such rights 1186 might or might not be available; nor does it represent that it has 1187 made any independent effort to identify any such rights. Information 1188 on the procedures with respect to rights in RFC documents can be 1189 found in BCP 78 and BCP 79. 1190 1191 Copies of IPR disclosures made to the IETF Secretariat and any 1192 assurances of licenses to be made available, or the result of an 1193 attempt made to obtain a general license or permission for the use of 1194 such proprietary rights by implementers or users of this 1195 specification can be obtained from the IETF on-line IPR repository at 1196 http://www.ietf.org/ipr. 1197 1198 The IETF invites any interested party to bring to its attention any 1199 copyrights, patents or patent applications, or other proprietary 1200 rights that may cover technology that may be required to implement 1201 this standard. Please address the information to the IETF at 1202 ietf-ipr@ietf.org. 1203 1204 1205Disclaimer of Validity 1206 1207 This document and the information contained herein are provided on an 1208 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1209 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1210 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1211 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1212 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1214 1215 1216Copyright Statement 1217 1218 Copyright (C) The Internet Society (2005). This document is subject 1219 to the rights, licenses and restrictions contained in BCP 78, and 1220 except as set forth therein, the authors retain all their rights. 1221 1222 1223Acknowledgment 1224 1225 Funding for the RFC Editor function is currently provided by the 1226 Internet Society. 1227 1228 1229 1230 1231Jaganathan, et al. Expires January 9, 2006 [Page 22] 1232 1233 1234