1 2 3Kerberos working group M. Swift 4 U.Washington 5Internet Draft J. Brezak 6Document: draft-brezak-win2k-krb-rc4-hmac-04.txt Microsoft 7Category: Informational May 2002 8 9 10 The Microsoft Windows 2000 RC4-HMAC Kerberos encryption type 11 12 13Status 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 311. 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 562. Conventions used in this document 57 58Swift 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 753. 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 1034. 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 124Swift 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 190Swift Category - Informational 3 191 192 193 194 195 196 197 198 199 Windows 2000 RC4-HMAC Kerberos E-Type May 2002 200 201 2025. 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 2206. 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 256Swift 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 322Swift 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 3427. 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 3558. GSSAPI Kerberos V5 Mechanism Type 356 3578.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 388Swift 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 4238.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 454Swift 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 520Swift 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 5418.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 586Swift 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 652Swift 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 7169. Security Considerations 717 718Swift 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 73610. 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 74111. 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 77912. Author's Addresses 780 781 Mike Swift 782 Dept. of Computer Science 783 784Swift 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 850Swift Category - Informational 13 851 852 853 854 855 856 857 858 859 Windows 2000 RC4-HMAC Kerberos E-Type October 1999 860 861 862 86313. 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 916Swift Category - Informational 14 917 918 919 920 921 922 923 924