1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft K. Jaganathan 5Obsoletes: 2478 (if approved) Microsoft Corporation 6Expires: April 25, 2005 October 25, 2004 7 8 9 Generating KDC Referrals to locate Kerberos realms 10 draft-ietf-krb-wg-kerberos-referrals-05 11 12Status of this Memo 13 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 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 24 Internet-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 April 25, 2005. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2004). 42 43Abstract 44 45 The memo documents a method for a Kerberos Key Distribution Center 46 (KDC) to respond to client requests for Kerberos tickets when the 47 client does not have detailed configuration information on the realms 48 of users or services. The KDC will handle requests for principals in 49 other realms by returning either a referral error or a cross-realm 50 TGT to another realm on the referral path. The clients will use this 51 referral information to reach the realm of the target principal and 52 53 54 55Zhu & Jaganathan Expires April 25, 2005 [Page 1] 56 57Internet-Draft KDC Referrals October 2004 58 59 60 then receive the ticket. 61 62Table of Contents 63 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . 5 66 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . 6 67 4. Realm Organization Model . . . . . . . . . . . . . . . . . . 7 68 5. Client Name Canonicalization . . . . . . . . . . . . . . . . 8 69 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . 9 70 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . 10 71 8. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . 12 72 9. Compatibility with Earlier Implementations of Name 73 Canonicalization . . . . . . . . . . . . . . . . . . . . . . 13 74 10. Security Considerations . . . . . . . . . . . . . . . . . . 14 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 12.1 Normative References . . . . . . . . . . . . . . . . . . . 16 78 12.2 Informative References . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 80 Intellectual Property and Copyright Statements . . . . . . . 17 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 April 25, 2005 [Page 2] 112 113Internet-Draft KDC Referrals October 2004 114 115 1161. Introduction 117 118 Current implementations of the Kerberos AS and TGS protocols, as 119 defined in [KRBCLR], 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 [RFC822]. This document 136 describes a mechanism that would allow a user to specify a user 137 principal name that is an alias for the user's Kerberos principal 138 name. In practice this would be the name that the user specifies to 139 obtain a TGT from a Kerberos KDC. The user principal name no longer 140 has a direct relationship with the Kerberos principal or realm. Thus 141 the administrator is able to move the user's principal to other 142 realms 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 April 25, 2005 [Page 3] 168 169Internet-Draft KDC Referrals October 2004 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 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Zhu & Jaganathan Expires April 25, 2005 [Page 4] 224 225Internet-Draft KDC Referrals October 2004 226 227 2282. Conventions Used in This Document 229 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in [RFC2119]. 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Zhu & Jaganathan Expires April 25, 2005 [Page 5] 280 281Internet-Draft KDC Referrals October 2004 282 283 2843. Requesting a Referral 285 286 In order to request referrals defined in section 5, 6, and 7, the 287 Kerberos client MUST explicitly request the canonicalize KDC option 288 (bit 15) [KRBCLR] for the AS-REQ or TGS-REQ. This flag indicates to 289 the KDC that the client is prepared to receive a reply that contains 290 a principal name other than the one requested. 291 292 293 KDCOptions ::= KerberosFlags 294 -- canonicalize (15) 295 -- other KDCOptions values omitted 296 297 The client should expect, when sending names with the "canonicalize" 298 KDC option, that names in the KDC's reply MAY be different than the 299 name in the request. A referral TGT is a cross realm TGT that is 300 returned with the server name of the ticket being different from the 301 server name in the request [KRBCLR]. 302 303 304 305 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 335Zhu & Jaganathan Expires April 25, 2005 [Page 6] 336 337Internet-Draft KDC Referrals October 2004 338 339 3404. Realm Organization Model 341 342 This memo assumes that the world of principals is arranged on 343 multiple levels: the realm, the enterprise, and the world. A KDC may 344 issue tickets for any principal in its realm or cross-realm tickets 345 for realms with which it has a direct trust relationship. The KDC 346 also has access to a trusted name service that can resolve any name 347 from within its enterprise into a realm. This trusted name service 348 removes the need to use an un-trusted DNS lookup for name resolution. 349 350 For example, consider the following configuration, where lines 351 indicate trust relationships: 352 353 MS.COM 354 / \ 355 / \ 356 OFFICE.MS.COM NTDEV.MS.COM 357 358 In this configuration, all users in the MS.COM enterprise could have 359 a principal name such as alice@MS.COM, with the same realm portion. 360 In addition, servers at MS.COM should be able to have DNS host names 361 from any DNS domain independent of what Kerberos realm their 362 principals reside in. 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Zhu & Jaganathan Expires April 25, 2005 [Page 7] 392 393Internet-Draft KDC Referrals October 2004 394 395 3965. Client Name Canonicalization 397 398 A client account may have multiple principal names. More useful, 399 though, is a globally unique name that allows unification of email 400 and security principal names. For example, all users at MS may have 401 a client principal name of the form "joe@MS.COM" even though the 402 principals are contained in multiple realms. This global name is 403 again an alias for the true client principal name, which indicates 404 what realm contains the principal. Thus, accounts "alice" in the 405 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as 406 "alice@MS.COM" and "bob@MS.COM". 407 408 This utilizes a new client principal name type, as the AS-REQ message 409 only contains a single realm field, and the realm portion of this 410 name doesn't correspond to any Kerberos realm. Thus, the entire name 411 "alice@MS.COM" is transmitted as a single component in the client 412 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 413 [KRBCLR]. The KDC will recognize this name type and then transform 414 the requested name into the true principal name. The true principal 415 name can be using a name type different from the requested name type. 416 Typically the true principal name will be a NT-PRINCIPAL [KRBCLR]. 417 418 If the "canonicalize" KDC option is set, then the KDC MAY change the 419 client principal name and type in the AS response and ticket returned 420 from the name type of the client name in the request. For example 421 the AS request may specify a client name of "bob@MS.COM" as an 422 NT-ENTERPRISE name with the "canonicalize" KDC option set and the KDC 423 will return with a client name of "104567" as a NT-UID. 424 425 It is assumed that the client discovers whether the KDC supports the 426 NT-ENTERPRISE name type via out of band mechanisms. 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Zhu & Jaganathan Expires April 25, 2005 [Page 8] 448 449Internet-Draft KDC Referrals October 2004 450 451 4526. Client Referrals 453 454 The simplest form of ticket referral is for a user requesting a 455 ticket using an AS-REQ. In this case, the client machine will send 456 the AS-REQ to a convenient trusted realm, for example the realm of 457 the client machine. In the case of the name alice@MS.COM, the client 458 MAY optimistically choose to send the request to MS.COM. The realm 459 in the AS-REQ is always the name of the realm that the request is for 460 as specified in [KRBCLR]. 461 462 The KDC will try to lookup the name in its local account database. 463 If the account is present in the realm of the request, it SHOULD 464 return a KDC reply structure with the appropriate ticket. 465 466 If the account is not present in the realm specified in the request 467 and the "canonicalize" KDC option is set, the KDC will try to lookup 468 the entire name, alice@MS.COM, using a name service. If this lookup 469 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 470 [KRBCLR]. If the lookup is successful, it MUST return an error 471 KDC_ERR_WRONG_REALM [KRBCLR] and in the error message the crealm 472 field will contain either the true realm of the client or another 473 realm that MAY have better information about the client's true realm. 474 The client SHALL NOT use a cname returned from a referral until that 475 name is validated. 476 477 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 478 new AS request with the same client principal name used to generate 479 the first referral to the realm specified by the realm field of the 480 Kerberos error message from the first request. The client SHOULD 481 repeat these steps until it finds the true realm of the client. To 482 avoid infinite referral loops, an implementation should limit the 483 number of referrals. A suggested limit is 5 referrals before giving 484 up. 485 486 In Microsoft's current implementation through the use of global 487 catalogs any domain in one forest is reachable from any other domain 488 in the same forest or another trusted forest with 3 or less 489 referrals. A forest is a collection of realms with hierarchical 490 trust relationships: there can be multiple trust trees in a forest; 491 each child and parent realm pair and each root realm pair have 492 bidirectional transitional direct rusts between them. 493 494 The true principal name of the client, carried via the KRB_ERROR 495 message, can be validated in a subsequent TGS message exchange where 496 its value is communicated back to the KDC via the authenticator in 497 the PA-TGS-REQ padata [KRBCLR]. 498 499 500 501 502 503Zhu & Jaganathan Expires April 25, 2005 [Page 9] 504 505Internet-Draft KDC Referrals October 2004 506 507 5087. Server Referrals 509 510 The primary difference in server referrals is that the KDC MUST 511 return a referral TGT rather than an error message as is done in the 512 client referrals. There needs to be a place to include in the reply 513 information about what realm contains the server. This is done by 514 returning information about the server name in the pre-authentication 515 data field of the KDC reply [KRBCLR], as specified later in this 516 section. 517 518 If the KDC resolves the server principal name into a principal in the 519 realm specified by the service realm name, it will return a normal 520 ticket. 521 522 If the "canonicalize" flag in the KDC options is not set, the KDC 523 MUST only look up the name as a normal principal name in the 524 specified server realm. If the "canonicalize" flag in the KDC 525 options is set and the KDC doesn't find the principal locally, the 526 KDC MAY return a cross-realm ticket granting ticket to the next hop 527 on the trust path towards a realm that may be able to resolve the 528 principal name. The true principal name of the server SHALL be 529 returned in the padata of the reply if it is different from what is 530 specified the request. 531 532 When a referral TGT is returned, the KDC MUST return the target realm 533 for the referral TGT as an KDC supplied pre-authentication data 534 element in the response. This referral information in 535 pre-authentication data MUST be encrypted using the session key from 536 the reply ticket. The key usage value for the encryption operation 537 used by PA-SERVER-REFERRAL is 26. 538 539 The pre-authentication data returned by the KDC, which contains the 540 referred realm and the true principal name of server, is encoded in 541 DER as follows. 542 543 PA-SERVER-REFERRAL 25 544 545 PA-SERVER-REFERRAL-DATA ::= EncryptedData 546 -- ServerReferralData -- 547 548 ServerReferralData ::= SEQUENCE { 549 referred-realm [0] Realm, OPTIONAL 550 -- target realm of the referral TGT 551 true-principal-name [1] PrincipalName OPTIONAL, 552 -- true server principal name 553 ... 554 } 555 556 557 558 559Zhu & Jaganathan Expires April 25, 2005 [Page 10] 560 561Internet-Draft KDC Referrals October 2004 562 563 564 Clients SHALL NOT accept a reply ticket, whose the server principal 565 name is different from that of the request, if the KDC response does 566 not contain a PA-SERVER-REFERRAL padata entry. 567 568 The referred-realm field is present if and only if the returned 569 ticket is a referral TGT, not a service ticket for the requested 570 server principal. 571 572 When a referral TGT is returned and the true-principal-name field is 573 present, the client MUST use that name in the subsequent requests to 574 the server realm when following the referral. 575 576 Client SHALL NOT accept a true server principal name for a service 577 ticket if the true-principal-name field is not present in the 578 PA-SERVER-REFERRAL data. 579 580 The client will use this referral information to request a chain of 581 cross-realm ticket granting tickets until it reaches the realm of the 582 server, and can then expect to receive a valid service ticket. 583 584 However an implementation should limit the number of referrals that 585 it processes to avoid infinite referral loops. A suggested limit is 586 5 referrals before giving up. 587 588 Here is an example of a client requesting a service ticket for a 589 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 590 591 +NC = Canonicalize KDCOption set 592 +PA-REFERRAL = returned PA-SERVER-REFERRAL 593 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM 594 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 595 containing MS.COM as the referred realm with no 596 true-principal-name 597 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM 598 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 599 containing NTDEV.MS.COM as the referred realm with no 600 true-principal-name 601 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM 602 S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM 603 604 605 606 607 608 609 610 611 612 613 614 615Zhu & Jaganathan Expires April 25, 2005 [Page 11] 616 617Internet-Draft KDC Referrals October 2004 618 619 6208. Cross Realm Routing 621 622 The current Kerberos protocol requires the client to explicitly 623 request a cross-realm TGT for each pair of realms on a referral 624 chain. As a result, the client need to be aware of the trust 625 hierarchy and of any short-cut trusts (those that aren't parent- 626 child trusts). 627 628 Instead, using the server referral routing mechanism as defined in 629 Section 7, The KDC will determine the best path for the client and 630 return a cross-realm TGT as the referral TGT, and the target realm 631 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 632 633 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 634 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 635 response does not contain the PA-SERVER-REFERRAL padata. 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 671Zhu & Jaganathan Expires April 25, 2005 [Page 12] 672 673Internet-Draft KDC Referrals October 2004 674 675 6769. Compatibility with Earlier Implementations of Name Canonicalization 677 678 The Microsoft Windows 2000 and Windows 2003 releases included an 679 earlier form of name-canonicalization [XPR]. Here are the 680 differences: 681 682 1) The TGS referral data is returned inside of the KDC message as 683 "encrypted pre-authentication data". 684 685 686 687 EncKDCRepPart ::= SEQUENCE { 688 key [0] EncryptionKey, 689 last-req [1] LastReq, 690 nonce [2] UInt32, 691 key-expiration [3] KerberosTime OPTIONAL, 692 flags [4] TicketFlags, 693 authtime [5] KerberosTime, 694 starttime [6] KerberosTime OPTIONAL, 695 endtime [7] KerberosTime, 696 renew-till [8] KerberosTime OPTIONAL, 697 srealm [9] Realm, 698 sname [10] PrincipalName, 699 caddr [11] HostAddresses OPTIONAL, 700 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 701 } 702 703 2) The preauth data type definition in the encrypted preauth data is 704 as follows: 705 706 707 708 PA-SVR-REFERRAL-INFO 20 709 710 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 711 referred-name [1] PrincipalName OPTIONAL, 712 referred-realm [0] Realm 713 }} 714 715 716 717 718 719 720 721 722 723 724 725 726 727Zhu & Jaganathan Expires April 25, 2005 [Page 13] 728 729Internet-Draft KDC Referrals October 2004 730 731 73210. Security Considerations 733 734 For the AS exchange case, it is important that the logon mechanism 735 not trust a name that has not been used to authenticate the user. 736 For example, the name that the user enters as part of a logon 737 exchange may not be the name that the user authenticates as, given 738 that the KDC_ERR_WRONG_REALM error may have been returned. The 739 relevant Kerberos naming information for logon (if any), is the 740 client name and client realm in the service ticket targeted at the 741 workstation that was obtained using the user's initial TGT. 742 743 How the client name and client realm is mapped into a local account 744 for logon is a local matter, but the client logon mechanism MUST use 745 additional information such as the client realm and/or authorization 746 attributes from the service ticket presented to the workstation by 747 the user, when mapping the logon credentials to a local account on 748 the workstation. 749 750 751 752 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 783Zhu & Jaganathan Expires April 25, 2005 [Page 14] 784 785Internet-Draft KDC Referrals October 2004 786 787 78811. Acknowledgments 789 790 The authors wish to thank Ken Raeburn for his comments and 791 suggestions. 792 793 Sam Hartman, Ken Raeburn, and authors came up with the idea of using 794 the ticket key to encrypt the referral data, which prevents cut and 795 paste attack using the referral data and referral TGTs. 796 797 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 798 version of this document. 799 800 801 802 803 804 805 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 839Zhu & Jaganathan Expires April 25, 2005 [Page 15] 840 841Internet-Draft KDC Referrals October 2004 842 843 84412. References 845 84612.1 Normative References 847 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, March 1997. 850 851 [KRBCLR] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 852 Kerberos Network Authentication Service (V5)", 853 draft-ietf-krb-wg-kerberos-clarifications. Work in 854 progress. 855 856 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet 857 Text Messages", RFC 822, August 1982. 858 85912.2 Informative References 860 861 [XPR] Trostle, J., Kosinovsky, I., and Swift, M., 862 "Implementation of Crossrealm Referral Handling in the 863 MIT Kerberos Client", In Network and Distributed System 864 Security Symposium, February 2001. 865 866Authors' Addresses 867 868 Larry Zhu 869 Microsoft Corporation 870 One Microsoft Way 871 Redmond, WA 98052 872 US 873 874 EMail: lzhu@microsoft.com 875 876 877 Karthik Jaganathan 878 Microsoft Corporation 879 One Microsoft Way 880 Redmond, WA 98052 881 US 882 883 EMail: karthikj@microsoft.com 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903Zhu & Jaganathan Expires April 25, 2005 [Page 16] 904 905Internet-Draft KDC Referrals October 2004 906 907 908Intellectual Property Statement 909 910 The IETF takes no position regarding the validity or scope of any 911 Intellectual Property Rights or other rights that might be claimed to 912 pertain to the implementation or use of the technology described in 913 this document or the extent to which any license under such rights 914 might or might not be available; nor does it represent that it has 915 made any independent effort to identify any such rights. Information 916 on the procedures with respect to rights in RFC documents can be 917 found in BCP 78 and BCP 79. 918 919 Copies of IPR disclosures made to the IETF Secretariat and any 920 assurances of licenses to be made available, or the result of an 921 attempt made to obtain a general license or permission for the use of 922 such proprietary rights by implementers or users of this 923 specification can be obtained from the IETF on-line IPR repository at 924 http://www.ietf.org/ipr. 925 926 The IETF invites any interested party to bring to its attention any 927 copyrights, patents or patent applications, or other proprietary 928 rights that may cover technology that may be required to implement 929 this standard. Please address the information to the IETF at 930 ietf-ipr@ietf.org. 931 932 933Disclaimer of Validity 934 935 This document and the information contained herein are provided on an 936 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 937 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 938 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 939 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 940 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 941 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 942 943 944Copyright Statement 945 946 Copyright (C) The Internet Society (2004). This document is subject 947 to the rights, licenses and restrictions contained in BCP 78, and 948 except as set forth therein, the authors retain all their rights. 949 950 951Acknowledgment 952 953 Funding for the RFC Editor function is currently provided by the 954 Internet Society. 955 956 957 958 959Zhu & Jaganathan Expires April 25, 2005 [Page 17] 960 961 962