idnits 2.17.1 draft-ietf-hokey-reauth-ps-03.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 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. 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 (September 10, 2007) is 6071 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 September 10, 2007 5 Expires: March 13, 2008 7 Handover Key Management and Re-authentication Problem Statement 8 draft-ietf-hokey-reauth-ps-03 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 March 13, 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 11 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]. 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 Lastly, a re-authentication protocol should also be capable of 210 supporting handover keying. Handover keying allows re-authentication 211 keys to be passed to a different domain. Execution of the re- 212 authentication protocol in that domain will then allow handover from 213 one domain to another. 215 These problems are the primary issue to be resolved. In solving 216 them, there are a number of constraints to conform to and those 217 result in some additional work to be done in the area of EAP keying. 219 5. Design Goals 221 The following are the goals and constraints in designing the EAP re- 222 authentication and key management protocol: 224 Lower latency operation: The protocol MUST be responsive to handover 225 and re-authentication latency performance objectives within a 226 mobile access network. A solution that reduces latency as 227 compared to a full EAP authentication will be most favorable. 229 EAP lower-layer independence: Any keying hierarchy and protocol 230 defined MUST be lower layer independent in order to provide the 231 capability over heterogeneous technologies. The defined protocols 232 MAY require some additional support from the lower layers that use 233 it. Any keying hierarchy and protocol defined MUST accommodate 234 inter-technology heterogeneous handover. 236 EAP method independence: Changes to existing EAP methods MUST NOT be 237 required as a result of the re-authentication protocol. There 238 MUST be no requirements imposed on future EAP methods. Note that 239 the only EAP methods for which independence is required are those 240 that conform to the specifications of [I-D.ietf-eap-keying] and 241 [RFC4017]. 243 AAA protocol compatibility and keying: Any modifications to EAP and 244 EAP keying MUST be compatible with RADIUS and Diameter. 245 Extensions to both RADIUS and Diameter to support these EAP 246 modifications are acceptable. The designs and protocols must 247 satisfy the AAA key management requirements specified in 248 [RFC4962]. 250 Compatability: Compatibility and co-existence with compliant 251 ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be 252 provided. The keying hierarchy or protocol extensions MUST NOT 253 preclude the use of CAPWAP or IEEE 802.11r. 255 6. Security Goals 257 The section draws from the guidance provided in [RFC4962] to further 258 define the security goals to be achieved by a complete re- 259 authentication keying solution. 261 6.1. Key Context and Domino Effect 263 Any key MUST have a well-defined scope and MUST be used in a specific 264 context and for the intended use. This specifically means the 265 lifetime and scope of each key MUST be defined clearly so that all 266 entities that are authorized to have access to the key have the same 267 context during the validity period. In a hierarchical key structure, 268 the lifetime of lower level keys MUST NOT exceed the lifetime of 269 higher level keys. This requirement MAY imply that the context and 270 the scope parameters have to be exchanged. Furthermore, the 271 semantics of these parameters MUST be defined to provide proper 272 channel binding specifications. The definition of exact parameter 273 syntax definition is part of the design of the transport protocol 274 used for the parameter exchange and that may be outside scope of this 275 protocol. 277 If a key hierarchy is deployed, compromising lower level keys MUST 278 NOT result in a compromise of higher level keys which they were used 279 to derive the lower level keys. The compromise of keys at each level 280 MUST NOT result in compromise of other keys at the same level. The 281 same principle applies to entities that hold and manage a particular 282 key defined in the key hierarchy. Compromising keys on one 283 authenticator MUST NOT reveal the keys of another authenticator. 284 Note that the compromise of higher-level keys has security 285 implications on lower levels. 287 Guidance on parameters required, caching, storage and deletion 288 procedures to ensure adequate security and authorization provisioning 289 for keying procedures MUST be defined in a solution document. 291 All the keying material MUST be uniquely named so that it can be 292 managed effectively. 294 6.2. Key Freshness 296 As [RFC4962] defines, a fresh key is one that is generated for the 297 intended use. This would mean the key hierarchy MUST provide for 298 creation of multiple cryptographically separate child keys from a 299 root key at higher level. Furthermore, the keying solution needs to 300 provide mechanisms for refreshing each of the keys within the key 301 hierarchy. 303 6.3. Authentication 305 Each party in the handover keying architecture MUST be authenticated 306 to any other party with whom it communicates, and securely provide 307 its identity to any other entity that may require the identity for 308 defining the key scope. The identity provided MUST be meaningful 309 according to the protocol over which the two parties communicate. 311 6.4. Authorization 313 The EAP Key management document [I-D.ietf-eap-keying] discusses 314 several vulnerabilities that are common to handover mechanisms. One 315 important issue arises from the way the authorization decisions might 316 be handled at the AAA server during network access authentication. 317 For example, if AAA proxies are involved, they may also influence in 318 the authorization decision. Furthermore, the reasons for making a 319 particular authorization decision are not communicated to the 320 authenticator. In fact, the authenticator only knows the final 321 authorization result. The proposed solution MUST make efforts to 322 document and mitigate authorization attacks. 324 6.5. Channel Binding 326 Channel Binding procedures are needed to avoid a compromised 327 intermediate authenticator providing unverified and conflicting 328 service information to each of the peer and the EAP server. In the 329 architecture introduced in this document, there are multiple 330 intermediate entities between the peer and the back-end EAP server. 331 Various keys need to be established and scoped between these parties 332 and some of these keys may be parents to other keys. Hence the 333 channel binding for this architecture will need to consider layering 334 intermediate entities at each level to make sure that an entity with 335 higher level of trust can examine the truthfulness of the claims made 336 by intermediate parties. 338 6.6. Transport Aspects 340 Depending on the physical architecture and the functionality of the 341 elements involved, there may be a need for multiple protocols to 342 perform the key transport between entities involved in the handover 343 keying architecture. Thus, a set of requirements for each of these 344 protocols, and the parameters they will carry, MUST be developed. 345 Following the requirement specifications, recommendations will be 346 provided as to whether new protocols or extensions to existing 347 protocols are needed. 349 As mentioned, the use of existing AAA protocols for carrying EAP 350 messages and keying material between the AAA server and AAA clients 351 that have a role within the architecture considered for the keying 352 problem will be carefully examined. Definition of specific 353 parameters, required for keying procedures and to be transferred over 354 any of the links in the architecture, are part of the scope. The 355 relation of the identities used by the transport protocol and the 356 identities used for keying also needs to be explored. 358 7. Use Cases and Related Work 360 In order to further clarify the items listed in scope of the proposed 361 work, this section provides some background on related work and the 362 use cases envisioned for the proposed work. 364 7.1. IEEE 802.11r Applicability 366 One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in 367 the process of specifying a mechanism to avoid the problem of 368 repeated full EAP exchanges in a limited setting, by introducing a 369 two-level key hierarchy. The EAP authenticator is collocated with 370 what is known as an R0 Key Holder (R0-KH), which receives the MSK 371 from the EAP server. A pairwise master key (PMK-R0) is derived from 372 the last 32 octets of the MSK. Subsequently, the R0-KH derives an 373 PMK-R1 to be handed out to the attachment point of the peer. When 374 the peer moves from one R1-KH to another, a new PMK-R1 is generated 375 by the R0-KH and handed out to the new R1-KH. The transport protocol 376 used between the R0-KH and the R1-KH is not specified. 378 In some cases, a mobile may seldom move beyond the domain of the 379 R0-KH and this model works well. A full EAP authentication will 380 generally be repeated when the PMK-R0 expires. However, in general 381 cases mobiles may roam beyond the domain of R0-KHs (or EAP 382 authenticators), and the latency of full EAP authentication remains 383 an issue. 385 Another consideration is that there needs to be a key transfer 386 protocol between the R0-KH and the R1-KH; in other words, there is 387 either a star configuration of security associations between the key 388 holder and a centralized entity that serves as the R0-KH, or if the 389 first authenticator is the default R0-KH, there will be a full-mesh 390 of security associations between all authenticators. This is 391 undesirable. 393 The proposed work on EAP efficient re-authentication protocol aims at 394 addressing re-authentication in a lower layer agnostic manner that 395 also can fill some of the gaps in IEEE 802.11r. 397 7.2. IEEE 802.21 Applicability 399 The IEEE 802.21 working group [IEEE.802-21] is standardizing 400 mechanisms for media-independent handover. More specifically, they 401 are looking at transitions from one link-layer protocol to another, 402 which is currently beyond the scope of the HOKEY charter. 404 The techniques developed within HOKEY could be applicable to IEEE 405 802.21 if the necessary issues with handover between different lower 406 layers can be resolved. In particular, pre-authentication may be 407 more appropriate than re-authentication. 409 7.3. CAPWAP Applicability 411 The IETF CAPWAP WG [RFC3990] is developing a protocol between what is 412 termed an Access Controller (AC) and Wireless Termination Points 413 (WTP). The AC and WTP can be mapped to a WLAN switch and Access 414 Point respectively. The CAPWAP model supports both split and 415 integrated MAC architectures, with the authenticator always being 416 implemented at the AC. 418 The proposed work on EAP efficient re-authentication protocol 419 addresses an inter-authenticator handover problem from an EAP 420 perspective, which applies during handover between ACs. Inter- 421 controller handover is a topic yet to be addressed in great detail 422 and the re-authentication work can potentially address it in an 423 effective manner. 425 7.4. Inter-Technology Handover 427 EAP is used for access authentication by several technologies and is 428 under consideration for use over several other technologies going 429 forward. Given that, it should be feasible to support smoother 430 handover across technologies. That is one of the big advantages of 431 using a common authentication protocol. Authentication procedures 432 typically add substantial handover delays. 434 An EAP peer that has multiple radio technologies (802.11 and GSM, for 435 instance) must perform the full EAP exchange on each interface upon 436 every horizontal or vertical handover. With a method independent EAP 437 efficient re-authentication, it is feasible to support faster 438 handover even in the vertical handover cases, when the peer may be 439 roaming from one technology to another. 441 8. Security Considerations 443 This document details the HOKEY problem statement. Since HOKEY is an 444 authentication protocol, there are a myriad of security-related 445 issues surrounding its development and deployment. 447 In this document, we have detailed a variety of security properties 448 inferred from [RFC4962] to which HOKEY must conform, including the 449 management of key context, scope, freshness, and transport; 450 resistance to attacks based on the domino effect; and authentication 451 and authorization. See section Section 6 for further details. 453 9. IANA Considerations 455 This document does not introduce any new IANA considerations. 457 10. References 459 10.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 465 Levkowetz, "Extensible Authentication Protocol (EAP)", 466 RFC 3748, June 2004. 468 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 469 Authentication Protocol (EAP) Method Requirements for 470 Wireless LANs", RFC 4017, March 2005. 472 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 473 Authorization, and Accounting (AAA) Key Management", 474 BCP 132, RFC 4962, July 2007. 476 10.2. Informative References 478 [I-D.ietf-eap-keying] 479 Aboba, B., "Extensible Authentication Protocol (EAP) Key 480 Management Framework", draft-ietf-eap-keying-18 (work in 481 progress), February 2007. 483 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 484 Provisioning for Wireless Access Points (CAPWAP) Problem 485 Statement", RFC 3990, February 2005. 487 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 488 Protocol Method for 3rd Generation Authentication and Key 489 Agreement (EAP-AKA)", RFC 4187, January 2006. 491 [IEEE.802-11R-D7.0] 492 "Information technology - Telecommunications and 493 information exchange between systems - Local and 494 metropolitan area networks - Specific requirements - Part 495 11: Wireless LAN Medium Access Control (MAC) and Physical 496 Layer (PHY) specifications - Amendment 2: Fast BSS 497 Transition", IEEE Standard 802.11r, June 2007. 499 [IEEE.802-21] 500 "Media Independent Handover Working Group", IEEE Working 501 Group 802.21. 503 Author's Address 505 T. Charles Clancy, Editor 506 DoD Laboratory for Telecommunications Sciences 507 8080 Greenmead Drive 508 College Park, MD 20740 509 USA 511 Email: clancy@LTSnet.net 513 Full Copyright Statement 515 Copyright (C) The IETF Trust (2007). 517 This document is subject to the rights, licenses and restrictions 518 contained in BCP 78, and except as set forth therein, the authors 519 retain all their rights. 521 This document and the information contained herein are provided on an 522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 524 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 525 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 526 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Intellectual Property 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org. 553 Acknowledgment 555 Funding for the RFC Editor function is provided by the IETF 556 Administrative Support Activity (IASA).