RFC 5169

Handover Key Management and Re-Authentication Problem Statement

📅 published March 2008, from ietf

RFC 5169: Handover Key Management and Re-Authentication Problem Statement 🦋

  • Stream: Network Working Group
  • Category: Informational
  • Date: March 2008
  • Authors: T. Clancy (LTS), M. Nakhjiri (Motorola), V. Narayanan and L. Dondeti (Qualcomm)
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🫶

Status of This Memo 📜

okay so this memo is here to give info to the Internet community 💖 It is not a standard of any kind. You can share it as much as you want, distribution is totally unlimited ✨

Abstract 🌸

this doc is all about the HOKEY (Handover Keying) re-authentication problem 🧚 The current EAP keying framework wasn't built to handle re-authentication and handovers without running an EAP method all over again, and ngl that causes some seriously painful latency in mobile wireless setups 😭 So this doc breaks down the problem and sets design goals for a generic way to reuse EAP keying material during handover. It's giving problem-solving era 💅

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
4.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  5
5.  Security Goals . . . . . . . . . . . . . . . . . . . . . . . .  6
  5.1.  Key Context and Domino Effect  . . . . . . . . . . . . . .  7
  5.2.  Key Freshness  . . . . . . . . . . . . . . . . . . . . . .  7
  5.3.  Authentication . . . . . . . . . . . . . . . . . . . . . .  8
  5.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
  5.5.  Channel Binding  . . . . . . . . . . . . . . . . . . . . .  8
  5.6.  Transport Aspects  . . . . . . . . . . . . . . . . . . . .  8
6.  Use Cases and Related Work . . . . . . . . . . . . . . . . . .  9
  6.1.  Method-Specific EAP Re-Authentication  . . . . . . . . . .  9
  6.2.  IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10
  6.3.  CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
  10.2. Informative References . . . . . . . . . . . . . . . . . . 12

1. Introduction ✨

okay so EAP (Extensible Authentication Protocol), specified in RFC 3748 [RFC3748], is a generic framework that supports multiple authentication methods 🦋 Its main job is network access control, and it can also export session keys that get derived during the authentication. The EAP keying hierarchy has two keys derived at the top level: the Master Session Key (MSK) and the Extended Master Session Key (EMSK) 🔑

In a lot of common deployments, an EAP peer and an EAP server authenticate each other through a third party called the pass-through authenticator (we'll just call it "authenticator" from here on) 💅 The authenticator handles wrapping EAP packets from a lower-layer network-access technology inside the Authentication, Authorization, and Accounting (AAA) protocol. It doesn't actually take part in the EAP exchange. It's basically a gateway while the EAP method runs 🫶

After a successful authentication, the EAP server sends the MSK to the authenticator. Note that this happens over AAA protocols, not EAP itself 👀 The underlying L2 or L3 protocol then uses the MSK to derive more keys, including the transient session keys (TSKs) used for per-packet encryption and authentication 🔥

Heads up: even though the authenticator is one logical device, there can be several physical devices involved 🧚 For example, the CAPWAP model [RFC3990] splits authenticators into two logical devices: Wireless Termination Points (WTPs) and Access Controllers (ACs). Depending on the configuration, authenticator features can be split up in a bunch of different ways between physical devices. From the EAP perspective, though, there's only one logical authenticator ✨

Wireless handover between access points or base stations is usually a complicated process with several layers of protocol execution going on 😭 Running all of those protocols often causes delays that are unacceptable for real-time apps like voice [MSA03]. One piece of the handover is EAP re-authentication, which can add a lot to the total handover time [MSPCA04]. So in many environments, we can cut the overall handover time by cutting down EAP re-authentication time 💖

Here's the current situation with existing EAP implementations 🍓 When a peer shows up at a new authenticator, it runs an EAP method no matter whether it was authenticated to the network recently and still has unexpired keying material. This usually involves an EAP-Response/Identity message from the peer to the server, then one or more round trips between the EAP server and the peer to do the authentication, and finally an EAP-Success or EAP-Failure message from the EAP server to the peer. At a minimum, the EAP exchange is 1.5 round trips. But because of the way EAP interacts with AAA, and because an EAP identity exchange is usually used, at least 2 round trips are required to the EAP server. The most commonly used EAP methods need even more round trips. For example, EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) needs at least 3 round trips, but typically 4 or more 🌈

People have tried to solve efficient re-authentication in different ways 🤔 But those solutions are either specific to one EAP method or specific to one EAP lower layer. On top of that, they either don't deal with handovers to new authenticators, or they don't follow the AAA keying requirements in [RFC4962].

This document gives a detailed description of the design goals for an efficient EAP-based re-authentication protocol 💜 The scope is specifically re-authentication and handover between authenticators within a single administrative domain. The design goals here might help with inter-technology handover and inter-administrative-domain handover too, but those are outside the scope of this protocol 🙈

2. Terminology 💅

In this document, a few words are used to signal the requirements of the specification. They're often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the qualification that, unless otherwise stated, they apply to the design of the re-authentication protocol, not its implementation or application. Important 🫶

With respect to EAP, this document follows the terminology defined in [RFC3748] and [EAP-KEYING] ✨

3. Problem Statement 🔥

Under the existing model, any re-authentication needs a full EAP exchange with the EAP server that the peer first authenticated to [RFC3748]. That adds handover latency from both network transit time and processing delay 😭 In service provider networks, the home EAP server for a peer could be on the other side of the world, and typical intercontinental latencies across the Internet are 100 to 300 milliseconds per round trip [LGS07]. Yikes 💀

Processing delays average a couple of milliseconds for symmetric-key operations and hundreds of milliseconds for public-key operations 🧚

A full EAP method run can take two or more round trips to finish, which delays re-authentication and handover times. Some methods use keys and state from the initial authentication to finish later authentications in fewer round trips, and without public-key operations (detailed in Section 6.1). Even then, though, multiple round trips to the EAP server are still needed, and that leads to unacceptable handover times 🍓

So to sum up: it's not ideal to run an EAP Identity and a complete EAP method exchange every single time a peer authenticates to a new authenticator, or needs to extend its current authentication with that same authenticator 🙅‍♀️ It's also desirable to have a method-independent, efficient re-authentication protocol. Keying material from the initial authentication can be used to make re-authentication efficient 💖 It's also good to have a local server with low-latency connectivity to the peer that can help with re-authentication 🌸 Last but not least, a re-authentication protocol should be able to handle cases where an EAP server passes authentication information to a remote re-authentication server. That way a peer can re-authenticate locally without having to talk to its home re-authentication server 🦋

These are the main problems to solve. Solving them comes with a few constraints to follow, and those lead to some extra work in the area of EAP keying 👑

4. Design Goals ✨

okay bestie, here's the wishlist for the EAP re-authentication and key management protocol 💅

  • Lower-latency operation: The protocol MUST be responsive to handover and re-authentication latency performance objectives within a mobile access network. A solution that reduces latency compared to a full EAP authentication is the most favorable, because in networks that rely on reactive re-authentication, this directly affects handover times. 🫶
  • EAP lower-layer independence: Any keying hierarchy and protocol defined MUST be lower-layer independent so they can provide capabilities over heterogeneous technologies. The defined protocols MAY require some additional support from the lower layers that use them, but they should not require any particular lower layer. 🌈
  • EAP method independence: Changes to existing EAP methods MUST NOT be required as a result of the re-authentication protocol. There MUST be no requirements imposed on future EAP methods, provided they satisfy [EAP-KEYING] and [RFC4017]. Note that the only EAP methods for which independence is required are those that currently conform to the specifications of [EAP-KEYING] and [RFC4017]. In particular, methods that do not generate the keys required by [EAP-KEYING] need not be supported by the re-authentication protocol. 💖
  • AAA protocol compatibility and keying: Any modifications to EAP and EAP keying MUST be compatible with RADIUS [RADEXT-DESIGN] and Diameter [DIME-APP-DESIGN]. Extensions to both RADIUS and Diameter that support these EAP modifications are acceptable. The designs and protocols must be configurable so they satisfy the AAA key management requirements specified in RFC 4962 [RFC4962]. 🎀
  • Compatibility: Compatibility and coexistence with compliant ([RFC3748] [EAP-KEYING]) EAP deployments MUST be provided. Specifically, the protocol should be designed so that a peer not supporting fast re-reauthentication should still function in a network supporting fast re-authentication, and a peer supporting fast re-authentication should still function in a network not supporting fast re-authentication. 🦋
  • Cryptographic Agility: Any re-authentication protocol MUST support cryptographic algorithm agility, to avoid hard-coded primitives whose security may eventually prove to be compromised. The protocol MAY support cryptographic algorithm negotiation, provided it does not adversely affect overall performance (i.e., by requiring additional round trips). 🔥
  • Impact to Existing Deployments: Any re-authentication protocol MAY make changes to the peer, authenticator, and EAP server, as necessary to meet the aforementioned design goals. To facilitate protocol deployment, protocols should seek to minimize the necessary changes, without sacrificing performance. 🧚

5. Security Goals 🔐

this section takes the guidance from [RFC4962] and goes deeper on the security goals a complete re-authentication keying solution has to hit. it's giving serious security energy, no cap 👑

5.1. Key Context and Domino Effect

okay so every key needs a well-defined scope, and it has to be used in a specific context and for its intended use. basically, the lifetime and scope of each key must be defined clearly so that every entity allowed to have the key shares the same context during the validity period. in a hierarchical key structure, the lifetime of lower-level keys must not exceed the lifetime of higher-level keys. this might mean the context and scope parameters have to be exchanged. the semantics of those parameters also need to be defined so channel binding can be specified properly. the exact syntax of the parameters is part of the design of the transport protocol used to exchange them, and that may be outside the scope of this protocol. 🌸

if a key hierarchy is deployed, compromising lower-level keys must not result in compromising the higher-level keys that were used to derive them. compromising the keys at each level must not result in compromising other keys at the same level. the same principle applies to entities that hold and manage a particular key in the key hierarchy. compromising keys on one authenticator must not reveal the keys of another authenticator. and note that compromising higher-level keys has security implications for the lower levels. 😭

guidance on the parameters required, plus caching, storage, and deletion procedures for keying, needs to be defined in a solution document. that's how you make sure provisioning for security and authorization is actually adequate. ✨

all the keying material must be uniquely named so it can be managed effectively. 🍓

5.2. Key Freshness

as [RFC4962] defines it, a fresh key is one that is generated for its intended use. so the key hierarchy must provide for creating multiple cryptographically separate child keys from a root key at a higher level. the keying solution also needs mechanisms for refreshing each of the keys in the hierarchy. the freshness era is real 🌈

5.3. Authentication

each handover keying participant must be authenticated to any other party it communicates with, to the extent necessary to ensure proper key scoping. it also has to securely provide its identity to any other entity that may need that identity to define the key scope. identity check, bestie 🫶

5.4. Authorization

[EAP-KEYING] discusses several vulnerabilities that are common to handover mechanisms. one important issue comes from how authorization decisions might be handled at the AAA server during network access authentication. on top of that, the reasons for a particular authorization decision are not communicated to the authenticator. in fact, the authenticator only knows the final authorization result. the proposed solution must make efforts to document and mitigate authorization attacks. this is a whole vibe check 💀

5.5. Channel Binding

channel binding procedures are needed to stop a compromised intermediate authenticator from giving unverified and conflicting service information to each of the peer and the EAP server. 🙈 to support fast re-authentication, there will be intermediate entities between the peer and the back-end EAP server. various keys need to be established and scoped between these parties, and some of these keys may be parents to other keys. so the channel binding for this architecture will need to consider layering intermediate entities at each level. that way, an entity with a higher level of trust can check the truthfulness of the claims made by intermediate parties. main character energy for trust levels 👑

5.6. Transport Aspects

depending on the physical architecture and the functionality of the elements involved, there may be a need for multiple protocols to do the key transport between the entities in the handover keying architecture. so a set of requirements for each of these protocols, and for the parameters they will carry, must be developed. 🧚

the use of existing AAA protocols to carry EAP messages and keying material between the AAA server and the AAA clients that have a role in the architecture will be carefully examined. defining the specific parameters needed for keying procedures, and that get transferred over any of the links in the architecture, is part of the scope. the relation between the identities used by the transport protocol and the identities used for keying also needs to be explored. 💅

to make the items in the scope of the proposed work clearer, this section gives some background on related work and the use cases envisioned for it. let's get into it 🌈

6.1. Method-Specific EAP Re-Authentication

a number of EAP methods support fast re-authentication, so let's look at their properties in more detail. 🔍

EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re-authentication, bootstrapped by the keys generated during an initial full authentication. in response to the typical EAP-Request/Identity, the peer sends a specially formatted identity that signals it wants a fast re-authentication. a single round trip verifies knowledge of the existing keys and provides fresh nonces for generating new keys. this is followed by an EAP success. in total, it requires a single local round trip between the peer and the authenticator, followed by another round trip between the peer and the EAP server. AKA is based on symmetric-key cryptography, so processing latency is minimal. ⚡

EAP-TTLS [EAP-TTLS] and PEAP (Protected EAP Protocol) [JOSEFSSON-PPPEXT] support using TLS session resumption for fast re-authentication. during the TLS handshake, the client includes the message ID of the previous session he wishes to resume, and the server can echo that ID back if it agrees to resume the session. EAP-FAST [RFC4851] also supports TLS session resumption, but additionally allows stateless session resumption as defined in [RFC5077]. overall, all three protocols still need two round trips between the peer and the EAP server, on top of the local round trip for the Identity request and response. 🍓

to improve performance, fast re-authentication needs to reduce the total number of round trips. optimal performance could come from eliminating the EAP-Request/Identity and EAP-Response/Identity messages seen in typical EAP method execution, and allowing a single round trip between the peer and a local re-authentication server. 🫶

6.2. IEEE 802.11r Applicability

one of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in the process of specifying a fast handover mechanism. access points (APs) get grouped into mobility domains. initial authentication to any AP in a mobility domain requires running EAP, but handover between APs within the mobility domain does not need EAP. 📡

inside the mobility domain there are sets of security associations that support key transfers between APs. in one model, relatively few devices, called R0-KHs, act as authenticators. all EAP traffic traverses an R0-KH, and it derives the initial IEEE 802.11 keys. it then distributes cryptographically separate keys to APs in the mobility domain as necessary to support client mobility. for a deployment with M designated R0-KHs and N APs, this requires M*N security associations. for small M, this approach scales reasonably. another approach lets any AP act as an R0-KH, which needs a full mesh of N2 security associations, and that scales poorly. 📉

the model that uses designated R0-KHs is architecturally similar to the fast re-authentication model proposed by HOKEY. HOKEY, however, allows handover between authenticators. this would let an IEEE 802.11r-enabled peer move from one mobility domain to another without performing an EAP authentication. 🌸

6.3. CAPWAP Applicability ✨

okay so CAPWAP (Control and Provisioning of Wireless Access Points) [CAPWAP-PROTOCOL-SPEC] lets the functionality of an IEEE 802.11 access point get split across two physical devices in enterprise deployments 🏢. The Wireless Termination Points (WTPs) handle the physical and low-level Media Access Control (MAC) layers, while a centralized Access Controller (AC) does the higher-level management and protocol execution. Client authentication is handled by the AC, which acts as the AAA authenticator 🔐.

One of the many features CAPWAP gives you is roaming between WTPs without running an EAP authentication 🦋. The way it works is that the AC caches the MSK from an initial EAP authentication, then uses it to run a separate four-way handshake with the station as it moves between WTPs 🚶‍♀️. The keys from that four-way handshake get distributed to whichever WTP the station is associated with. And the best part? CAPWAP is transparent to the station 🫶.

CAPWAP currently has no way to support roaming between ACs in an enterprise network 😭. The proposed work on EAP efficient re-authentication addresses is an inter-authenticator handover problem from an EAP perspective, and it applies during handover between ACs. Inter-AC handover is still a topic that hasn't been dug into in great detail yet, but the re-authentication work could potentially handle it in an effective way 🌈.

7. Security Considerations 💀

okay this part is serious, bestie 🫣. This document details the HOKEY problem statement. Since HOKEY is an authentication protocol, there is a whole myriad of security-related issues surrounding its development and deployment 🚨.

In this document, we detailed a bunch of security properties inferred from [RFC4962] that HOKEY must conform to. These include the management of key context, scope, freshness, and transport; resistance to attacks based on the domino effect; and authentication and authorization 🛡️. See Section 5 for the full details, and please go read them, they're iconic 👑.

8. Contributors 🎀

This document is the synthesis of two problem statement documents. In this section we acknowledge their contributions and their involvement in the early documents 🌸.

   Mohan Parthasarathy
   Nokia
   EMail: mohan.parthasarathy@nokia.com

   Julien Bournelle
   France Telecom R&D
   EMail: julien.bournelle@orange-ftgroup.com

   Hannes Tschofenig
   Siemens
   EMail: Hannes.Tschofenig@siemens.com

   Rafael Marin Lopez
   Universidad de Murcia
   EMail: rafa@dif.um.es

9. Acknowledgements 🫶

The authors would like to thank the participants of the HOKEY working group for their review and comments, including Glen Zorn, Dan Harkins, Joe Salowey, and Yoshi Ohba 💖. The authors would also like to thank those who provided last-call reviews, including Bernard Aboba, Alan DeKok, Jari Arkko, and Hannes Tschofenig 🙌.

10. References 📚

10.1. Normative References

[RFC2119]               Bradner, S., "Key words for use in RFCs to
                        Indicate Requirement Levels", BCP 14,
                        RFC 2119, March 1997.

[RFC3748]               Aboba, B., Blunk, L., Vollbrecht, J.,
                        Carlson, J., and H. Levkowetz, "Extensible
                        Authentication Protocol (EAP)", RFC 3748,
                        June 2004.

[RFC4017]               Stanley, D., Walker, J., and B. Aboba,
                        "Extensible Authentication Protocol (EAP)
                        Method Requirements for Wireless LANs",
                        RFC 4017, March 2005.

[RFC4962]               Housley, R. and B. Aboba, "Guidance for
                        Authentication, Authorization, and Accounting
                        (AAA) Key Management", BCP 132, RFC 4962,
                        July 2007.

10.2. Informative References

[CAPWAP-PROTOCOL-SPEC]  Calhoun, P., Montemurro, M., and D. Stanely,
                        "CAPWAP Protocol Specification", Work
                        in Progress, March 2008.

[DIME-APP-DESIGN]       Fajardo, V., Asveren, T., Tschofenig, H.,
                        McGregor, G., and J. Loughney, "Diameter
                        Applications Design Guidelines", Work
                        in Progress, January 2008.

[EAP-KEYING]            Aboba, B., Simon, D., and P. Eronen,
                        "Extensible Authentication Protocol (EAP) Key
                        Management Framework", Work in Progress,
                        November 2007.

[EAP-TTLS]              Funk, P. and S. Blake-Wilson, "EAP Tunneled
                        TLS Authentication Protocol Version 0 (EAP-
                        TTLSv0)", Work in Progress, March 2008.

[IEEE.802-11R-D9.0]     "Information technology - Telecommunications
                        and information exchange between systems -
                        Local and metropolitan area networks -
                        Specific requirements - Part 11: Wireless LAN
                        Medium Access Control (MAC) and Physical
                        Layer (PHY) specifications - Amendment 2:
                        Fast BSS Transition", IEEE Standard 802.11r,
                        January 2008.

[JOSEFSSON-PPPEXT]      Josefsson, S., Palekar, A., Simon, D., and G.
                        Zorn, "Protected EAP Protocol (PEAP) Version
                        2", Work in Progress, October 2004.

[LGS07]                 Ledlie, J., Gardner, P., and M. Selter,
                        "Network Coordinates in the Wild",
                        USENIX Symposium on Networked System Design
                        and Implementation, April 2007.

[MSA03]                 Mishra, A., Shin, M., and W. Arbaugh, "An
                        Empirical Analysis of the IEEE 802.11 MAC-
                        Layer Handoff Process", ACM SIGCOMM Computer
                        and Communications Review, April 2003.

[MSPCA04]               Mishra, A., Shin, M., Petroni, N., Clancy,
                        T., and W. Arbaugh, "Proactive Key
                        Distribution using Neighbor Graphs",
                        IEEE Wireless Communications, February 2004.

[RADEXT-DESIGN]         Weber, G. and A. DeKok, "RADIUS Design
                        Guidelines", Work in Progress, December 2007.

[RFC3990]               O'Hara, B., Calhoun, P., and J. Kempf,
                        "Configuration and Provisioning for Wireless
                        Access Points (CAPWAP) Problem Statement",
                        RFC 3990, February 2005.

[RFC4186]               Haverinen, H. and J. Salowey, "Extensible
                        Authentication Protocol Method for Global
                        System for Mobile Communications (GSM)
                        Subscriber Identity Modules (EAP-SIM)",
                        RFC 4186, January 2006.

[RFC4187]               Arkko, J. and H. Haverinen, "Extensible
                        Authentication Protocol Method for 3rd
                        Generation Authentication and Key Agreement
                        (EAP-AKA)", RFC 4187, January 2006.

[RFC4851]               Cam-Winget, N., McGrew, D., Salowey, J., and
                        H. Zhou, "The Flexible Authentication via
                        Secure Tunneling Extensible Authentication
                        Protocol Method (EAP-FAST)", RFC 4851,
                        May 2007.

[RFC5077]               Salowey, J., Zhou, H., Eronen, P., and H.
                        Tschofenig, "Transport Layer Security (TLS)
                        Session Resumption without Server-Side
                        State", RFC 5077, January 2008.

Authors' Addresses 🎀

T. Charles Clancy, Editor
Laboratory for Telecommunications Sciences
US Department of Defense
College Park, MD
USA

EMail: clancy@LTSnet.net


Madjid Nakhjiri
Motorola

EMail: madjid.nakhjiri@motorola.com


Vidya Narayanan
Qualcomm, Inc.
San Diego, CA
USA

EMail: vidyan@qualcomm.com


Lakshminath Dondeti
Qualcomm, Inc.
San Diego, CA
USA

EMail: ldondeti@qualcomm.com

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔍

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💖

📦 where this page comes from