1 2 3 4NETWORK WORKING GROUP L. Zhu 5Internet-Draft K. Jaganathan 6Updates: 4120 (if approved) Microsoft Corporation 7Expires: January 20, 2006 July 19, 2005 8 9 10 Generating KDC Referrals to locate Kerberos realms 11 draft-ietf-krb-wg-kerberos-referrals-06 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on January 20, 2006. 37 38Copyright Notice 39 40 Copyright (C) The Internet Society (2005). 41 42Abstract 43 44 The memo documents a method for a Kerberos Key Distribution Center 45 (KDC) to respond to client requests for Kerberos tickets when the 46 client does not have detailed configuration information on the realms 47 of users or services. The KDC will handle requests for principals in 48 other realms by returning either a referral error or a cross-realm 49 TGT to another realm on the referral path. The clients will use this 50 referral information to reach the realm of the target principal and 51 then receive the ticket. 52 53 54 55Zhu & Jaganathan Expires January 20, 2006 [Page 1] 56 57Internet-Draft KDC Referrals July 2005 58 59 60Table of Contents 61 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . 4 64 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . 4 65 4. Realm Organization Model . . . . . . . . . . . . . . . . . . 5 66 5. Client Name Canonicalization . . . . . . . . . . . . . . . . 5 67 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . 9 70 9. Compatibility with Earlier Implementations of Name 71 Canonicalization . . . . . . . . . . . . . . . . . . . . . . 9 72 10. Security Considerations . . . . . . . . . . . . . . . . . . 10 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 12.1 Normative References . . . . . . . . . . . . . . . . . . 11 76 12.2 Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 78 Intellectual Property and Copyright Statements . . . . . . . 13 79 80 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 111Zhu & Jaganathan Expires January 20, 2006 [Page 2] 112 113Internet-Draft KDC Referrals July 2005 114 115 1161. Introduction 117 118 Current implementations of the Kerberos AS and TGS protocols, as 119 defined in [RFC4120], use principal names constructed from a known 120 user or service name and realm. A service name is typically 121 constructed from a name of the service and the DNS host name of the 122 computer that is providing the service. Many existing deployments of 123 Kerberos use a single Kerberos realm where all users and services 124 would be using the same realm. However in an environment where there 125 are multiple trusted Kerberos realms, the client needs to be able to 126 determine what realm a particular user or service is in before making 127 an AS or TGS request. Traditionally this requires client 128 configuration to make this possible. 129 130 When having to deal with multiple trusted realms, users are forced to 131 know what realm they are in before they can obtain a ticket granting 132 ticket (TGT) with an AS request. However, in many cases the user 133 would like to use a more familiar name that is not directly related 134 to the realm of their Kerberos principal name. A good example of 135 this is an RFC 822 style email name. This document describes a 136 mechanism that would allow a user to specify a user principal name 137 that is an alias for the user's Kerberos principal name. In practice 138 this would be the name that the user specifies to obtain a TGT from a 139 Kerberos KDC. The user principal name no longer has a direct 140 relationship with the Kerberos principal or realm. Thus the 141 administrator is able to move the user's principal to other realms 142 without the user having to know that it happened. 143 144 Once a user has a TGT, they would like to be able to access services 145 in any trusted Kerberos realm. To do this requires that the client 146 be able to determine what realm the target service principal is in 147 before making the TGS request. Current implementations of Kerberos 148 typically have a table that maps DNS host names to corresponding 149 Kerberos realms. In order for this to work on the client, each 150 application canonicalizes the host name of the service, for example 151 by doing a DNS lookup followed by a reverse lookup using the returned 152 IP address. The returned primary host name is then used in the 153 construction of the principal name for the target service. In order 154 for the correct realm to be added for the target host, the mapping 155 table [domain_to_realm] is consulted for the realm corresponding to 156 the DNS host name. The corresponding realm is then used to complete 157 the target service principal name. 158 159 This traditional mechanism requires that each client have very 160 detailed configuration information about the hosts that are providing 161 services and their corresponding realms. Having client side 162 configuration information can be very costly from an administration 163 point of view - especially if there are many realms and computers in 164 165 166 167Zhu & Jaganathan Expires January 20, 2006 [Page 3] 168 169Internet-Draft KDC Referrals July 2005 170 171 172 the environment. 173 174 There are also cases where specific DNS aliases (local names) have 175 been setup in an organization to refer to a server in another 176 organization (remote server). The server has different DNS names in 177 each organization and each organization has a Kerberos realm that is 178 configured to service DNS names within that organization. Ideally 179 users are able to authenticate to the server in the other 180 organization using the local server name. This would mean that the 181 local realm be able to produce a ticket to the remote server under 182 its name. You could give that remote server an identity in the local 183 realm and then have that remote server maintain a separate secret for 184 each alias it is known as. Alternatively you could arrange to have 185 the local realm issue a referral to the remote realm and notify the 186 requesting client of the server's remote name that should be used in 187 order to request a ticket. 188 189 This memo proposes a solution for these problems and simplifies 190 administration by minimizing the configuration information needed on 191 each computer using Kerberos. Specifically it describes a mechanism 192 to allow the KDC to handle canonicalization of names, provide for 193 principal aliases for users and services and provide a mechanism for 194 the KDC to determine the trusted realm authentication path by being 195 able to generate referrals to other realms in order to locate 196 principals. 197 198 Two kinds of KDC referrals are introduced in this memo: 199 200 1. Client referrals, in which the client doesn't know which realm 201 contains a user account. 202 2. Server referrals, in which the client doesn't know which realm 203 contains a server account. 204 2052. Conventions Used in This Document 206 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 210 2113. Requesting a Referral 212 213 In order to request referrals defined in section 5, 6, and 7, the 214 Kerberos client MUST explicitly request the canonicalize KDC option 215 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to 216 the KDC that the client is prepared to receive a reply that contains 217 a principal name other than the one requested. 218 219 220 221 222 223Zhu & Jaganathan Expires January 20, 2006 [Page 4] 224 225Internet-Draft KDC Referrals July 2005 226 227 228 KDCOptions ::= KerberosFlags 229 -- canonicalize (15) 230 -- other KDCOptions values omitted 231 232 The client should expect, when sending names with the "canonicalize" 233 KDC option, that names in the KDC's reply MAY be different than the 234 name in the request. A referral TGT is a cross realm TGT that is 235 returned with the server name of the ticket being different from the 236 server name in the request [RFC4120]. 237 2384. Realm Organization Model 239 240 This memo assumes that the world of principals is arranged on 241 multiple levels: the realm, the enterprise, and the world. A KDC may 242 issue tickets for any principal in its realm or cross-realm tickets 243 for realms with which it has a direct trust relationship. The KDC 244 also has access to a trusted name service that can resolve any name 245 from within its enterprise into a realm. This trusted name service 246 removes the need to use an un-trusted DNS lookup for name resolution. 247 248 For example, consider the following configuration, where lines 249 indicate trust relationships: 250 251 MS.COM 252 / \ 253 / \ 254 OFFICE.MS.COM NTDEV.MS.COM 255 256 In this configuration, all users in the MS.COM enterprise could have 257 a principal name such as alice@MS.COM, with the same realm portion. 258 In addition, servers at MS.COM should be able to have DNS host names 259 from any DNS domain independent of what Kerberos realm their 260 principals reside in. 261 2625. Client Name Canonicalization 263 264 A client account may have multiple principal names. More useful, 265 though, is a globally unique name that allows unification of email 266 and security principal names. For example, all users at MS may have 267 a client principal name of the form "joe@MS.COM" even though the 268 principals are contained in multiple realms. This global name is 269 again an alias for the true client principal name, which indicates 270 what realm contains the principal. Thus, accounts "alice" in the 271 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as "alice@ 272 MS.COM" and "bob@MS.COM". 273 274 This utilizes a new client principal name type, as the AS-REQ message 275 only contains a single realm field, and the realm portion of this 276 277 278 279Zhu & Jaganathan Expires January 20, 2006 [Page 5] 280 281Internet-Draft KDC Referrals July 2005 282 283 284 name doesn't correspond to any Kerberos realm. Thus, the entire name 285 "alice@MS.COM" is transmitted as a single component in the client 286 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 287 [RFC4120]. The KDC will recognize this name type and then transform 288 the requested name into the true principal name. The true principal 289 name can be using a name type different from the requested name type. 290 Typically the true principal name will be a NT-PRINCIPAL [RFC4120]. 291 292 If the "canonicalize" KDC option is set, then the KDC MAY change the 293 client principal name and type in the AS response and ticket returned 294 from the name type of the client name in the request. For example 295 the AS request may specify a client name of "bob@MS.COM" as an NT- 296 ENTERPRISE name with the "canonicalize" KDC option set and the KDC 297 will return with a client name of "104567" as a NT-UID. 298 299 It is assumed that the client discovers whether the KDC supports the 300 NT-ENTERPRISE name type via out of band mechanisms. 301 3026. Client Referrals 303 304 The simplest form of ticket referral is for a user requesting a 305 ticket using an AS-REQ. In this case, the client machine will send 306 the AS-REQ to a convenient trusted realm, for example the realm of 307 the client machine. In the case of the name alice@MS.COM, the client 308 MAY optimistically choose to send the request to MS.COM. The realm 309 in the AS-REQ is always the name of the realm that the request is for 310 as specified in [RFC4120]. 311 312 The KDC will try to lookup the name in its local account database. 313 If the account is present in the realm of the request, it SHOULD 314 return a KDC reply structure with the appropriate ticket. 315 316 If the account is not present in the realm specified in the request 317 and the "canonicalize" KDC option is set, the KDC will try to lookup 318 the entire name, alice@MS.COM, using a name service. If this lookup 319 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 320 [RFC4120]. If the lookup is successful, it MUST return an error 321 KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm 322 field will contain either the true realm of the client or another 323 realm that MAY have better information about the client's true realm. 324 The client SHALL NOT use a cname returned from a referral until that 325 name is validated. 326 327 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 328 new AS request with the same client principal name used to generate 329 the first referral to the realm specified by the realm field of the 330 Kerberos error message from the first request. The client SHOULD 331 repeat these steps until it finds the true realm of the client. To 332 333 334 335Zhu & Jaganathan Expires January 20, 2006 [Page 6] 336 337Internet-Draft KDC Referrals July 2005 338 339 340 avoid infinite referral loops, an implementation should limit the 341 number of referrals. A suggested limit is 5 referrals before giving 342 up. 343 344 In Microsoft's current implementation through the use of global 345 catalogs any domain in one forest is reachable from any other domain 346 in the same forest or another trusted forest with 3 or less 347 referrals. A forest is a collection of realms with hierarchical 348 trust relationships: there can be multiple trust trees in a forest; 349 each child and parent realm pair and each root realm pair have 350 bidirectional transitive direct rusts between them. 351 352 The true principal name of the client, returned in AS-REQ, can be 353 validated in a subsequent TGS message exchange where its value is 354 communicated back to the KDC via the authenticator in the PA-TGS-REQ 355 padata [RFC4120]. 356 3577. Server Referrals 358 359 The primary difference in server referrals is that the KDC MUST 360 return a referral TGT rather than an error message as is done in the 361 client referrals. There needs to be a place to include in the reply 362 information about what realm contains the server. This is done by 363 returning information about the server name in the pre-authentication 364 data field of the KDC reply [RFC4120], as specified later in this 365 section. 366 367 If the KDC resolves the server principal name into a principal in the 368 realm specified by the service realm name, it will return a normal 369 ticket. 370 371 If the "canonicalize" flag in the KDC options is not set, the KDC 372 MUST only look up the name as a normal principal name in the 373 specified server realm. If the "canonicalize" flag in the KDC 374 options is set and the KDC doesn't find the principal locally, the 375 KDC MAY return a cross-realm ticket granting ticket to the next hop 376 on the trust path towards a realm that may be able to resolve the 377 principal name. The true principal name of the server SHALL be 378 returned in the padata of the reply if it is different from what is 379 specified the request. 380 381 When a referral TGT is returned, the KDC MUST return the target realm 382 for the referral TGT as an KDC supplied pre-authentication data 383 element in the response. This referral information in pre- 384 authentication data MUST be encrypted using the session key from the 385 reply ticket. The key usage value for the encryption operation used 386 by PA-SERVER-REFERRAL is 26. 387 388 389 390 391Zhu & Jaganathan Expires January 20, 2006 [Page 7] 392 393Internet-Draft KDC Referrals July 2005 394 395 396 The pre-authentication data returned by the KDC, which contains the 397 referred realm and the true principal name of server, is encoded in 398 DER as follows. 399 400 PA-SERVER-REFERRAL 25 401 402 PA-SERVER-REFERRAL-DATA ::= EncryptedData 403 -- ServerReferralData -- 404 405 ServerReferralData ::= SEQUENCE { 406 referred-realm [0] Realm OPTIONAL, 407 -- target realm of the referral TGT 408 true-principal-name [1] PrincipalName OPTIONAL, 409 -- true server principal name 410 ... 411 } 412 413 Clients SHALL NOT accept a reply ticket, whose the server principal 414 name is different from that of the request, if the KDC response does 415 not contain a PA-SERVER-REFERRAL padata entry. 416 417 The referred-realm field is present if and only if the returned 418 ticket is a referral TGT, not a service ticket for the requested 419 server principal. 420 421 When a referral TGT is returned and the true-principal-name field is 422 present, the client MUST use that name in the subsequent requests to 423 the server realm when following the referral. 424 425 Client SHALL NOT accept a true server principal name for a service 426 ticket if the true-principal-name field is not present in the PA- 427 SERVER-REFERRAL data. 428 429 The client will use this referral information to request a chain of 430 cross-realm ticket granting tickets until it reaches the realm of the 431 server, and can then expect to receive a valid service ticket. 432 433 However an implementation should limit the number of referrals that 434 it processes to avoid infinite referral loops. A suggested limit is 435 5 referrals before giving up. 436 437 Here is an example of a client requesting a service ticket for a 438 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 439 440 441 442 443 444 445 446 447Zhu & Jaganathan Expires January 20, 2006 [Page 8] 448 449Internet-Draft KDC Referrals July 2005 450 451 452 +NC = Canonicalize KDCOption set 453 +PA-REFERRAL = returned PA-SERVER-REFERRAL 454 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM 455 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 456 containing MS.COM as the referred realm with no 457 true-principal-name 458 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM 459 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 460 containing NTDEV.MS.COM as the referred realm with no 461 true-principal-name 462 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM 463 S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM 464 465 4668. Cross Realm Routing 467 468 The current Kerberos protocol requires the client to explicitly 469 request a cross-realm TGT for each pair of realms on a referral 470 chain. As a result, the client need to be aware of the trust 471 hierarchy and of any short-cut trusts (those that aren't parent- 472 child trusts). 473 474 Instead, using the server referral routing mechanism as defined in 475 Section 7, The KDC will determine the best path for the client and 476 return a cross-realm TGT as the referral TGT, and the target realm 477 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 478 479 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 480 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 481 response does not contain the PA-SERVER-REFERRAL padata. 482 4839. Compatibility with Earlier Implementations of Name Canonicalization 484 485 The Microsoft Windows 2000 and Windows 2003 releases included an 486 earlier form of name-canonicalization [XPR]. Here are the 487 differences: 488 489 1) The TGS referral data is returned inside of the KDC message as 490 "encrypted pre-authentication data". 491 492 493 494 495 496 497 498 499 500 501 502 503Zhu & Jaganathan Expires January 20, 2006 [Page 9] 504 505Internet-Draft KDC Referrals July 2005 506 507 508 EncKDCRepPart ::= SEQUENCE { 509 key [0] EncryptionKey, 510 last-req [1] LastReq, 511 nonce [2] UInt32, 512 key-expiration [3] KerberosTime OPTIONAL, 513 flags [4] TicketFlags, 514 authtime [5] KerberosTime, 515 starttime [6] KerberosTime OPTIONAL, 516 endtime [7] KerberosTime, 517 renew-till [8] KerberosTime OPTIONAL, 518 srealm [9] Realm, 519 sname [10] PrincipalName, 520 caddr [11] HostAddresses OPTIONAL, 521 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 522 } 523 524 2) The preauth data type definition in the encrypted preauth data is 525 as follows: 526 527 528 529 PA-SVR-REFERRAL-INFO 20 530 531 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 532 referred-name [1] PrincipalName OPTIONAL, 533 referred-realm [0] Realm 534 }} 535 536 3) When [PKINIT] is used, the NT-ENTERPRISE client name is encoded as 537 a Subject Alternative Name (SAN) extension [RFC3280] in the 538 client's X.509 certificate. The type of the otherName field for 539 this SAN extension is AnotherName [RFC3280]. The type-id field of 540 the type AnotherName is id-ms-sc-logon-upn 541 (1.3.6.1.4.1.311.20.2.3) and the value field of the type 542 AnotherName is a KerberosString [RFC4120]. The value of this 543 KerberosString type is the single component in the name-string 544 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 545 54610. Security Considerations 547 548 For the AS exchange case, it is important that the logon mechanism 549 not trust a name that has not been used to authenticate the user. 550 For example, the name that the user enters as part of a logon 551 exchange may not be the name that the user authenticates as, given 552 that the KDC_ERR_WRONG_REALM error may have been returned. The 553 relevant Kerberos naming information for logon (if any), is the 554 client name and client realm in the service ticket targeted at the 555 workstation that was obtained using the user's initial TGT. 556 557 558 559Zhu & Jaganathan Expires January 20, 2006 [Page 10] 560 561Internet-Draft KDC Referrals July 2005 562 563 564 How the client name and client realm is mapped into a local account 565 for logon is a local matter, but the client logon mechanism MUST use 566 additional information such as the client realm and/or authorization 567 attributes from the service ticket presented to the workstation by 568 the user, when mapping the logon credentials to a local account on 569 the workstation. 570 57111. Acknowledgments 572 573 The authors wish to thank Ken Raeburn for his comments and 574 suggestions. 575 576 Sam Hartman, Ken Raeburn, and authors came up with the idea of using 577 the ticket key to encrypt the referral data, which prevents cut and 578 paste attack using the referral data and referral TGTs. 579 580 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 581 version of this document. 582 58312. References 584 58512.1 Normative References 586 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 590 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 591 X.509 Public Key Infrastructure Certificate and 592 Certificate Revocation List (CRL) Profile", RFC 3280, 593 April 2002. 594 595 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 596 Kerberos Network Authentication Service (V5)", RFC 4120, 597 July 2005. 598 599 [PKINIT] RFC-Editor: To be replaced by RFC number for draft-ietf- 600 cat-kerberos-pk-init. Work in Progress. 601 60212.2 Informative References 603 604 [XPR] Trostle, J., Kosinovsky, I., and Swift, M., 605 "Implementation of Crossrealm Referral Handling in the 606 MIT Kerberos Client", In Network and Distributed System 607 Security Symposium, February 2001. 608 609 610 611 612 613 614 615 616 617 618 619Zhu & Jaganathan Expires January 20, 2006 [Page 11] 620 621Internet-Draft KDC Referrals July 2005 622 623 624Authors' Addresses 625 626 Larry Zhu 627 Microsoft Corporation 628 One Microsoft Way 629 Redmond, WA 98052 630 US 631 632 Email: lzhu@microsoft.com 633 634 635 Karthik Jaganathan 636 Microsoft Corporation 637 One Microsoft Way 638 Redmond, WA 98052 639 US 640 641 Email: karthikj@microsoft.com 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 671 672 673 674 675Zhu & Jaganathan Expires January 20, 2006 [Page 12] 676 677Internet-Draft KDC Referrals July 2005 678 679 680Intellectual Property Statement 681 682 The IETF takes no position regarding the validity or scope of any 683 Intellectual Property Rights or other rights that might be claimed to 684 pertain to the implementation or use of the technology described in 685 this document or the extent to which any license under such rights 686 might or might not be available; nor does it represent that it has 687 made any independent effort to identify any such rights. Information 688 on the procedures with respect to rights in RFC documents can be 689 found in BCP 78 and BCP 79. 690 691 Copies of IPR disclosures made to the IETF Secretariat and any 692 assurances of licenses to be made available, or the result of an 693 attempt made to obtain a general license or permission for the use of 694 such proprietary rights by implementers or users of this 695 specification can be obtained from the IETF on-line IPR repository at 696 http://www.ietf.org/ipr. 697 698 The IETF invites any interested party to bring to its attention any 699 copyrights, patents or patent applications, or other proprietary 700 rights that may cover technology that may be required to implement 701 this standard. Please address the information to the IETF at 702 ietf-ipr@ietf.org. 703 704 705Disclaimer of Validity 706 707 This document and the information contained herein are provided on an 708 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 709 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 710 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 711 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 712 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 713 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 714 715 716Copyright Statement 717 718 Copyright (C) The Internet Society (2005). This document is subject 719 to the rights, licenses and restrictions contained in BCP 78, and 720 except as set forth therein, the authors retain all their rights. 721 722 723Acknowledgment 724 725 Funding for the RFC Editor function is currently provided by the 726 Internet Society. 727 728 729 730 731Zhu & Jaganathan Expires January 20, 2006 [Page 13] 732 733 734