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