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