1 2 3 4 5 6 7Network Working Group Jonathan Trostle 8INTERNET-DRAFT Cisco Systems 9Category: Standards Track Mike Swift 10 University of WA 11 John Brezak 12 Microsoft 13 Bill Gossman 14 Cisco Systems 15 16 17 Kerberos Set/Change Password: Version 2 18 <draft-ietf-cat-kerberos-set-passwd-06.txt> 19 20 21 22 23Status of this Memo 24 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026 [6]. 27 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 32 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet- Drafts as reference 36 material or to cite them other than as "work in progress." 37 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 40 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 43 44 This draft expires on December 31st, 2001. Please send comments to 45 the authors. 46 471. Abstract 48 49 This proposal specifies a Kerberos (RFC 1510 [3]) change/set password 50 protocol and a Kerberos change/set key protocol. The protocol 51 consists of a single request and reply message. The request message 52 includes both AP-REQ and KRB-PRIV submessages; the new password is 53 contained in the KRB-PRIV submessage which is encrypted in the 54 subsession key from the AP-REQ. The original Kerberos change password 55 protocol did not allow for an administrator to set a password for a 56 new user. This functionality is useful in some environments, and this 57 proposal allows password setting as well as password changing. The 58 protocol includes fields in the request message to indicate the 59 principal which is having its password set. We also extend the 60 set/change protocol to allow a client to send a sequence of keys to 61 62 63 64Trostle, Swift, Brezak, Gossman [Page 1] 65 66INTERNET DRAFT June 2001 Expires December 2001 67 68 69 the KDC instead of a cleartext password. If in the cleartext password 70 case, the cleartext password fails to satisfy password policy, the 71 server should use the result code KRB5_KPASSWD_POLICY_REJECT. 72 732. Conventions used in this document 74 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC2119 [7]. 78 793. Definitions from RFC 1510 80 81 We include some of the relevant ASN.1 definitions from RFC 1510 in 82 this section. 83 84 Realm ::= GeneralString 85 86 PrincipalName ::= SEQUENCE { 87 name-type[0] INTEGER, 88 name-string[1] SEQUENCE OF GeneralString 89 } 90 91 KerberosTime ::= GeneralizedTime 92 -- Specifying UTC time zone (Z) 93 94 HostAddress ::= SEQUENCE { 95 addr-type[0] INTEGER, 96 address[1] OCTET STRING 97 } 98 99 EncryptedData ::= SEQUENCE { 100 etype[0] INTEGER, -- EncryptionType 101 kvno[1] INTEGER OPTIONAL, 102 cipher[2] OCTET STRING -- ciphertext 103 } 104 105 EncryptionKey ::= SEQUENCE { 106 keytype[0] INTEGER, 107 keyvalue[1] OCTET STRING 108 } 109 110 Checksum ::= SEQUENCE { 111 cksumtype[0] INTEGER, 112 checksum[1] OCTET STRING 113 } 114 115 116 AP-REQ ::= [APPLICATION 14] SEQUENCE { 117 pvno [0] INTEGER, -- indicates Version 5 118 msg-type [1] INTEGER, -- indicates KRB_AP_REQ 119 ap-options[2] APOptions, 120 ticket[3] Ticket, 121 authenticator[4] EncryptedData 122 } 123 124 125 126Trostle, Swift, Brezak, Gossman [Page 2] 127 128INTERNET DRAFT June 2001 Expires December 2001 129 130 131 APOptions ::= BIT STRING { 132 133 reserved (0), 134 use-session-key (1), 135 mutual-required (2) 136 } 137 138 Ticket ::= [APPLICATION 1] SEQUENCE { 139 tkt-vno [0] INTEGER, -- indicates Version 5 140 realm [1] Realm, 141 sname [2] PrincipalName, 142 enc-part [3] EncryptedData 143 } 144 145 146 -- Encrypted part of ticket 147 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 148 flags[0] TicketFlags, 149 key[1] EncryptionKey, 150 crealm[2] Realm, 151 cname[3] PrincipalName, 152 transited[4] TransitedEncoding, 153 authtime[5] KerberosTime, 154 starttime[6] KerberosTime OPTIONAL, 155 endtime[7] KerberosTime, 156 renew-till[8] KerberosTime OPTIONAL, 157 caddr[9] HostAddresses OPTIONAL, 158 authorization-data[10] AuthorizationData OPTIONAL 159 } 160 161 -- Unencrypted authenticator 162 Authenticator ::= [APPLICATION 2] SEQUENCE { 163 authenticator-vno[0] INTEGER, 164 crealm[1] Realm, 165 cname[2] PrincipalName, 166 cksum[3] Checksum OPTIONAL, 167 cusec[4] INTEGER, 168 ctime[5] KerberosTime, 169 subkey[6] EncryptionKey OPTIONAL, 170 seq-number[7] INTEGER OPTIONAL, 171 authorization-data[8] AuthorizationData OPTIONAL 172 } 173 174 AP-REP ::= [APPLICATION 15] SEQUENCE { 175 pvno [0] INTEGER, -- represents Kerberos V5 176 msg-type [1] INTEGER, -- represents KRB_AP_REP 177 enc-part [2] EncryptedData 178 } 179 180 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 181 ctime [0] KerberosTime, 182 cusec [1] INTEGER, 183 subkey [2] EncryptionKey OPTIONAL, 184 seq-number [3] INTEGER OPTIONAL 185 186 187 188Trostle, Swift, Brezak, Gossman [Page 3] 189 190INTERNET DRAFT June 2001 Expires December 2001 191 192 193 } 194 195 Here is the syntax of the KRB-ERROR message: 196 197 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 198 pvno[0] INTEGER, 199 msg-type[1] INTEGER, 200 ctime[2] KerberosTime OPTIONAL, 201 cusec[3] INTEGER OPTIONAL, 202 stime[4] KerberosTime, 203 susec[5] INTEGER, 204 error-code[6] INTEGER, 205 crealm[7] Realm OPTIONAL, 206 cname[8] PrincipalName OPTIONAL, 207 realm[9] Realm, -- Correct realm 208 sname[10] PrincipalName, -- Correct name 209 e-text[11] GeneralString OPTIONAL, 210 e-data[12] OCTET STRING OPTIONAL 211 } 212 213 The KRB-PRIV message is used to send the request and reply data: 214 215 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 216 pvno[0] INTEGER, 217 msg-type[1] INTEGER, 218 enc-part[3] EncryptedData 219 } 220 221 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 222 user-data[0] OCTET STRING, 223 timestamp[1] KerberosTime OPTIONAL, 224 usec[2] INTEGER OPTIONAL, 225 seq-number[3] INTEGER OPTIONAL, 226 s-address[4] HostAddress, 227 -- sender's addr 228 r-address[5] HostAddress OPTIONAL 229 -- recip's addr 230 } 231 232 2334. The Protocol 234 235 The service SHOULD accept requests on UDP port 464 and TCP port 464 236 as well. Use of other ports can significantly increase the complexity 237 and size of IPSEC policy rulesets in organizations that have IPSEC 238 capable nodes. 239 240 The protocol consists of a single request message followed by a 241 single reply message. For UDP transport, each message must be fully 242 contained in a single UDP packet. 243 244 For TCP transport, there is a 4 octet header in network byte order 245 that precedes the message and specifies the length of the message. 246 This requirement is consistent with the TCP transport header in 247 248 249 250Trostle, Swift, Brezak, Gossman [Page 4] 251 252INTERNET DRAFT June 2001 Expires December 2001 253 254 255 1510bis. 256 257 258 259 Request Message 260 261 0 1 2 3 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | message length | protocol version number | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | AP-REQ length | AP-REQ data / 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 / KRB-PRIV message / 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 271 All 16 bit fields are in network byte order. 272 273 message length field: contains the number of bytes in the message 274 including this field. 275 276 protocol version number: contains the hex constant 0x0002 (network 277 byte order). 278 279 AP-REQ length: length of AP-REQ data, in bytes. If the length is 280 zero, then the last field contains a KRB-ERROR message instead of a 281 KRB-PRIV message. 282 283 AP-REQ data: (see [3]) For a change password/key request, the AP-REQ 284 message service ticket sname, srealm principal identifier is 285 kadmin/changepw@REALM where REALM is the realm of the change password 286 service. The same applies to a set password/key request except the 287 principal identifier is kadmin/setpw@REALM. The authenticator in the 288 AP-REQ MUST contain a subsession key (which will be used to encrypt 289 the KRB-PRIV user data field - see below). The KDC may have stronger 290 pseudorandom generating capability then the clients; thus, the client 291 SHOULD use the session key as an input (along with additional locally 292 pseudorandom generated bits) into the generation of the subsession 293 key. To enable setting of passwords/keys, it is not required that the 294 initial flag be set in the Kerberos service ticket. The initial flag 295 is required for change requests, but not for set requests. We have 296 the following definitions: 297 298 old passwd initial flag target principal can be 299 in request? required? distinct from 300 authenticating principal? 301 302 change password: yes yes no 303 304 set password: no policy (*) yes 305 306 set key: no policy (*) yes 307 308 change key: no yes no 309 310 311 312Trostle, Swift, Brezak, Gossman [Page 5] 313 314INTERNET DRAFT June 2001 Expires December 2001 315 316 317 policy (*): implementations SHOULD allow administrators to set the 318 initial flag required for set requests policy to either yes or no. 319 Clients MUST be able to retry set requests that fail due to error 7 320 (initial flag required) with an initial ticket. Clients SHOULD NOT 321 cache service tickets targetted at kadmin/changepw. 322 323 KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted 324 using the subsession key from the authenticator in the AP-REQ. The 325 authenticator MUST contain a subsession key. The timestamp and usec 326 fields of the KRB-PRIV message MUST be present, and the data values 327 MUST be copies of the same data values from the authenticator. The 328 recipient should ignore the sender address field in the KRB-PRIV 329 message. 330 331 The user-data component of the message contains the DER encoding of 332 the ChangePasswdData ASN.1 type described below: 333 334 ChangePasswdData ::= SEQUENCE { 335 passwds [0] PasswordSequence OPTIONAL, 336 keys [1] KeySequences OPTIONAL, 337 -- exactly one of the above two will be 338 -- present, else KRB5_KPASSWD_MALFORMED 339 -- error will be returned by the server. 340 targname[2] PrincipalName OPTIONAL, 341 -- only present in set password/key: the 342 -- principal which will have its password 343 -- or keys set. Not present in a set request 344 -- if the client principal from the ticket is 345 -- the principal having its passwords or keys 346 -- set. 347 targrealm[3] Realm OPTIONAL, 348 -- only present in set password/key: the realm 349 -- for the principal which will have its 350 -- password or keys set. Not present in a set 351 -- request if the client principal from the 352 -- ticket is the principal having its 353 -- passwords or keys set. 354 flags[4] RequestFlags OPTIONAL 355 -- 32 bit string 356 } 357 358 KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence 359 360 KeySequence ::= SEQUENCE { 361 key[0] EncryptionKey, 362 salt[1] OCTET STRING OPTIONAL, 363 -- depends on enc type, not currently used 364 salt-type[2] INTEGER OPTIONAL 365 -- depends on enc type, not currently used 366 } 367 368 PasswordSequence ::= SEQUENCE { 369 newpasswd[0] OCTET STRING, 370 oldpasswd[1] OCTET STRING OPTIONAL 371 372 373 374Trostle, Swift, Brezak, Gossman [Page 6] 375 376INTERNET DRAFT June 2001 Expires December 2001 377 378 379 -- oldpasswd always present for change 380 -- password but not present for set 381 -- password, set key, or change key 382 -- NOTE: the passwords are UTF8 strings. 383 } 384 385 RequestFlags ::= BIT STRING (SIZE (32..MAX)) 386 -- reserved(0) 387 -- request-srv-gen-keys(1) 388 -- only in change/set keys 389 -- if the client desires 390 -- server to contribute to 391 -- keys; 392 -- server will return keys 393 394 395 The server must verify the AP-REQ message, check whether the client 396 principal in the ticket is authorized to set/change the password/keys 397 (either for that principal, or for the principal in the targname 398 field if present), and decrypt the new password/keys. The server also 399 checks whether the initial flag is required for this request, 400 replying with status 0x0007 if it is not set and should be. An 401 authorization failure is cause to respond with status 0x0005. For 402 forward compatibility, the server should be prepared to ignore fields 403 after targrealm in the structure that it does not understand. 404 405 If the passwds field is present, it contains the new cleartext 406 password (with the old cleartext password for a change password 407 operation). Otherwise the keys field is present, and it contains a 408 sequence of encryption keys. 409 410 In the cleartext password case, if the old password is sent in the 411 request, the request MUST be a change password request. If the old 412 password is not present in the request, the request MUST be a set 413 password request. The server should apply policy checks to the old 414 and new password after verifying that the old password is valid. The 415 server can check validity by obtaining a key from the old password 416 with a keytype that is present in the KDC database for the user and 417 comparing the keys for equality. The server then generates the 418 appropriate keytypes from the password and stores them in the KDC 419 database. If all goes well, status 0x0000 is returned to the client 420 in the reply message (see below). For a change password operation, 421 the initial flag in the service ticket MUST be set. 422 423 In the key sequence case, the sequence of keys is sent to the change 424 or set password service (kadmin/changepw or kadmin/setpw 425 respectively). For a principal that can act as a server, its 426 preferred keytype should be sent as the first key in the sequence, 427 but the KDC is not required to honor this preference. Application 428 servers SHOULD use the key sequence option for changing/setting their 429 keys. The change/set password services should check that all keys are 430 in the proper format, returning the KRB5_KPASSWD_MALFORMED error 431 otherwise. 432 433 434 435 436Trostle, Swift, Brezak, Gossman [Page 7] 437 438INTERNET DRAFT June 2001 Expires December 2001 439 440 441 For change/set key, the request message may include the request flags 442 bit string with the request-srv-gen-keys bit set. In this case, the 443 client is requesting that the server add entropy to its keys in the 444 KeySequences field. When using this option, the client SHOULD attempt 445 to generate pseudorandom keys with as much entropy as possible in its 446 request. The server will return the final key sequence in a 447 KeySequences structure in the edata of the reply message. The server 448 does not store any of the new keys at this point. The client MUST 449 make a subsequent change/set key request without the request-srv- 450 gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this 451 second request, then the new keys have been written into the 452 database. A conformant server MUST support this option. 453 454 455 456 457 458 459 460 Reply Message 461 462 0 1 2 3 463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | message length | protocol version number | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | AP-REP length | AP-REP data / 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 / KRB-PRIV message / 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 472 All 16 bit fields are in network byte order. 473 474 message length field: contains the number of bytes in the message 475 including this field. 476 477 protocol version number: contains the hex constant 0x0002 (network 478 byte order). (The reply message has the same format as in the 479 original Kerberos change password protocol). 480 481 AP-REP length: length of AP-REP data, in bytes. If the length is 482 zero, then the last field contains a KRB-ERROR message instead of a 483 KRB-PRIV message. An implementation should check this field to 484 determine whether a KRB-ERROR message or KRB-PRIV message has been 485 returned. 486 487 AP-REP data: the AP-REP is the response to the AP-REQ in the request 488 packet. The subkey MUST be present in the AP-REP message. 489 490 KRB-PRIV message: This KRB-PRIV message must be encrypted using the 491 subkey from the AP-REP message. The client should ignore the sender 492 address (the server's address) in the KRB-PRIV message. Reflection 493 attacks are prevented since the subkey is used to encrypt the user- 494 data field of the KRB-PRIV message. The timestamp and usec fields of 495 496 497 498Trostle, Swift, Brezak, Gossman [Page 8] 499 500INTERNET DRAFT June 2001 Expires December 2001 501 502 503 the KRB-PRIV message MUST be present, and the data values MUST be 504 copies of the same data values from the AP-REP message. 505 506 The server will respond with a KRB-PRIV message unless it cannot 507 validate the client AP-REQ or KRB-PRIV message, in which case it will 508 respond with a KRB-ERROR message. 509 510 The user-data component of the KRB-PRIV message, or e-data component 511 of the KRB-ERROR message, must consist of the following data. 512 513 0 1 2 3 514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | result code | key version (only on success) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | result string length | result string / 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | edata / 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 523 result code (16 bits) (result codes 0-4 are the same as in the 524 original Kerberos change password protocol): 525 526 The result code must have one of the following values (network 527 byte order): 528 529 KRB5_KPASSWD_SUCCESS 0 request succeeds (This 530 value is not allowed in a 531 KRB-ERROR message) 532 533 KRB5_KPASSWD_MALFORMED 1 request fails due to being 534 malformed 535 536 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" 537 error in processing the 538 request (for example, there 539 is a resource or other 540 problem causing the request 541 to fail) 542 543 KRB5_KPASSWD_AUTHERROR 3 request fails due to an 544 error in authentication 545 processing 546 547 KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft 548 error in processing the 549 request 550 551 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized 552 553 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported 554 555 KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required 556 557 558 559 560Trostle, Swift, Brezak, Gossman [Page 9] 561 562INTERNET DRAFT June 2001 Expires December 2001 563 564 565 KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails 566 policy; the result string 567 should include a text 568 message to be presented to 569 the user. 570 571 KRB5_KPASSWD_WRONG_SRV 9 policy failure: the client 572 sent change/set key and 573 should have sent change/set 574 passwd, or vice-versa. 575 576 KRB5_KPASSWD_BAD_PRINCIPAL 10 target principal does not 577 exist (only in response to 578 a set password or set key 579 request). 580 581 KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence 582 containing at least one etype that 583 is not supported by the KDC. The 584 response edata contains an ASN.1 585 DER encoded PKERB-ETYPE-INFO type 586 that specifies the etypes that the 587 KDC supports: 588 589 KERB-ETYPE-INFO-ENTRY :: = SEQUENCE 590 { 591 encryption-type[0] INTEGER, 592 salt[1] OCTET STRING 593 OPTIONAL -- not sent, client 594 -- may ignore if 595 -- sent 596 } 597 598 PKERB-ETYPE-INFO ::= SEQUENCE OF 599 KERB-ETYPE-INFO-ENTRY 600 601 The client should retry the request 602 using only etypes (keytypes) that 603 are contained within the 604 PKERB-ETYPE-INFO structure in the 605 previous response. 606 607 KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph. 608 609 610 The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when 611 the request has the request-srv-gen-keys flag set and the 612 server is returning the KeySequences structure defined above in 613 the edata field of the reply. The server returns one key sequence 614 structure of the same keytype for each key sequence structure in 615 the client request, unless it does not support one of the 616 keytypes (or etypes). In that case, it returns error 617 KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST 618 add keylength number of bits of entropy to each key, where 619 620 621 622Trostle, Swift, Brezak, Gossman [Page 10] 623 624INTERNET DRAFT June 2001 Expires December 2001 625 626 627 keylength is the number of actual key bits in the key (minus 628 any parity or non-entropy contributing bits). The assumption 629 here is that the client may have added insufficient entropy 630 to the request keys. The server SHOULD use the client key from 631 each KeySequence structure as input into the final keyvalue for 632 the returned key. The client MUST make another request after 633 receiving a reply with this status, since no keys have been 634 written into the database. 635 636 0xFFFF is returned if the request fails for some other reason. 637 The client must interpret any non-zero result code as a failure. 638 639 key version (16 bits - optional): 640 Present if and only if the result 641 code is KRB5_KPASSWD_SUCCESS. This contains the key version of 642 the new key(s). 643 644 result string length (16 bits): 645 Gives the length of the following result string field, in bytes. 646 If the result string is not present, the length is zero. 647 648 result string (optional): 649 This field is a UTF-8 encoded string which can be displayed 650 to the user. Specific reasons for a password set/change policy 651 failure is one possible use for this string. 652 653 edata (optional): 654 Used to convey additional information as defined by the 655 result code. 656 6575. Acknowledgements 658 659 The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony 660 Andrea, Nicolas Williams, and other participants from the IETF 661 Kerberos Working Group for their input to the document. 662 6636. Security Considerations 664 665 Password policies should be enforced to make sure that users do not 666 pick passwords (for change password/key) that are vulnerable to brute 667 force password guessing attacks. 668 6697. References 670 671 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 672 9, RFC 2026, October 1996. 673 674 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 675 Levels", BCP 14, RFC 2119, March 1997 676 677 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication 678 Service (V5), Request for Comments 1510. 679 680 681 682 683 684Trostle, Swift, Brezak, Gossman [Page 11] 685 686INTERNET DRAFT June 2001 Expires December 2001 687 688 6898. Expiration Date 690 691 This draft expires on December 31st, 2001. 692 6939. Authors' Addresses 694 695 Jonathan Trostle 696 Cisco Systems 697 170 W. Tasman Dr. 698 San Jose, CA 95134 699 Email: jtrostle@cisco.com 700 701 Mike Swift 702 University of Washington 703 Seattle, WA 704 Email: mikesw@cs.washington.edu 705 706 John Brezak 707 Microsoft 708 1 Microsoft Way 709 Redmond, WA 98052 710 Email: jbrezak@microsoft.com 711 712 Bill Gossman 713 Cisco Systems 714 500 108th Ave. NE, Suite 500 715 Bellevue, WA 98004 716 Email: bgossman@cisco.com 717 71810. Full Copyright Statement 719 720 Copyright (C) The Internet Society (2001). All Rights Reserved. 721 722 This document and translations of it may be copied and furnished to 723 others, and derivative works that comment on or otherwise explain it 724 or assist in its implmentation may be prepared, copied, published and 725 distributed, in whole or in part, without restriction of any kind, 726 provided that the above copyright notice and this paragraph are 727 included on all such copies and derivative works. However, this 728 document itself may not be modified in any way, such as by removing 729 the copyright notice or references to the Internet Society or other 730 Internet organizations, except as needed for the purpose of 731 developing Internet standards in which case the procedures for 732 copyrights defined in the Internet Standards process must be 733 followed, or as required to translate it into languages other than 734 English. 735 736 The limited permissions granted above are perpetual and will not be 737 revoked by the Internet Society or its successors or assigns. 738 739 This document and the information contained herein is provided on an 740 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 741 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 742 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 743 744 745 746Trostle, Swift, Brezak, Gossman [Page 12] 747 748INTERNET DRAFT June 2001 Expires December 2001 749 750 751 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 752 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808Trostle, Swift, Brezak, Gossman [Page 13] 809 810