idnits 2.17.1 draft-zhu-pku2u-04.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 539. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 76 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (January 27, 2008) is 5931 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: '1' on line 472 == Outdated reference: A later version (-12) exists of draft-ietf-krb-wg-anon-04 ** Downref: Normative reference to an Historic draft: draft-ietf-krb-wg-anon (ref. 'KRB-ANON') ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft Microsoft Corporation 4 Intended status: Standards Track J. Altman 5 Expires: July 30, 2008 Secure Endpoints 6 January 27, 2008 8 Public Key Cryptography Based User-to-User Authentication - (PKU2U) 9 draft-zhu-pku2u-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 30, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines the public key cryptography based user-to-user 43 authentication protocol - PKU2U. This mechanism provides security 44 services in peer to peer networking environments without requiring a 45 Kerberos Key Distribution Center (KDC). Furthermore, the binding of 46 PKU2U for the Generic Security Service Application Program Interface 47 (GSS-API) per RFC2743 is defined based on RFC4121. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3 54 4. PKU2U Principal Names . . . . . . . . . . . . . . . . . . . . 4 55 5. The Protocol Description and the Context Establishment 56 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. The GSS-API Binding for PKU2U . . . . . . . . . . . . . . . . 7 58 7. Guidelines for Credentials Selection . . . . . . . . . . . . . 8 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 61 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 64 11.2. Informative References . . . . . . . . . . . . . . . . . 10 65 Appendix A. PKU2U ASN.1 Module . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 Intellectual Property and Copyright Statements . . . . . . . . . . 12 69 1. Introduction 71 Peer-to-peer systems are increasingly popular today. In a peer-to- 72 peer system, all clients provide resources that contribute positively 73 to the total capacity of the overall system and there is no single 74 point of failure. This distributed nature makes such systems highly 75 scalable and robust. 77 A true peer-to-peer system is self-organized, typically there is no 78 trusted third party in such environments. Consequently the Kerberos 79 protocol as defined in [RFC4120] and [RFC4556] is inadequate to 80 provide security services. Currently there is no interoperable GSS- 81 API mechanism for establishing trust in the information received from 82 the peer. The inability to authenticate the messages exchanged among 83 peers enables many attacks such as poisoning (e.g. providing data 84 contents are different from the description) and polluting (e.g. 85 inserting "bad" packets). 87 To remedy this, the PKU2U protocol extends [RFC4120] and [RFC4556] to 88 support peer-to-peer authentication without the help of a Key 89 Distribution Center (KDC) [RFC4120]. This mechanism can act as a 90 bridge between Public Key Infrastructure (PKI) and GSS-API for such 91 environments. 93 In addition, the binding of PKU2U for GSS-API is defined based on 94 [RFC4121]. 96 2. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 In this document, the GSS-API initiator or acceptor is referred to as 103 the peer when the description is applicable to both the initiator and 104 the acceptor. 106 3. The PKU2U Realm Name 108 The PKU2U realm name is defined as a reserved Kerberos realm name per 109 [KRB-NAME], and it has the value of "WELLKNOWN:PKU2U". 111 Unless otherwise specified, the realm name in any Kerberos message 112 used by PKU2U is the PKU2U realm name. 114 4. PKU2U Principal Names 116 PKU2U Principal names can be constructed as follows: 118 o If the X.509 certificate [RFC3280] of a peer contains an id- 119 pkinit-san Subject Alternative Name (SAN) as defined in Section 120 3.2.2 of [RFC4556] or an id-ms-sc-logon-upn SAN as defined in 121 [REFERALS], then the Kerberos Principal Name for the peer is as 122 specified in that SAN in the certificate. If the realm in the 123 KRB5PrincipalName structure is specified, it MUST be the PKU2U 124 realm. 126 o If the X.509 certificate of the peer contains a dNSName SAN 127 [RFC3280], then unless otherwise specified the peer's Kerberos 128 principal name is a two-component NT-SRV-HST type name as defined 129 in Section 6.2.1 of [RFC4120], with the first component as "host" 130 and the second component as the name in the dNSName SAN of the 131 certificate, and the realm of this Kerberos principal is the PKU2U 132 realm. 134 It should be noted that a certificate that does not have any of the 135 above name attributes can be used in PKU2U as long as there is a 136 binding between the key pair and the peer principal that can be 137 verified, and such bindings can be maintained via a trusted table 138 such as a database that the peers learn via leap-of-faith ways, or 139 via PKI where the certificate is the binding. 141 A Distinguished Name (DN) can be transformed into a string and 142 represented as the NT-X500-PRINCIPAL name type, but the current 143 definition of this name type in [RFC4120] does not guarantee a 144 canonical form. Additional work is anticipated to start with 145 [RFC4514] but add further constraints: require Distinguished Encoding 146 Rules (DER) [X680] [X690] for values of unknown syntax, restrict the 147 use of escape characters, force the case of case-insensitive string 148 values, etc. It is anticipated that any name that appears in a 149 certificate, either as its DN or as a SAN, can be used via 150 GSS_Import_name() and GSS_Acquire_cred(). In order to do that, a 151 GSS-API name type is expected to be defined for each kind of PKI name 152 (DN, and every kind of SAN that may be useful), and a generic human- 153 readable syntax is expected to be defined for each such name-type. 154 The DN remains, however, as the canonical principal name. This work 155 is out of the scope to this document and it is generic to integrating 156 Distinguished Names into GSS-API. 158 Implementations conforming to this document MUST support the binding 159 schema specified in this section. 161 The rest of this document assumes there is a binding between a 162 Kerberos principal name and the asymmetric key pair used for 163 authentication. The Kerberos principal name is returned by GSS-API 164 primitives such as GSS_Export_name() and GSS_Display_name(). 166 5. The Protocol Description and the Context Establishment Tokens 168 The PKU2U protocol is based on [RFC4120], and it can only be used in 169 conjunction with GSS-API. 171 This section describes how PKU2U works and how it differs from 172 [RFC4120]. 174 If initially the initiator has a service ticket to the acceptor, the 175 initiator, acting as the client in the parlance of [RFC4120], 176 performs the client-server authentication exchange according to 177 [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as 178 the server. 180 When the initiator does not have a service ticket to the acceptor, it 181 requests a ticket from the acceptor instead of the KDC by 182 constructing a KRB_AS_REQ message, where the acceptor is identified 183 as the server and the initiator is identified as the client, 184 according to Section 3.1.1 of [RFC4120]. The initiator always 185 includes the PA_PK_AS_REQ pre-authentication data computed according 186 to Section 3.2.1 of [RFC4556]. In a modification to [RFC4120], the 187 KRB_AS_REQ message is not sent directly to the acceptor, but instead 188 returned within the output GSS-API token. GSS_Init_sec_context() 189 returns GSS_S_CONTINUE_NEEDED status [RFC2743] indicating at least 190 one more token is needed in order to establish the context, and the 191 KRB_AS_REQ message is returned as the innerContextToken defined in 192 Section 3.1 of [RFC2743], in the output token. 194 This output token that contains the KRB_AS_REQ message is then passed 195 to GSS_Accept_security_context() as the input token in accordance 196 with GSS-API. The acceptor processes the KRB_AS_REQ request 197 according to Section 3.1.2 of [RFC4120]. The acceptor MUST verify 198 that the server name in the request is that of the acceptor itself. 199 The acceptor validates the pre-authentication data in the request 200 according to Section 3.2.2 of [RFC4556]. The acceptor MUST verify 201 the binding between the initiator's name and the initiator's public 202 key. Unless otherwise specified, the initiator's X.509 certificate 203 MUST contain either the id-pkinit-KPClientAuth [RFC4556] Extended Key 204 Usage (EKU) extension or the id-kp-clientAuth EKU [RFC3280]. 206 If all goes well, processing the KRB_AS_REQ message will result in 207 the creation of a ticket for the initiator to present to the acceptor 208 and the response is a KRB_AS_REP message generated according to 209 Section 3.1.3 of [RFC4120]. 211 If an error occurs, however, the response is a KRB_ERROR message 212 generated according to Section 3.1.4 of [RFC4120]. 214 In other words, the output token of GSS_Accept_security_context() is 215 a KRB_AS_REP message if a ticket was created or a KRB_ERROR message 216 if there was an error while processing the request or the local 217 policy prevented a ticket from being issued. The reply token is then 218 passed to the initiator as the input token to GSS_Init_sec_context(). 220 The initiator then processes the reply token according to Section 221 3.1.5 of [RFC4120] if a ticket has been returned. Upon receipt of 222 the KRB_AS_REP message, the initiator MUST validate the PA_PK_AS_REP 223 pre-authentication data in the reply according to Section 3.2.4 of 224 [RFC4556]. The inclusion of the EKU KeyPurposeId [RFC3280] id- 225 pkinit-KPKdc in the X.509 certificate in the response is not 226 applicable when PKU2U is used because there is no KDC involved in 227 this protocol. The initiator MUST verify the binding between the 228 acceptor's name and the acceptor's public key. 230 Furthermore, PKU2U differs from [RFC4556] in that it allows the use 231 of self-signed certificates given the binding between the named 232 principal and the public key can be verified and cannot be spoofed. 234 The GSS-API acceptor is identified using the targ_name parameter of 235 the GSS_Init_sec_context() call, the initiator MUST verify the 236 binding between the targ_name and the acceptor in order to 237 authenticate the acceptor. In addition, unless otherwise specified 238 the acceptor's X.509 certificate MUST contain either the id-kp- 239 serverAuth EKU [RFC3280] or the id-pkinit-KPClientAuth EKU [RFC4556]. 241 If an error message was returned, the initiator processes the 242 response according to Section 3.1.6 of [RFC4120]. 244 With the obtained ticket, the initiator then, acting as the client in 245 the parlance of [RFC4120], performs the client-server authentication 246 exchange according to [RFC4121] and Section 3.2 of [RFC4120], with 247 the acceptor acting as the server. 249 To recapitulate, the acceptor and the initiator communicate by 250 tunneling the authentication service exchange messages through the 251 use of the GSS-API tokens and application traffic. The reliable 252 delivery of the authentication service exchange messages at the GSS- 253 API token level is mandatory. In the event of message loss, message 254 duplication, or out of order message delivery, the security context 255 MUST fail to establish. 257 The syntax of the initial context establishment token follows the 258 initialContextToken syntax defined in Section 3.1 of [RFC2743]. 259 PKU2U is identified by the Objection Identifier (OID) id-kerberos- 260 pku2u. 262 id-kerberos-pku2u ::= 263 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 264 pku2u(7) } 266 Subsequent context establishment tokens MUST NOT be encapsulated in 267 this GSS-API generic token framing. 269 The innerToken described in section 3.1 of [RFC2743] and subsequent 270 GSS-API mechanism tokens have the following formats: it starts with a 271 two-octet token-identifier (TOK_ID), followed by a Kerberos message. 272 The TOK_ID values for the KRB_AS_REQ message and the KRB_AS_REP 273 message are defined in the table blow: 275 Token TOK_ID Value in Hex 276 ----------------------------------------------- 277 KRB_AS_REQ 05 00 278 KRB_AS_REP 06 00 280 The TOK_ID values for all other Kerberos messages are the same as 281 defined in [RFC4121]. 283 By using anonymous PKINIT [KRB-ANON], PKU2U can provide server- 284 authentication without revealing the client's identity. 286 6. The GSS-API Binding for PKU2U 288 Section 5 defines the context establishment tokens. PKU2U per- 289 message tokens are defined as the per-message tokens in [RFC4121]. 291 The Kerberos principal name form and the host-based service Name 292 described in [RFC1964] MUST be supported by implementations 293 conforming to this specification. 295 For implementations comforming to this specification, the 296 authenticator subkey in the AP-REQ [RFC4120] [RFC4121] MUST alway be 297 present, and the Exts field in the GSS-API authenticator [GSS-EXTS] 298 MUST contain an extension of the type GSS_EXTS_FINISHED and the 299 extension data contains the ASN.1 DER encoding of the structure KRB- 300 FINISHED. 302 GSS_EXTS_FINISHED TBA 303 --- The type for the checksum extension. 305 KRB-FINISHED ::= SEQUENCE { 306 gss-mic [1] Checksum, 307 -- Contains the checksum of the GSS-API tokens 308 -- exchanged between the initiator and the acceptor, 309 -- and prior to the containing AP-REQ GSS-API token. 310 -- The checksum is performed over the GSS-API 311 -- tokens in the order that the tokens were sent. 312 ... 313 } 315 The gss-mic field contains a checksum of all the GSS-API tokens sent 316 from the initiator to the acceptor in the order they were sent, prior 317 to the current token. This checksum is performed over these GSS-API 318 tokens in the order that the tokens were sent by the initiator and 319 the acceptor. In the parlance of [RFC3961], the checksum type is the 320 required checksum type for the enctype of the subkey in the 321 authenticator, the protocol key for the checksum operation is the 322 authenticator subkey, and the key usage number is KEY_USAGE_FINISHED. 324 KEY_USAGE_FINISHED 41 326 The GSS-API acceptor MUST then verify the checksum contained in the 327 GSS_EXTS_FINISHED extension. This checksum provides integrity 328 protection for the messages exchanged including the unauthenticated 329 clear texts in the Kerberos messages exchanged between the two 330 parties. 332 7. Guidelines for Credentials Selection 334 If a peer, either the initiator or the acceptor, has multiple pairs 335 of public-key private keys, a choice is to be made in choosing the 336 best fit. The trustedCertifiers field in the PA-PK-AS-REQ structure 337 [RFC4556] SHOULD be filled by the initiator, to provide hints for 338 guiding the selection of an appropriate certificate chain by the 339 acceptor. If the initiator's X.509 certificate cannot be validated 340 according to [RFC3280], the acceptor SHOULD send back the TD-TRUSTED- 341 CERTIFIERS structure [RFC4556] that provides hints for guiding the 342 selection of an appropriate certificate by the initiator. 344 It is RECOMMENDED that implementations of this protocol expose 345 sufficient information based on the hints described above to the 346 users and allow the certificates to be selected interactively. 348 If the certificates cannot be selected interactively, and multiple 349 certificates can be used, it is RECOMMENDED that implementations fail 350 the context establishment thus avoid confusions caused by an 351 unexpected programmatic selection. 353 8. Security Considerations 355 The security considerations in [RFC4556] apply here. It is crucial 356 that both the initiator and the acceptor MUST be able to verify the 357 binding between the signing key and the associated identity. 359 9. Acknowledgements 361 The authors would like to thank Jeffrey Hutzelman for his insightful 362 comments on the earlier revisions of this document. 364 In addition, the following individuals have provided review comments 365 for this document: Nicolas Williams, Sam Hartman, Leif Johansson, 366 Olga Kornievskaia, Martin Rex, and Sunil Gottumukkala. 368 Ari Medvinsky provided help in editing the initial revisions of this 369 document. 371 The text for the DN mapping is compiled directly from the email 372 discussions among the following individuals: Howard Chu, Martin Rex, 373 Nicolas Williams, Jeffrey Hutzelman, Kevin Coffman, Henry B. Hotz, 374 Leif Johansson, and Olga Kornievskaia. Howard and Jeffery clearly 375 illustrated the challenges in creating a unique mapping, while 376 Nicolas and Martin demonstrated the relevance and interactions to 377 GSS-API and Kerberos. 379 10. IANA Considerations 381 Section 3 defines the PKU2U realm. The IANA registry for the 382 reserved names should be updated to reference this document. 384 This document defines GSS_EXTS_FINISHED extension type. The 385 corresponding IANA registry need to be updated to reference this 386 document. 388 11. References 389 11.1. Normative References 391 [GSS-EXTS] 392 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 393 Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility, 394 work in progress. 396 [KRB-ANON] 397 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 398 draft-ietf-krb-wg-anon, work in progress. 400 [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints", 401 draft-ietf-krb-wg-naming, work in progress. 403 [REFERALS] Raeburn, K. and L. Zhu, "Generating KDC Referrals to 404 Locate Kerberos Realms, 405 draft-ietf-krb-wg-kerberos-referrals, work in progress. 407 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 408 RFC 1964, June 1996. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC2743] Linn, J., "Generic Security Service Application Program 414 Interface Version 2, Update 1", RFC 2743, January 2000. 416 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 417 X.509 Public Key Infrastructure Certificate and 418 Certificate Revocation List (CRL) Profile", RFC 3280, 419 April 2002. 421 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 422 Kerberos 5", RFC 3961, February 2005. 424 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 425 Kerberos Network Authentication Service (V5)", RFC 4120, 426 July 2005. 428 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 429 Version 5 Generic Security Service Application Program 430 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 431 July 2005. 433 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 434 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 436 11.2. Informative References 438 [KRB-ANON] 439 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 440 draft-ietf-krb-wg-anon-04.txt (work in progress), 2007. 442 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 443 (LDAP): String Representation of Distinguished Names", 444 RFC 4514, June 2006. 446 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 447 Information technology - Abstract Syntax Notation One 448 (ASN.1): Specification of basic notation. 450 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 451 Information technology - ASN.1 encoding Rules: 452 Specification of Basic Encoding Rules (BER), Canonical 453 Encoding Rules (CER) and Distinguished Encoding Rules 454 (DER). 456 Appendix A. PKU2U ASN.1 Module 458 PKU2U-SPEC { 459 iso(1) identified-organization(3) dod(6) internet(1) 460 security(5) kerberosV5(2) modules(4) pku2u(TBA) 461 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 463 IMPORTS 465 Checksum 466 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 467 dod(6) internet(1) security(5) kerberosV5(2) 468 modules(4) krb5spec2(2) }; 469 -- as defined in RFC 4120. 471 KRB-FINISHED ::= SEQUENCE { 472 gss-mic [1] Checksum, 473 -- Contains the checksum of the GSS-API tokens 474 -- exchanged between the initiator and the acceptor, 475 -- and prior to the containing AP-REQ GSS-API token. 476 -- The checksum is performed over the GSS-API 477 -- tokens in the order that the tokens were sent. 478 ... 479 } 481 END 483 Authors' Addresses 485 Larry Zhu 486 Microsoft Corporation 487 One Microsoft Way 488 Redmond, WA 98052 489 US 491 Email: lzhu@microsoft.com 493 Jeffery Altman 494 Secure Endpoints 495 255 W 94th St 496 New York, NY 10025 497 US 499 Email: jaltman@secure-endpoints.com 501 Full Copyright Statement 503 Copyright (C) The IETF Trust (2008). 505 This document is subject to the rights, licenses and restrictions 506 contained in BCP 78, and except as set forth therein, the authors 507 retain all their rights. 509 This document and the information contained herein are provided on an 510 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 511 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 512 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 513 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 514 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 515 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 517 Intellectual Property 519 The IETF takes no position regarding the validity or scope of any 520 Intellectual Property Rights or other rights that might be claimed to 521 pertain to the implementation or use of the technology described in 522 this document or the extent to which any license under such rights 523 might or might not be available; nor does it represent that it has 524 made any independent effort to identify any such rights. Information 525 on the procedures with respect to rights in RFC documents can be 526 found in BCP 78 and BCP 79. 528 Copies of IPR disclosures made to the IETF Secretariat and any 529 assurances of licenses to be made available, or the result of an 530 attempt made to obtain a general license or permission for the use of 531 such proprietary rights by implementers or users of this 532 specification can be obtained from the IETF on-line IPR repository at 533 http://www.ietf.org/ipr. 535 The IETF invites any interested party to bring to its attention any 536 copyrights, patents or patent applications, or other proprietary 537 rights that may cover technology that may be required to implement 538 this standard. Please address the information to the IETF at 539 ietf-ipr@ietf.org. 541 Acknowledgment 543 Funding for the RFC Editor function is provided by the IETF 544 Administrative Support Activity (IASA).