idnits 2.17.00 (12 Aug 2021) /tmp/idnits45159/draft-eronen-ipsec-ikev2-eap-auth-01.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 518. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 534), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (May 6, 2004) is 6588 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: 'CERTREQ' on line 211 == Unused Reference: '8' is defined on line 377, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 382, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 405, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 409, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 413, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 424, but no explicit reference was found in the text == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-04 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 == Outdated reference: draft-ietf-kink-kink has been published as RFC 4430 == Outdated reference: draft-tschofenig-eap-ikev2 has been published as RFC 5106 Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC P. Eronen 2 Internet-Draft Nokia 3 Expires: November 4, 2004 H. Tschofenig 4 Siemens 5 May 6, 2004 7 Extension for EAP Authentication in IKEv2 8 draft-eronen-ipsec-ikev2-eap-auth-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 4, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 IKEv2 specifies that EAP authentication must be used together with 41 public key signature based responder authentication. This is 42 necessary with old EAP methods that provide only unilateral 43 authentication using e.g. one-time passwords or token cards. 45 This document specifies how EAP methods that provide mutual 46 authentication and key agreement can be used to provide extensible 47 responder authentication for IKEv2 based on other methods than public 48 key signatures. 50 1. Introduction 52 The Extensible Authentication Protocol (EAP), defined in [7], is an 53 authentication framework which supports multiple authentication 54 mechanisms. Today, EAP has been implemented at end hosts and routers 55 that connect via switched circuits or dial-up lines using PPP [16], 56 IEEE 802 wired switches [10], and IEEE 802.11 wireless access points 57 [12]. 59 One of the advantages of the EAP architecture is its flexibility. EAP 60 is used to select a specific authentication mechanism, typically 61 after the authenticator requests more information in order to 62 determine the specific authentication method to be used. Rather than 63 requiring the authenticator (e.g., wireless LAN access point) to be 64 updated to support each new authentication method, EAP permits the 65 use of a backend authentication server which may implement some or 66 all authentication methods. 68 IKEv2 [3] is a component of IPsec used for performing mutual 69 authentication and establishing and maintaining security associations 70 for IPsec ESP and AH. In addition to supporting authentication using 71 public key signatures and shared secrets, IKEv2 also supports EAP 72 authentication. 74 IKEv2 provides EAP authentication since it was recognized that public 75 key signatures and shared secrets are not flexible enough to meet the 76 requirements of many deployment scenarios. By using EAP, IKEv2 can 77 leverage existing authentication infrastructure and credential 78 databases, since EAP allows users to choose a method suitable for 79 existing credentials, and also makes separation of the IKEv2 80 responder (VPN gateway) from the EAP authentication endpoint (backend 81 AAA server) easier. 83 Some older EAP methods are designed for unilateral authentication 84 only (that is, EAP peer to EAP server). These methods are used in 85 conjunction with IKEv2 public key based authentication of the 86 responder to the initiator. It is expected that this approach is 87 especially useful for "road warrior" VPN gateways that use, for 88 instance, one-time passwords or token cards to authenticate the 89 clients. 91 However, most newer EAP methods, such as those typically used with 92 IEEE 802.11i wireless LANs, provide mutual authentication and key 93 agreement. Currently, IKEv2 specifies that also these EAP methods 94 must be used together with public key signature based responder 95 authentication. 97 In some environments, requiring the deployment of PKI for just this 98 purpose can be counterproductive. Deploying new infrastructure can be 99 expensive, and it may weaken security by creating new 100 vulnerabilities. Mutually authenticating EAP methods alone can 101 provide a sufficient level of security in many circumstances, and 102 indeed, IEEE 802.11i uses EAP without any PKI for authenticating the 103 WLAN access points. 105 This document specifies how EAP methods that offer mutual 106 authentication and key agreement can be used to provide responder 107 authentication in IKEv2 completely based on EAP. 109 1.1 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [2]. 115 2. Scenarios 117 In this section we describe two scenarios for extensible 118 authentication within IKEv2. These scenarios are intended to be 119 illustrative examples rather than specifying how things should be 120 done. 122 Figure 1 shows a configuration where the EAP and the IKEv2 endpoints 123 are co-located. Authenticating the IKEv2 responder using both EAP and 124 public key signatures is redundant. Offering EAP based authentication 125 has the advantage that multiple different authentication and key 126 exchange protocols are available with EAP with different security 127 properties (such as strong password based protocols, protocols 128 offering user identity confidentiality and many more). As an example 129 it is possible to use GSS-API support within EAP [5] to support 130 Kerberos based authentication which effectively replaces the need for 131 KINK [17]. 133 +------+-----+ +------------+ 134 O | IKEv2 | | IKEv2 | 135 /|\ | Initiator |<---////////////////////--->| Responder | 136 / \ +------------+ IKEv2 +------------+ 137 User | EAP Peer | Exchange | EAP Server | 138 +------------+ +------------+ 140 Figure 1: EAP and IKEv2 endpoints are co-located 142 Figure 2 shows a typical corporate network access scenario. The 143 initiator (client) interacts with the responder (VPN gateway) in the 144 corporate network. The EAP exchange within IKE runs between the 145 client and the home AAA server. As a result of a successful EAP 146 authentication protocol run, session keys are established and sent 147 from the AAA server to the VPN gateway, and then used to authenticate 148 the IKEv2 SA with AUTH payloads. 150 The protocol used between the VPN gateway and AAA server could be, 151 for instance, Diameter [7] or RADIUS [4]. See Section 5 for related 152 security considerations. 154 +-------------------------------+ 155 | Corporate network | 156 | | 157 +-----------+ +--------+ | 158 | IKEv2 | AAA | Home | | 159 IKEv2 +////----->+ Responder +<---------->+ AAA | | 160 Exchange / | (VPN GW) | (RADIUS/ | Server | | 161 / +-----------+ Diameter) +--------+ | 162 / | carrying EAP | 163 | | | 164 | +-------------------------------+ 165 v 166 +------+-----+ 167 o | IKEv2 | 168 /|\ | Initiator | 169 / \ | VPN client | 170 User +------------+ 172 Figure 2: Corporate Network Access 174 3. Solution 176 IKEv2 specifies that when the EAP method establishes a shared secret 177 key, that key is used by both the initiator and responder to generate 178 an AUTH payload (thus authenticating the IKEv2 SA set up by messages 179 1 and 2). 181 When used together with public key responder authentication, the 182 responder is in effect authenticated using two different methods: the 183 public key signature AUTH payload in message 4, and the EAP-based 184 AUTH payload later. 186 If the initiator does not wish to use public key based responder 187 authentication, it includes an EAP_ONLY_AUTHENTICATION notification 188 payload (type TBD-BY-IANA) in message 3. There is no additional data 189 associated with this notification. 191 If the responder supports this notification, it omits the public key 192 based AUTH payload and CERT payloads from message 4. 194 If the responder does not support the EAP_ONLY_AUTHENTICATION 195 notification, it ignores the notification payload, and includes the 196 AUTH payload in message 4. In this case the initiator can, based on 197 its local policy, choose to either ignore the AUTH payload, or verify 198 it and any associated certificates as usual. 200 Both the initiator and responder MUST verify that the EAP method 201 actually used provided mutual authentication and established a shared 202 secret key. The AUTH payloads sent after EAP Success MUST use the 203 EAP-generated key, and MUST NOT use SK_pi or SK_pr. 205 An IKEv2 message exchange with this modification is shown below: 207 Initiator Responder 208 ----------- ----------- 209 HDR, SAi1, KEi, Ni --> 211 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 213 HDR, SK { IDi, [IDr,] EAP_ONLY_AUTHENTICATION, 214 SAi2, TSi, TSr} --> 216 <-- HDR, SK { IDr, EAP(Request) } 218 HDR, SK { EAP(Response) } --> 220 <-- HDR, SK { EAP(Request) } 222 HDR, SK { EAP(Response) } --> 224 <-- HDR, SK { EAP(Success) } 226 HDR, SK { AUTH } --> 228 <-- HDR, SK { AUTH, SAr2, TSi, TSr } 230 4. IANA considerations 232 This document defines a new IKEv2 Notification Payload type, 233 EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must be 234 assigned a new type number from the "status types" range. 236 This document does not define any new namespaces to be managed by 237 IANA. 239 5. Security Considerations 241 Security considerations applicable to all EAP methods are discussed 242 in [1]. The EAP Key Management Framework [6] deals with issues that 243 arise when EAP is used as a part of a larger system. 245 5.1 Authentication of IKEv2 SA 247 It is important to note that the IKEv2 SA is not authenticated by 248 just running an EAP conversation: the crucial step is the AUTH 249 payload based on the EAP-generated key. Thus, EAP methods that do not 250 provide mutual authentication or establish a shared secret key MUST 251 NOT be used with the modifications presented in this document. 253 5.2 Authentication with separated IKEv2 responder/EAP server 255 As described in Section 2, the EAP conversation can terminate either 256 at the IKEv2 responder or at a backend AAA server. 258 If the EAP method terminates at the IKEv2 responder then no key 259 transport via the AAA infrastructure is required. Pre-shared secret 260 and public key based authentication offered by IKEv2 is then replaced 261 by a wider range of authentication and key exchange methods. 263 However, typically EAP will be used with a backend AAA server. See 264 [6] for a more complete discussion of the related security issues; 265 here we provide only a short summary. 267 When a backend server is used, there are actually two authentication 268 exchanges: the EAP method between the client and the AAA server, and 269 another authentication between the AAA server and IKEv2 gateway. The 270 AAA server authenticates the client using the selected EAP method, 271 and they establish a session key. The AAA server then sends this key 272 to the IKEv2 gateway over a connection authenticated using e.g. IPsec 273 or TLS. 275 Some EAP methods do not have any concept of pass-through 276 authenticator (e.g. NAS or IKEv2 gateway) identity, and these two 277 authentications remain quite independent of each other. That is, 278 after the client has verified the AUTH payload sent by the IKEv2 279 gateway, it knows that it is talking to SOME gateway trusted by the 280 home AAA server, but not which one. The situation is somewhat similar 281 if a single cryptographic hardware accelerator, containing a single 282 private key, would be shared between multiple IKEv2 gateways (perhaps 283 in some kind of cluster configuration). In particular, if one of the 284 gateways is compromised, it can impersonate any of the other gateways 285 towards the user (until the compromise is discovered and access 286 rights revoked). 288 In some environments it is not desirable to trust the IKEv2 gateways 289 this much (also known as the "Lying NAS Problem"). EAP methods that 290 provide what is called "connection binding" or "channel binding" 291 transport some identity or identities of the gateway (or WLAN access 292 point/NAS) inside the EAP method. Then the AAA server can check that 293 it is indeed sending the key to the gateway expected by the client. 295 In some deployment configurations, AAA proxies may be present between 296 the IKEv2 gateway and the backend AAA server. These AAA proxies MUST 297 be trusted for secure operation, and therefore SHOULD be avoided when 298 possible; see [7] and [6] for more discussion. 300 5.3 Protection of EAP payloads 302 Although the EAP payloads are encrypted and integrity protected with 303 SK_e/SK_a, this does not provide any protection against active 304 attackers. Until the AUTH payload has been received and verified, a 305 man-in-the-middle can change the KEi/KEr payloads and eavesdrop or 306 modify the EAP payloads. 308 In IEEE 802.11i WLANs, the EAP payloads are neither encrypted nor 309 integrity protected (by the link layer), so EAP methods are typically 310 designed to take that into account. 312 In particular, EAP methods that are vulnerable to dictionary attacks 313 when used in WLANs are still vulnerable (to active attackers) when 314 run inside IKEv2. 316 5.4 User identity confidentiality 318 IKEv2 provides confidentiality for the initiator identity against 319 passive eavesdroppers, but not against active attackers. The 320 initiator announces its identity first (in message #3), before the 321 responder has been authenticated. The usage of EAP in IKEv2 does not 322 change this situation, since the ID payload in message #3 is used 323 instead of the EAP Identity Request/Response exchange. This is 324 somewhat unfortunate since when EAP is used with public key 325 authentication of the responder, it would be possible to provide 326 active user identity confidentiality for the initiator. 328 IKEv2 protects the responder identity even against active attacks. 329 This property cannot be provided when using EAP. If public key 330 responder authentication is used in addition to EAP, the responder 331 reveals its identity before authenticating the initiator. If only EAP 332 is used (as proposed in this document), the situation depends on the 333 EAP method used (in some EAP methods, the server reveals its identity 334 first). 336 Hence, if active user identity confidentiality for the initiator is 337 required then EAP methods that offer this functionality have to be 338 used (see [1], Section 7.3). 340 6. Acknowledgments 342 This document borrows some text from [1], [3], and [7]. We would also 343 like to thank Hugo Krawczyk for interesting discussions about this 344 topic. 346 7. References 348 7.1 Normative References 350 [1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 351 Levkowetz, "Extensible Authentication Protocol (EAP)", 352 draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004. 354 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 355 Levels", RFC 2119, March 1997. 357 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 358 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004. 360 7.2 Informative References 362 [4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 363 In User Service) Support For Extensible Authentication Protocol 364 (EAP)", RFC 3579, September 2003. 366 [5] Aboba, B. and D. Simon, "EAP GSS Authentication Protocol", 367 draft-aboba-pppext-eapgss-12 (work in progress), April 2002. 369 [6] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP Key 370 Management Framework", draft-ietf-eap-keying-01 (work in 371 progress), October 2003. 373 [7] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 374 Authentication Protocol (EAP) Application", 375 draft-ietf-aaa-eap-05 (work in progress), April 2004. 377 [8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, 378 "Protocol for Carrying Authentication for Network Access 379 (PANA)", draft-ietf-pana-pana-03 (work in progress), February 380 2004. 382 [9] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication 383 Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-04 (work in 384 progress), April 2004. 386 [10] Institute of Electrical and Electronics Engineers, "Local and 387 Metropolitan Area Networks: Port-Based Network Access Control", 388 IEEE Standard 802.1X-2001, 2001. 390 [11] Institute of Electrical and Electronics Engineers, "Information 391 technology - Telecommunications and information exchange 392 between systems - Local and metropolitan area networks - 393 Specific Requirements Part 11: Wireless LAN Medium Access 394 Control (MAC) and Physical Layer (PHY) Specifications", IEEE 395 Standard 802.11-1999, 1999. 397 [12] Institute of Electrical and Electronics Engineers, "IEEE 398 Standard for Information technology - Telecommunications and 399 information exchange between systems - Local and metropolitan 400 area networks - Specific requirements - Part 11: Wireless 401 Medium Access Control (MAC) and Physical Layer (PHY) 402 specifications: Amendment 6: Medium Access Control (MAC) 403 Security Enhancements", IEEE Draft 802.11i/D10.0, April 2004. 405 [13] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected 406 EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07 407 (work in progress), October 2003. 409 [14] Puthenkulam, J., "The Compound Authentication Binding Problem", 410 draft-puthenkulam-eap-binding-04 (work in progress), October 411 2003. 413 [15] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 414 Authentication Dial In User Service (RADIUS)", RFC 2865, June 415 2000. 417 [16] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 418 1661, July 1994. 420 [17] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of 421 Keys (KINK)", draft-ietf-kink-kink-05 (work in progress), 422 January 2003. 424 [18] Tschofenig, H., Kroeselberg, D. and Y. Ohba, "EAP IKEv2 Method 425 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in progress), 426 February 2004. 428 Authors' Addresses 430 Pasi Eronen 431 Nokia Research Center 432 P.O. Box 407 433 FIN-00045 Nokia Group 434 Finland 436 EMail: pasi.eronen@nokia.com 438 Hannes Tschofenig 439 Siemens 440 Otto-Hahn-Ring 6 441 Munich, Bayern 81739 442 Germany 444 EMail: Hannes.Tschofenig@siemens.com 446 Appendix A. Alternative Approaches 448 In this section we list alternatives which have been considered 449 during the work on this document. Finally, the solution presented in 450 Section 3 seems to fit better into IKEv2. 452 A.1 Ignore AUTH payload at the initiator 454 With this approach, the initiator simply ignores the AUTH payload in 455 message #4 (but obviously must check the second AUTH payload later!). 456 The main advantage of this approach is that no protocol modifications 457 are required and no signature verification is required. 459 The initiator could signal the responder (using a NOTIFY payload) 460 that it did not verify the first AUTH payload. 462 A.2 Unauthenticated PKs in AUTH payload (message 4) 464 The first solution approach suggests the use of unauthenticated 465 public keys in the public key signature AUTH payload (for message 4). 467 That is, the initiator verifies the signature in the AUTH payload, 468 but does not verify that the public key indeed belongs to the 469 intended party (using certificates)--since it doesn't have a PKI that 470 would allow this. This could be used with X.509 certificates (the 471 initiator ignores all other fields of the certificate except the 472 public key), or "Raw RSA Key" CERT payloads. 474 This approach has the advantage that initiators that wish to perform 475 certificate-based responder authentication (in addition to EAP) may 476 do so, without requiring the responder to handle these cases 477 separately. 479 If using RSA, the overhead of signature verification is quite small 480 (compared to g^xy calculation). 482 A.3 Use EAP derived session keys for IKEv2 484 It has been proposed that when using an EAP methods that provides 485 mutual authentication and key agreement, the IKEv2 Diffie-Hellman 486 exchange could also be omitted. This would mean that the sessions 487 keys for IPsec SAs established later would rely only on EAP-provided 488 keys. 490 It seems the only benefit of this approach is saving some computation 491 time (g^xy calculation). This approach requires designing a 492 completely new protocol (which would not resemble IKEv2 anymore) we 493 do not believe that it should be considered. Nevertheless, we include 494 it for completeness. 496 Intellectual Property Statement 498 The IETF takes no position regarding the validity or scope of any 499 Intellectual Property Rights or other rights that might be claimed to 500 pertain to the implementation or use of the technology described in 501 this document or the extent to which any license under such rights 502 might or might not be available; nor does it represent that it has 503 made any independent effort to identify any such rights. Information 504 on the IETF's procedures with respect to rights in IETF Documents can 505 be found in BCP 78 and BCP 79. 507 Copies of IPR disclosures made to the IETF Secretariat and any 508 assurances of licenses to be made available, or the result of an 509 attempt made to obtain a general license or permission for the use of 510 such proprietary rights by implementers or users of this 511 specification can be obtained from the IETF on-line IPR repository at 512 http://www.ietf.org/ipr. 514 The IETF invites any interested party to bring to its attention any 515 copyrights, patents or patent applications, or other proprietary 516 rights that may cover technology that may be required to implement 517 this standard. Please address the information to the IETF at 518 ietf-ipr@ietf.org. 520 Disclaimer of Validity 522 This document and the information contained herein are provided on an 523 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 524 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 525 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 526 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 527 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 528 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Copyright Statement 532 Copyright (C) The Internet Society (2004). This document is subject 533 to the rights, licenses and restrictions contained in BCP 78, and 534 except as set forth therein, the authors retain all their rights. 536 Acknowledgment 538 Funding for the RFC Editor function is currently provided by the 539 Internet Society.