idnits 2.17.1 draft-ietf-hokey-reauth-ps-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 (July 24, 2007) is 6120 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-18 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOKEY Working Group T. Clancy, Ed. 3 Internet-Draft LTS 4 Intended status: Informational July 24, 2007 5 Expires: January 25, 2008 7 Handover Key Management and Re-authentication Problem Statement 8 draft-ietf-hokey-reauth-ps-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 25, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes the Handover Keying (HOKEY) problem 42 statement. The current EAP keying framework is not designed to 43 support re-authentication and handovers. This often cause 44 unacceptable latency in various mobile wireless environments. HOKEY 45 plans to address these HOKEY plans to address these problems by 46 implementing a generic mechanism to reuse derived EAP keying material 47 for handover. 49 Table of Contents 51 1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 58 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 59 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 60 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 61 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 62 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 63 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 64 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 65 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 10 66 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 67 7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 13 76 1. Authors 78 The following authors contributed to the HOKEY problem statement 79 draft: 81 o Julien Bournelle, France Telecom R&D, 82 julien.bournelle@orange-ftgroup.com 83 o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com 84 o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es 85 o Madjid Nakhjiri, Huawei, mnakhjiri@huawei.com 86 o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com 87 o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com 88 o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com 90 2. Introduction 92 The extensible authentication protocol (EAP), specified in [RFC3748] 93 is a generic framework supporting multiple authentication methods. 94 The primary purpose of EAP is network access control. It also 95 supports exporting session keys derived during the authentication. 96 The EAP keying hierarchy defines two keys that are derived at the top 97 level, the master session key (MSK) and the extended MSK (EMSK). 99 In many common deployment scenario, an EAP peer and EAP server 100 authenticate each other through a third party known as the pass- 101 through authenticator (hereafter referred to as simply 102 "authenticator"). The authenticator is responsible for translating 103 EAP packets from the layer 2 (L2) or layer 3 (L3) network access 104 technology to the AAA protocol. 106 According to [RFC3748], after successful authentication, the server 107 transports the MSK to the authenticator. The underlying L2 or L3 108 protocol uses the MSK to derive additional keys, including the 109 transient session keys (TSK) used per-packet access encryption and 110 enforcement. Figure Figure 1 depicts this process. 112 +--------+ +---------+ +--------+ 113 | EAP |<----->| Authen- |<------------------->| EAP | 114 | Client | L2/L3 | ticator | AAA | Server | 115 +--------+ +---------+ +--------+ 116 ^ ^ 117 | +---------+ | 118 \-------------------------->| Authen- |<--------/ 119 L2/L3 | ticator | AAA 120 +---------+ 122 Initial Authentication: 124 <----------------- EAP Authentication -------------> 125 <------ MSK Transport ------------- 126 <- TSK Generation -> 128 Re-Authentication / Handover: 130 <----------------- EAP Authentication -------------> 131 <- MSK Transport - 132 <---------- TSK Generation ---------> 134 Figure 1: Logical diagram of EAP authentication and key derivation 135 using passthrough authenticator 137 Note that while the authenticator is one logical device, there can be 138 many physical devices involved. For example, in the CAPWAP model 139 [RFC3990] WTPs communicate using L2 protocols with the EAP client and 140 ACs communicate using AAA to the EAP server, while using CAPWAP 141 protocols to communicate with each other. Depending on the 142 configuration, authenticator features can be split in a variety of 143 ways between physical devices, however from the EAP perspective there 144 is only one logical authenticator. 146 The current models of EAP authentication and keying are unfortunately 147 not efficient in case of mobile and wireless networks. When a peer 148 arrives at the new authenticator, or is expected to re-affirm its 149 access through the current authenticator, the security restraints 150 will require the peer to run an EAP method irrespective of whether it 151 has been authenticated to the network recently and has unexpired 152 keying material. A full EAP method execution involves several round 153 trips between the EAP peer and the server. 155 There have been attempts to solve the problem of efficient re- 156 authentication in various ways. However, those solutions are either 157 EAP-method specific, EAP lower-layer specific, or are otherwise 158 limited in scope. Furthermore, these solutions do not deal with 159 scenarios involving handovers to new authenticators, or do not 160 conform to the AAA keying requirements specified in [RFC4962]. 162 This document provides a detailed description of EAP efficient re- 163 authentication protocol requirements. 165 3. Terminology 167 In this document, several words are used to signify the requirements 168 of the specification. These words are often capitalized. The key 169 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 170 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 171 are to be interpreted as described in [RFC2119]. 173 This document follows the terminology that has been defined in 174 [RFC3748] and the EAP Keying Framework [I-D.ietf-eap-keying]. 176 4. Problem Statement 178 When a peer needs to re-affirm access to an authenticator or moves 179 from one authenticator and reattaches to another authenticator, the 180 current EAP keying model requires the peer to engage in a full EAP 181 exchange with the authentication server in its home domain [RFC3748]. 183 An EAP conversation with a full EAP method run takes several round 184 trips and significant time to complete, causing delays in re- 185 authentication and handover times. Some methods [RFC4187] specify 186 the use of keys and state from the initial authentication to finish 187 subsequent authentications in fewer round trips. However, even in 188 those cases, several round trips to the EAP server are still 189 involved. Furthermore, many commonly-used EAP methods do not offer 190 such a fast re-authentication feature. In summary, it is undesirable 191 to have to run a full EAP method each time a peer associates with a 192 new authenticator or needs to extend its current association with the 193 same authenticator. Furthermore, it is desirable to specify a 194 method-independent, efficient, re-authentication protocol. Keying 195 material from the full authentication can be used to enable efficient 196 re-authentication. 198 Another problem with respect to authentication is when the EAP server 199 is several hops away from the peer, causing too much delay in 200 executing the re-authentication. It is desirable to allow a locally 201 reachable server with EAP efficient re-authentication capability with 202 which the peer can execute such re-authentication without having to 203 involve the original EAP server all the time. An EAP re- 204 authentication solution defined MUST NOT prevent its extension to a 205 fast re-authentication protocol that operates between EAP servers, 206 and the defined keying hierarchy MUST be designed such that this 207 could be supported. 209 These problems are the primary issue to be resolved. In solving 210 them, there are a number of constraints to conform to and those 211 result in some additional work to be done in the area of EAP keying. 213 5. Design Goals 215 The following are the goals and constraints in designing the EAP re- 216 authentication and key management protocol: 218 Lower latency operation: The protocol MUST be responsive to handover 219 and re-authentication latency performance objectives within a 220 mobile access network. A solution that reduces latency as 221 compared to a full EAP authentication will be most favorable. 223 EAP lower-layer independence: Any keying hierarchy and protocol 224 defined MUST be lower layer independent in order to provide the 225 capability over heterogeneous technologies. The defined protocols 226 MAY require some additional support from the lower layers that use 227 it. Any keying hierarchy and protocol defined MUST accommodate 228 inter-technology heterogeneous handover. 230 EAP method independence: Changes to existing EAP methods MUST NOT be 231 required as a result of the re-authentication protocol. There 232 MUST be no requirements imposed on future EAP methods. Note that 233 the only EAP methods for which independence is required are those 234 that conform to the specifications of [I-D.ietf-eap-keying] and 235 [RFC4017]. 237 AAA protocol compatibility and keying: Any modifications to EAP and 238 EAP keying MUST be compatible with RADIUS and Diameter. 239 Extensions to both RADIUS and Diameter to support these EAP 240 modifications are acceptable. The designs and protocols must 241 satisfy the AAA key management requirements specified in 242 [RFC4962]. 244 Compatability: Compatibility and co-existence with compliant 245 ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be 246 provided. The keying hierarchy or protocol extensions MUST NOT 247 preclude the use of CAPWAP or IEEE 802.11r. 249 6. Security Goals 251 The section draws from the guidance provided in [RFC4962] to further 252 define the security goals to be achieved by a complete re- 253 authentication keying solution. 255 6.1. Key Context and Domino Effect 257 Any key MUST have a well-defined scope and MUST be used in a specific 258 context and for the intended use. This specifically means the 259 lifetime and scope of each key MUST be defined clearly so that all 260 entities that are authorized to have access to the key have the same 261 context during the validity period. In a hierarchical key structure, 262 the lifetime of lower level keys MUST NOT exceed the lifetime of 263 higher level keys. This requirement MAY imply that the context and 264 the scope parameters have to be exchanged. Furthermore, the 265 semantics of these parameters MUST be defined to provide proper 266 channel binding specifications. The definition of exact parameter 267 syntax definition is part of the design of the transport protocol 268 used for the parameter exchange and that may be outside scope of this 269 protocol. 271 If a key hierarchy is deployed, compromising lower level keys MUST 272 NOT result in a compromise of higher level keys which they were used 273 to derive the lower level keys. The compromise of keys at each level 274 MUST NOT result in compromise of other keys at the same level. The 275 same principle applies to entities that hold and manage a particular 276 key defined in the key hierarchy. Compromising keys on one 277 authenticator MUST NOT reveal the keys of another authenticator. 278 Note that the compromise of higher-level keys has security 279 implications on lower levels. 281 Guidance on parameters required, caching, storage and deletion 282 procedures to ensure adequate security and authorization provisioning 283 for keying procedures MUST be defined in a solution document. 285 All the keying material MUST be uniquely named so that it can be 286 managed effectively. 288 6.2. Key Freshness 290 As [RFC4962] defines, a fresh key is one that is generated for the 291 intended use. This would mean the key hierarchy MUST provide for 292 creation of multiple cryptographically separate child keys from a 293 root key at higher level. Furthermore, the keying solution needs to 294 provide mechanisms for refreshing each of the keys within the key 295 hierarchy. 297 6.3. Authentication 299 Each party in the handover keying architecture MUST be authenticated 300 to any other party with whom it communicates, and securely provide 301 its identity to any other entity that may require the identity for 302 defining the key scope. The identity provided MUST be meaningful 303 according to the protocol over which the two parties communicate. 305 6.4. Authorization 307 The EAP Key management document [I-D.ietf-eap-keying] discusses 308 several vulnerabilities that are common to handover mechanisms. One 309 important issue arises from the way the authorization decisions might 310 be handled at the AAA server during network access authentication. 311 For example, if AAA proxies are involved, they may also influence in 312 the authorization decision. Furthermore, the reasons for making a 313 particular authorization decision are not communicated to the 314 authenticator. In fact, the authenticator only knows the final 315 authorization result. The proposed solution MUST make efforts to 316 document and mitigate authorization attacks. 318 6.5. Channel Binding 320 Channel Binding procedures are needed to avoid a compromised 321 intermediate authenticator providing unverified and conflicting 322 service information to each of the peer and the EAP server. In the 323 architecture introduced in this document, there are multiple 324 intermediate entities between the peer and the back-end EAP server. 325 Various keys need to be established and scoped between these parties 326 and some of these keys may be parents to other keys. Hence the 327 channel binding for this architecture will need to consider layering 328 intermediate entities at each level to make sure that an entity with 329 higher level of trust can examine the truthfulness of the claims made 330 by intermediate parties. 332 6.6. Transport Aspects 334 Depending on the physical architecture and the functionality of the 335 elements involved, there may be a need for multiple protocols to 336 perform the key transport between entities involved in the handover 337 keying architecture. Thus, a set of requirements for each of these 338 protocols, and the parameters they will carry, MUST be developed. 339 Following the requirement specifications, recommendations will be 340 provided as to whether new protocols or extensions to existing 341 protocols are needed. 343 As mentioned, the use of existing AAA protocols for carrying EAP 344 messages and keying material between the AAA server and AAA clients 345 that have a role within the architecture considered for the keying 346 problem will be carefully examined. Definition of specific 347 parameters, required for keying procedures and to be transferred over 348 any of the links in the architecture, are part of the scope. The 349 relation of the identities used by the transport protocol and the 350 identities used for keying also needs to be explored. 352 7. Use Cases and Related Work 354 In order to further clarify the items listed in scope of the proposed 355 work, this section provides some background on related work and the 356 use cases envisioned for the proposed work. 358 7.1. IEEE 802.11r Applicability 360 One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in 361 the process of specifying a mechanism to avoid the problem of 362 repeated full EAP exchanges in a limited setting, by introducing a 363 two-level key hierarchy. The EAP authenticator is collocated with 364 what is known as an R0 Key Holder (R0-KH), which receives the MSK 365 from the EAP server. A pairwise master key (PMK-R0) is derived from 366 the last 32 octets of the MSK. Subsequently, the R0-KH derives an 367 PMK-R1 to be handed out to the attachment point of the peer. When 368 the peer moves from one R1-KH to another, a new PMK-R1 is generated 369 by the R0-KH and handed out to the new R1-KH. The transport protocol 370 used between the R0-KH and the R1-KH is not specified. 372 In some cases, a mobile may seldom move beyond the domain of the 373 R0-KH and this model works well. A full EAP authentication will 374 generally be repeated when the PMK-R0 expires. However, in general 375 cases mobiles may roam beyond the domain of R0-KHs (or EAP 376 authenticators), and the latency of full EAP authentication remains 377 an issue. 379 Another consideration is that there needs to be a key transfer 380 protocol between the R0-KH and the R1-KH; in other words, there is 381 either a star configuration of security associations between the key 382 holder and a centralized entity that serves as the R0-KH, or if the 383 first authenticator is the default R0-KH, there will be a full-mesh 384 of security associations between all authenticators. This is 385 undesirable. 387 The proposed work on EAP efficient re-authentication protocol aims at 388 addressing re-authentication in a lower layer agnostic manner that 389 also can fill some of the gaps in IEEE 802.11r. 391 7.2. IEEE 802.21 Applicability 393 The IEEE 802.21 working group [IEEE.802-21] is standardizing 394 mechanisms for media-independent handover. More specifically, they 395 are looking at transitions from one link-layer protocol to another, 396 which is currently beyond the scope of the HOKEY charter. 398 The techniques developed within HOKEY could be applicable to IEEE 399 802.21 if the necessary issues with handover between different lower 400 layers can be resolved. In particular, pre-authentication may be 401 more appropriate than re-authentication. 403 7.3. CAPWAP Applicability 405 The IETF CAPWAP WG [RFC3990] is developing a protocol between what is 406 termed an Access Controller (AC) and Wireless Termination Points 407 (WTP). The AC and WTP can be mapped to a WLAN switch and Access 408 Point respectively. The CAPWAP model supports both split and 409 integrated MAC architectures, with the authenticator always being 410 implemented at the AC. 412 The proposed work on EAP efficient re-authentication protocol 413 addresses an inter-authenticator handover problem from an EAP 414 perspective, which applies during handover between ACs. Inter- 415 controller handover is a topic yet to be addressed in great detail 416 and the re-authentication work can potentially address it in an 417 effective manner. 419 7.4. Inter-Technology Handover 421 EAP is used for access authentication by several technologies and is 422 under consideration for use over several other technologies going 423 forward. Given that, it should be feasible to support smoother 424 handover across technologies. That is one of the big advantages of 425 using a common authentication protocol. Authentication procedures 426 typically add substantial handover delays. 428 An EAP peer that has multiple radio technologies (802.11 and GSM, for 429 instance) must perform the full EAP exchange on each interface upon 430 every horizontal or vertical handover. With a method independent EAP 431 efficient re-authentication, it is feasible to support faster 432 handover even in the vertical handover cases, when the peer may be 433 roaming from one technology to another. 435 8. Security Considerations 437 This document details the HOKEY problem statement. Since HOKEY is an 438 authentication protocol, there are a myriad of security-related 439 issues surrounding its development and deployment. 441 In this document, we have detailed a variety of security properties 442 inferred from [RFC4962] to which HOKEY must conform, including the 443 management of key context, scope, freshness, and transport; 444 resistance to attacks based on the domino effect; and authentication 445 and authorization. See section Section 6 for further details. 447 9. IANA Considerations 449 This document does not introduce any new IANA considerations. 451 10. References 453 10.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 459 Levkowetz, "Extensible Authentication Protocol (EAP)", 460 RFC 3748, June 2004. 462 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 463 Authentication Protocol (EAP) Method Requirements for 464 Wireless LANs", RFC 4017, March 2005. 466 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 467 Authorization, and Accounting (AAA) Key Management,", 468 BCP 132, RFC 4962, July 2007. 470 [I-D.ietf-eap-keying] 471 Aboba, B., "Extensible Authentication Protocol (EAP) Key 472 Management Framework", draft-ietf-eap-keying-18 (work in 473 progress), February 2007. 475 10.2. Informative References 477 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 478 Provisioning for Wireless Access Points (CAPWAP) Problem 479 Statement", RFC 3990, February 2005. 481 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 482 Protocol Method for 3rd Generation Authentication and Key 483 Agreement (EAP-AKA)", RFC 4187, January 2006. 485 [IEEE.802-11R-D7.0] 486 "Information technology - Telecommunications and 487 information exchange between systems - Local and 488 metropolitan area networks - Specific requirements - Part 489 11: Wireless LAN Medium Access Control (MAC) and Physical 490 Layer (PHY) specifications - Amendment 2: Fast BSS 491 Transition", IEEE Standard 802.11r, June 2007. 493 [IEEE.802-21] 494 "Media Independent Handover Working Group", IEEE Working 495 Group 802.21. 497 Author's Address 499 T. Charles Clancy, Editor 500 DoD Laboratory for Telecommunications Sciences 501 8080 Greenmead Drive 502 College Park, MD 20740 503 USA 505 Email: clancy@LTSnet.net 507 Full Copyright Statement 509 Copyright (C) The IETF Trust (2007). 511 This document is subject to the rights, licenses and restrictions 512 contained in BCP 78, and except as set forth therein, the authors 513 retain all their rights. 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 518 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 519 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 520 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Intellectual Property 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the procedures with respect to rights in RFC documents can be 532 found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use of 537 such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository at 539 http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at 545 ietf-ipr@ietf.org. 547 Acknowledgment 549 Funding for the RFC Editor function is provided by the IETF 550 Administrative Support Activity (IASA).