idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 512. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 16) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC2478, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2004) is 7123 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 417 -- Looks like a reference, but probably isn't: '1' on line 416 -- Looks like a reference, but probably isn't: '2' on line 397 -- Looks like a reference, but probably isn't: '3' on line 398 -- Looks like a reference, but probably isn't: '4' on line 399 -- Looks like a reference, but probably isn't: '5' on line 400 -- Looks like a reference, but probably isn't: '6' on line 401 -- Looks like a reference, but probably isn't: '7' on line 402 -- Looks like a reference, but probably isn't: '8' on line 403 -- Looks like a reference, but probably isn't: '9' on line 404 -- Looks like a reference, but probably isn't: '10' on line 405 -- Looks like a reference, but probably isn't: '11' on line 406 -- Looks like a reference, but probably isn't: '12' on line 407 ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft K. Jaganathan 4 Obsoletes: 2478 (if approved) Microsoft Corporation 5 Expires: April 25, 2005 October 25, 2004 7 Generating KDC Referrals to locate Kerberos realms 8 draft-ietf-krb-wg-kerberos-referrals-05 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 25, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 The memo documents a method for a Kerberos Key Distribution Center 44 (KDC) to respond to client requests for Kerberos tickets when the 45 client does not have detailed configuration information on the realms 46 of users or services. The KDC will handle requests for principals in 47 other realms by returning either a referral error or a cross-realm 48 TGT to another realm on the referral path. The clients will use this 49 referral information to reach the realm of the target principal and 50 then receive the ticket. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . 5 56 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . 6 57 4. Realm Organization Model . . . . . . . . . . . . . . . . . . 7 58 5. Client Name Canonicalization . . . . . . . . . . . . . . . . 8 59 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . 10 61 8. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . 12 62 9. Compatibility with Earlier Implementations of Name 63 Canonicalization . . . . . . . . . . . . . . . . . . . . . . 13 64 10. Security Considerations . . . . . . . . . . . . . . . . . . 14 65 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 12.1 Normative References . . . . . . . . . . . . . . . . . . . 16 68 12.2 Informative References . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 70 Intellectual Property and Copyright Statements . . . . . . . 17 72 1. Introduction 74 Current implementations of the Kerberos AS and TGS protocols, as 75 defined in [KRBCLR], use principal names constructed from a known 76 user or service name and realm. A service name is typically 77 constructed from a name of the service and the DNS host name of the 78 computer that is providing the service. Many existing deployments of 79 Kerberos use a single Kerberos realm where all users and services 80 would be using the same realm. However in an environment where there 81 are multiple trusted Kerberos realms, the client needs to be able to 82 determine what realm a particular user or service is in before making 83 an AS or TGS request. Traditionally this requires client 84 configuration to make this possible. 86 When having to deal with multiple trusted realms, users are forced to 87 know what realm they are in before they can obtain a ticket granting 88 ticket (TGT) with an AS request. However, in many cases the user 89 would like to use a more familiar name that is not directly related 90 to the realm of their Kerberos principal name. A good example of 91 this is an RFC 822 style email name [RFC822]. This document 92 describes a mechanism that would allow a user to specify a user 93 principal name that is an alias for the user's Kerberos principal 94 name. In practice this would be the name that the user specifies to 95 obtain a TGT from a Kerberos KDC. The user principal name no longer 96 has a direct relationship with the Kerberos principal or realm. Thus 97 the administrator is able to move the user's principal to other 98 realms without the user having to know that it happened. 100 Once a user has a TGT, they would like to be able to access services 101 in any trusted Kerberos realm. To do this requires that the client 102 be able to determine what realm the target service principal is in 103 before making the TGS request. Current implementations of Kerberos 104 typically have a table that maps DNS host names to corresponding 105 Kerberos realms. In order for this to work on the client, each 106 application canonicalizes the host name of the service, for example 107 by doing a DNS lookup followed by a reverse lookup using the returned 108 IP address. The returned primary host name is then used in the 109 construction of the principal name for the target service. In order 110 for the correct realm to be added for the target host, the mapping 111 table [domain_to_realm] is consulted for the realm corresponding to 112 the DNS host name. The corresponding realm is then used to complete 113 the target service principal name. 115 This traditional mechanism requires that each client have very 116 detailed configuration information about the hosts that are providing 117 services and their corresponding realms. Having client side 118 configuration information can be very costly from an administration 119 point of view - especially if there are many realms and computers in 120 the environment. 122 There are also cases where specific DNS aliases (local names) have 123 been setup in an organization to refer to a server in another 124 organization (remote server). The server has different DNS names in 125 each organization and each organization has a Kerberos realm that is 126 configured to service DNS names within that organization. Ideally 127 users are able to authenticate to the server in the other 128 organization using the local server name. This would mean that the 129 local realm be able to produce a ticket to the remote server under 130 its name. You could give that remote server an identity in the local 131 realm and then have that remote server maintain a separate secret for 132 each alias it is known as. Alternatively you could arrange to have 133 the local realm issue a referral to the remote realm and notify the 134 requesting client of the server's remote name that should be used in 135 order to request a ticket. 137 This memo proposes a solution for these problems and simplifies 138 administration by minimizing the configuration information needed on 139 each computer using Kerberos. Specifically it describes a mechanism 140 to allow the KDC to handle canonicalization of names, provide for 141 principal aliases for users and services and provide a mechanism for 142 the KDC to determine the trusted realm authentication path by being 143 able to generate referrals to other realms in order to locate 144 principals. 146 Two kinds of KDC referrals are introduced in this memo: 148 1. Client referrals, in which the client doesn't know which realm 149 contains a user account. 150 2. Server referrals, in which the client doesn't know which realm 151 contains a server account. 153 2. Conventions Used in This Document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 3. Requesting a Referral 161 In order to request referrals defined in section 5, 6, and 7, the 162 Kerberos client MUST explicitly request the canonicalize KDC option 163 (bit 15) [KRBCLR] for the AS-REQ or TGS-REQ. This flag indicates to 164 the KDC that the client is prepared to receive a reply that contains 165 a principal name other than the one requested. 167 KDCOptions ::= KerberosFlags 168 -- canonicalize (15) 169 -- other KDCOptions values omitted 171 The client should expect, when sending names with the "canonicalize" 172 KDC option, that names in the KDC's reply MAY be different than the 173 name in the request. A referral TGT is a cross realm TGT that is 174 returned with the server name of the ticket being different from the 175 server name in the request [KRBCLR]. 177 4. Realm Organization Model 179 This memo assumes that the world of principals is arranged on 180 multiple levels: the realm, the enterprise, and the world. A KDC may 181 issue tickets for any principal in its realm or cross-realm tickets 182 for realms with which it has a direct trust relationship. The KDC 183 also has access to a trusted name service that can resolve any name 184 from within its enterprise into a realm. This trusted name service 185 removes the need to use an un-trusted DNS lookup for name resolution. 187 For example, consider the following configuration, where lines 188 indicate trust relationships: 190 MS.COM 191 / \ 192 / \ 193 OFFICE.MS.COM NTDEV.MS.COM 195 In this configuration, all users in the MS.COM enterprise could have 196 a principal name such as alice@MS.COM, with the same realm portion. 197 In addition, servers at MS.COM should be able to have DNS host names 198 from any DNS domain independent of what Kerberos realm their 199 principals reside in. 201 5. Client Name Canonicalization 203 A client account may have multiple principal names. More useful, 204 though, is a globally unique name that allows unification of email 205 and security principal names. For example, all users at MS may have 206 a client principal name of the form "joe@MS.COM" even though the 207 principals are contained in multiple realms. This global name is 208 again an alias for the true client principal name, which indicates 209 what realm contains the principal. Thus, accounts "alice" in the 210 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as 211 "alice@MS.COM" and "bob@MS.COM". 213 This utilizes a new client principal name type, as the AS-REQ message 214 only contains a single realm field, and the realm portion of this 215 name doesn't correspond to any Kerberos realm. Thus, the entire name 216 "alice@MS.COM" is transmitted as a single component in the client 217 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 218 [KRBCLR]. The KDC will recognize this name type and then transform 219 the requested name into the true principal name. The true principal 220 name can be using a name type different from the requested name type. 221 Typically the true principal name will be a NT-PRINCIPAL [KRBCLR]. 223 If the "canonicalize" KDC option is set, then the KDC MAY change the 224 client principal name and type in the AS response and ticket returned 225 from the name type of the client name in the request. For example 226 the AS request may specify a client name of "bob@MS.COM" as an 227 NT-ENTERPRISE name with the "canonicalize" KDC option set and the KDC 228 will return with a client name of "104567" as a NT-UID. 230 It is assumed that the client discovers whether the KDC supports the 231 NT-ENTERPRISE name type via out of band mechanisms. 233 6. Client Referrals 235 The simplest form of ticket referral is for a user requesting a 236 ticket using an AS-REQ. In this case, the client machine will send 237 the AS-REQ to a convenient trusted realm, for example the realm of 238 the client machine. In the case of the name alice@MS.COM, the client 239 MAY optimistically choose to send the request to MS.COM. The realm 240 in the AS-REQ is always the name of the realm that the request is for 241 as specified in [KRBCLR]. 243 The KDC will try to lookup the name in its local account database. 244 If the account is present in the realm of the request, it SHOULD 245 return a KDC reply structure with the appropriate ticket. 247 If the account is not present in the realm specified in the request 248 and the "canonicalize" KDC option is set, the KDC will try to lookup 249 the entire name, alice@MS.COM, using a name service. If this lookup 250 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 251 [KRBCLR]. If the lookup is successful, it MUST return an error 252 KDC_ERR_WRONG_REALM [KRBCLR] and in the error message the crealm 253 field will contain either the true realm of the client or another 254 realm that MAY have better information about the client's true realm. 255 The client SHALL NOT use a cname returned from a referral until that 256 name is validated. 258 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 259 new AS request with the same client principal name used to generate 260 the first referral to the realm specified by the realm field of the 261 Kerberos error message from the first request. The client SHOULD 262 repeat these steps until it finds the true realm of the client. To 263 avoid infinite referral loops, an implementation should limit the 264 number of referrals. A suggested limit is 5 referrals before giving 265 up. 267 In Microsoft's current implementation through the use of global 268 catalogs any domain in one forest is reachable from any other domain 269 in the same forest or another trusted forest with 3 or less 270 referrals. A forest is a collection of realms with hierarchical 271 trust relationships: there can be multiple trust trees in a forest; 272 each child and parent realm pair and each root realm pair have 273 bidirectional transitional direct rusts between them. 275 The true principal name of the client, carried via the KRB_ERROR 276 message, can be validated in a subsequent TGS message exchange where 277 its value is communicated back to the KDC via the authenticator in 278 the PA-TGS-REQ padata [KRBCLR]. 280 7. Server Referrals 282 The primary difference in server referrals is that the KDC MUST 283 return a referral TGT rather than an error message as is done in the 284 client referrals. There needs to be a place to include in the reply 285 information about what realm contains the server. This is done by 286 returning information about the server name in the pre-authentication 287 data field of the KDC reply [KRBCLR], as specified later in this 288 section. 290 If the KDC resolves the server principal name into a principal in the 291 realm specified by the service realm name, it will return a normal 292 ticket. 294 If the "canonicalize" flag in the KDC options is not set, the KDC 295 MUST only look up the name as a normal principal name in the 296 specified server realm. If the "canonicalize" flag in the KDC 297 options is set and the KDC doesn't find the principal locally, the 298 KDC MAY return a cross-realm ticket granting ticket to the next hop 299 on the trust path towards a realm that may be able to resolve the 300 principal name. The true principal name of the server SHALL be 301 returned in the padata of the reply if it is different from what is 302 specified the request. 304 When a referral TGT is returned, the KDC MUST return the target realm 305 for the referral TGT as an KDC supplied pre-authentication data 306 element in the response. This referral information in 307 pre-authentication data MUST be encrypted using the session key from 308 the reply ticket. The key usage value for the encryption operation 309 used by PA-SERVER-REFERRAL is 26. 311 The pre-authentication data returned by the KDC, which contains the 312 referred realm and the true principal name of server, is encoded in 313 DER as follows. 315 PA-SERVER-REFERRAL 25 317 PA-SERVER-REFERRAL-DATA ::= EncryptedData 318 -- ServerReferralData -- 320 ServerReferralData ::= SEQUENCE { 321 referred-realm [0] Realm, OPTIONAL 322 -- target realm of the referral TGT 323 true-principal-name [1] PrincipalName OPTIONAL, 324 -- true server principal name 325 ... 326 } 328 Clients SHALL NOT accept a reply ticket, whose the server principal 329 name is different from that of the request, if the KDC response does 330 not contain a PA-SERVER-REFERRAL padata entry. 332 The referred-realm field is present if and only if the returned 333 ticket is a referral TGT, not a service ticket for the requested 334 server principal. 336 When a referral TGT is returned and the true-principal-name field is 337 present, the client MUST use that name in the subsequent requests to 338 the server realm when following the referral. 340 Client SHALL NOT accept a true server principal name for a service 341 ticket if the true-principal-name field is not present in the 342 PA-SERVER-REFERRAL data. 344 The client will use this referral information to request a chain of 345 cross-realm ticket granting tickets until it reaches the realm of the 346 server, and can then expect to receive a valid service ticket. 348 However an implementation should limit the number of referrals that 349 it processes to avoid infinite referral loops. A suggested limit is 350 5 referrals before giving up. 352 Here is an example of a client requesting a service ticket for a 353 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 355 +NC = Canonicalize KDCOption set 356 +PA-REFERRAL = returned PA-SERVER-REFERRAL 357 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM 358 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 359 containing MS.COM as the referred realm with no 360 true-principal-name 361 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM 362 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 363 containing NTDEV.MS.COM as the referred realm with no 364 true-principal-name 365 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM 366 S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM 368 8. Cross Realm Routing 370 The current Kerberos protocol requires the client to explicitly 371 request a cross-realm TGT for each pair of realms on a referral 372 chain. As a result, the client need to be aware of the trust 373 hierarchy and of any short-cut trusts (those that aren't parent- 374 child trusts). 376 Instead, using the server referral routing mechanism as defined in 377 Section 7, The KDC will determine the best path for the client and 378 return a cross-realm TGT as the referral TGT, and the target realm 379 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 381 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 382 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 383 response does not contain the PA-SERVER-REFERRAL padata. 385 9. Compatibility with Earlier Implementations of Name Canonicalization 387 The Microsoft Windows 2000 and Windows 2003 releases included an 388 earlier form of name-canonicalization [XPR]. Here are the 389 differences: 391 1) The TGS referral data is returned inside of the KDC message as 392 "encrypted pre-authentication data". 394 EncKDCRepPart ::= SEQUENCE { 395 key [0] EncryptionKey, 396 last-req [1] LastReq, 397 nonce [2] UInt32, 398 key-expiration [3] KerberosTime OPTIONAL, 399 flags [4] TicketFlags, 400 authtime [5] KerberosTime, 401 starttime [6] KerberosTime OPTIONAL, 402 endtime [7] KerberosTime, 403 renew-till [8] KerberosTime OPTIONAL, 404 srealm [9] Realm, 405 sname [10] PrincipalName, 406 caddr [11] HostAddresses OPTIONAL, 407 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 408 } 410 2) The preauth data type definition in the encrypted preauth data is 411 as follows: 413 PA-SVR-REFERRAL-INFO 20 415 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 416 referred-name [1] PrincipalName OPTIONAL, 417 referred-realm [0] Realm 418 }} 420 10. Security Considerations 422 For the AS exchange case, it is important that the logon mechanism 423 not trust a name that has not been used to authenticate the user. 424 For example, the name that the user enters as part of a logon 425 exchange may not be the name that the user authenticates as, given 426 that the KDC_ERR_WRONG_REALM error may have been returned. The 427 relevant Kerberos naming information for logon (if any), is the 428 client name and client realm in the service ticket targeted at the 429 workstation that was obtained using the user's initial TGT. 431 How the client name and client realm is mapped into a local account 432 for logon is a local matter, but the client logon mechanism MUST use 433 additional information such as the client realm and/or authorization 434 attributes from the service ticket presented to the workstation by 435 the user, when mapping the logon credentials to a local account on 436 the workstation. 438 11. Acknowledgments 440 The authors wish to thank Ken Raeburn for his comments and 441 suggestions. 443 Sam Hartman, Ken Raeburn, and authors came up with the idea of using 444 the ticket key to encrypt the referral data, which prevents cut and 445 paste attack using the referral data and referral TGTs. 447 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 448 version of this document. 450 12. References 452 12.1 Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 [KRBCLR] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 458 Kerberos Network Authentication Service (V5)", 459 draft-ietf-krb-wg-kerberos-clarifications. Work in 460 progress. 462 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet 463 Text Messages", RFC 822, August 1982. 465 12.2 Informative References 467 [XPR] Trostle, J., Kosinovsky, I., and Swift, M., 468 "Implementation of Crossrealm Referral Handling in the 469 MIT Kerberos Client", In Network and Distributed System 470 Security Symposium, February 2001. 472 Authors' Addresses 474 Larry Zhu 475 Microsoft Corporation 476 One Microsoft Way 477 Redmond, WA 98052 478 US 480 EMail: lzhu@microsoft.com 482 Karthik Jaganathan 483 Microsoft Corporation 484 One Microsoft Way 485 Redmond, WA 98052 486 US 488 EMail: karthikj@microsoft.com 490 Intellectual Property Statement 492 The IETF takes no position regarding the validity or scope of any 493 Intellectual Property Rights or other rights that might be claimed to 494 pertain to the implementation or use of the technology described in 495 this document or the extent to which any license under such rights 496 might or might not be available; nor does it represent that it has 497 made any independent effort to identify any such rights. Information 498 on the procedures with respect to rights in RFC documents can be 499 found in BCP 78 and BCP 79. 501 Copies of IPR disclosures made to the IETF Secretariat and any 502 assurances of licenses to be made available, or the result of an 503 attempt made to obtain a general license or permission for the use of 504 such proprietary rights by implementers or users of this 505 specification can be obtained from the IETF on-line IPR repository at 506 http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary 510 rights that may cover technology that may be required to implement 511 this standard. Please address the information to the IETF at 512 ietf-ipr@ietf.org. 514 Disclaimer of Validity 516 This document and the information contained herein are provided on an 517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 519 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 520 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 521 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Copyright Statement 526 Copyright (C) The Internet Society (2004). This document is subject 527 to the rights, licenses and restrictions contained in BCP 78, and 528 except as set forth therein, the authors retain all their rights. 530 Acknowledgment 532 Funding for the RFC Editor function is currently provided by the 533 Internet Society.