RFC 6697
Handover Keying (HOKEY) Architecture Design
Handover Keying (HOKEY) Architecture Design 🦋
Okay bestie, this is RFC 6697 📜 and it's an Informational doc, so it's published for information and isn't a Standards Track spec. It came out in July 2012 and has ISSN 2070-1721. The main author is G. Zorn, Ed. from Network Zen 💖. Q. Wu and T. Taylor are both from Huawei, Y. Nir is from Check Point, K. Hoeper is from Motorola Solutions, Inc., and S. Decugis is from INSIDE Secure 🫶. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 💅.
Abstract 🌸
Okay so the Handover Keying (HOKEY) Working Group wants to cut down the handover delay caused by authentication when a peer moves from one point of attachment to another 🦋. Two approaches are in the works. The first is early authentication, so authentication doesn't have to happen during the handover itself ✨. The second is reusing the cryptographic material made during an initial authentication to save time on re-authentication 🔥. The basic assumption is that the mobile host (aka the "peer") gets initially authenticated with the Extensible Authentication Protocol (EAP), running between the peer and an EAP server, as defined in RFC 3748 💜.
This document defines the HOKEY architecture 🧚. It covers the design objectives, the functional environment that handover keying works in, the functions the HOKEY architecture itself has to perform, and how those functions get assigned to architectural components 👑. It also shows how the architecture works in different deployment scenarios, which are explained in more detail in other documents from the HOKEY Working Group 🌈.
Status of This Memo 📝
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF) 💅. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🙈.
For the current status of this document, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6697 🎀.
Copyright Notice 💜
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date this document was published 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🫶. Code Components pulled out of this document have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥.
Table of Contents 📚
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Design Goals ....................................................6
3.1. Reducing Signaling Overhead ................................7
3.1.1. Minimized Communications with Home Servers ..........7
3.1.2. Minimized User Interaction for Authentication .......7
3.2. Integrated Local Domain Name (LDN) Discovery ...............7
3.3. Fault-Tolerant Re-Authentication ...........................8
3.4. Improved Deployment Scalability ............................8
4. Required Functionality ..........................................8
4.1. Authentication Subsystem Functional Overview ...............8
4.2. Pre-Authentication Function (Direct or Indirect) ...........9
4.3. EAP Re-Authentication Function .............................9
4.4. EAP Authentication Function ...............................10
4.5. Authenticated Anticipatory Keying (AAK) Function ..........10
4.6. Management of EAP-Based Handover Keys .....................10
5. Components of the HOKEY Architecture ...........................11
5.1. Functions of the Peer .....................................12
5.2. Functions of the Serving Authenticator ....................13
5.3. Functions of the Candidate Authenticator ..................14
5.4. Functions of the EAP Server ...............................15
5.5. Functions of the ER Server ................................16
6. Usage Scenarios ................................................16
6.1. Simple Re-Authentication ..................................16
6.2. Intra-Domain Handover .....................................17
6.3. Inter-Domain Handover .....................................17
6.4. Inter-Technology Handover .................................17
7. AAA Considerations .............................................17
7.1. Authorization .............................................17
7.2. Transport Aspect ..........................................18
8. Security Considerations ........................................18
9. Acknowledgments ................................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................191. Introduction ✨
Okay so the Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework that supports lots of different kinds of authentication methods 🧚. It was originally built for dial-up connections, but now it's everywhere for authentication across all kinds of access networks 🌐.
When a host (or "peer", which is the term we'll use from here on) changes its point of attachment to the network, it must be re-authenticated 💔. If a full EAP authentication has to be repeated, several message round trips between the peer and the home EAP server might be involved 😭. That delay can cause degradation, or in the worst case, the loss of any service session in progress, if communication gets suspended while re-authentication is happening 💀. It's even worse if the new point of attachment is in a visited network instead of the peer's home network, because there are extra procedural steps and the round-trip time will probably go up too 🙈.
Clancy, et al. [RFC5169] describe this problem in more detail and set design goals for solutions that reduce re-authentication delay for transfers within a single administrative domain 🦋. They also suggest a few ways to get there:
- specification of a method-independent, efficient re-authentication protocol based upon EAP;
- reuse of keying material from the initial EAP authentication;
- deployment of re-authentication servers local to the peer to reduce round-trip delay; and
- specification of the additional protocol needed to allow the EAP server to pass authentication information to the local re-authentication servers.
Salowey, et al. [RFC5295] tackle the reuse of keying material by specifying how to derive a hierarchy of cryptographically independent, purpose-specific keys from the results of the original EAP authentication 🔑. Cao, et al. [RFC6696] specify a method-independent re-authentication protocol called the EAP Re-authentication Protocol (ERP) 💅. ERP works for two specific deployment scenarios:
- where the peer's home EAP server also performs re-authentication; and
- where a local re-authentication server exists but is co-located with an Authentication, Authorization, and Accounting (AAA) proxy within the domain.
Other work adds more pieces to the puzzle or gives more insight into the problem 🧩. For the purposes of this memo, Hoeper, et al. [RFC5749] provide an abstract mechanism for distributing keying material from the EAP server to re-authentication servers 👑. Ohba, et al. [RFC5836] compare the EAP Re-authentication (ER) strategy that ERP provides with an alternative strategy called "early authentication" ⚖️. RFC 5836 defines EAP early authentication as the use of EAP by a mobile peer to establish authenticated keying material on a target attachment point before the peer arrives there 🦋. So the goal of EAP early authentication is to finish all the EAP-related communications, including AAA signaling, in preparation for the handover, before the mobile device actually moves 🏃♀️💨. Early authentication includes direct and indirect pre-authentication, plus Authenticated Anticipatory Keying (AAK) 🌸.
All three early authentication mechanisms give you a way to securely establish authenticated keying material on a Candidate Attachment Point (CAP) while the peer is still connected to the Serving Attachment Point (SAP) 🔐. But they each have different system assumptions and communication paths 🛤️. Direct pre-authentication assumes clients can discover CAPs and that all communications are routed through the SAP 🧭. Indirect pre-authentication assumes there's an existing relationship between the SAP and the CAP, and the discovery and selection of CAPs is outside the scope of AAK 🙃. Both direct and indirect pre-authentication require a full EAP execution to happen before the peer hands over ✨. AAK techniques (like ERP [RFC6696]), on the other hand, use keys derived from the initial EAP authentication 🔑.
Both EAP re-authentication and early authentication make inter-authenticator handovers faster 🚀. But it's still unclear how the necessary handover infrastructure can be deployed and integrated into existing EAP infrastructures 🤔. Previous work hasn't described how ER servers that act as endpoints in the re-authentication process should get integrated into local and home domain networks 🏠. And how EAP infrastructure can support the timely triggering of early authentications and help select CAPs is still unspecified 🫠.
This document proposes a general HOKEY architecture and shows how it can be adapted to different deployment scenarios 🎀. To start, Section 3 recalls the design objectives for the HOKEY architecture 🎯. Section 4 reviews the functions that must be supported within the architecture 💪. Section 5 describes the components of the HOKEY architecture 🧩. Section 6 describes the different deployment scenarios the HOKEY Working Group has addressed, along with the information flows that must occur within those scenarios, referencing the documents summarized above where possible and otherwise covering them within this document itself 📚. Finally, Section 7 analyzes how AAA protocols can be applied in the HOKEY architecture 🦋.
⏭️ Part 1 of 4 is done, bestie! Up next is Section 2, Terminology 💜🌈
2. Terminology 💅
okay so this section is basically the glossary bestie 🧚 it reuses terms from Section 2 of Ohba, et al. [RFC5836] and Section 2 of Cao, et al. [RFC6696], and then it adds its own fresh ones ✨
DS-rRK 🔑 Domain-Specific re-authentication Root Key.
pMSK 🌸 pre-established Master Session Key.
EAP Early Authentication 🦋 The use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival; see Ohba, et al. [RFC5836].
ER Key Management 👑 An instantiation of the mechanism described in Hoeper, et al. [RFC5749] for creating and delivering root keys from an EAP server to an ER server.
EAP Re-authentication (ER) 💜 The use of keying material derived from an initial EAP authentication to enable single-round-trip re-authentication of a mobile peer. For a detailed description of the keying material, see Section 4 of Cao, et al. [RFC6696].
ER Server 🎀 A component of the HOKEY architecture that terminates the EAP re-authentication exchange with the peer.
3. Design Goals ✨
okay this section is where the HOKEY architecture gets its vision board 🫶 it digs into the design goals, which are reducing signaling overhead for re-authentication and early authentication, integrating local domain name discovery, enabling fault-tolerant re-authentication, and improving deployment scalability. these goals are extra to the ones in Section 4 of RFC 5169. also, identifying and selecting CAPs is not a goal here, since that stuff is usually specific to whatever lower layer you're using 🙈
3.1. Reducing Signaling Overhead 🍓
3.1.1. Minimized Communications with Home Servers
ERP [RFC6696] needs only one round trip 🏃♀️ but that round trip might involve talking to the peer's home ER and/or home AAA server during explicit bootstrapping, and local servers talking to the home server during implicit bootstrapping, even when the peer is sitting on a visited (local) network. so even that one round trip can take forever, because the home ER and home AAA servers might be far away from both the peer and the network it's attached to 😭 to keep signaling overhead low, communication with the home ER server and home AAA server should be minimized. ideally, a peer only needs to talk to local servers and other local entities 💖
3.1.2. Minimized User Interaction for Authentication
when the peer first attaches to the network or moves between heterogeneous networks, full EAP authentication happens between the peer and the EAP server, and user interaction may be needed, like a dialog asking for credentials 🥺 to cut down on latency, user interaction for authentication at each handover should be minimized. ideally, the user only gets involved during initial authentication, and later re-authentication just happens transparently 🧚
3.2. Integrated Local Domain Name (LDN) Discovery 🗺️
ERP bootstrapping has to happen before (implicit) or during (explicit) a handover so the necessary keys get to the local ER server involved 🔐 implicit bootstrapping is the preferable option, because it doesn't need to talk to the home ER server during handover. the catch is that the peer has to know the domain name of the ER server before the local ERP exchange happens, so it can derive the re-authentication keying material it needs 🫠 ERP [RFC6696] doesn't specify a domain name discovery mechanism. it just suggests the peer might learn the domain name through the EAP-Initiate/Re-auth-Start message or via lower-layer announcements. but domain name discovery happens after implicit bootstrapping finishes, which can add extra latency 😤 so for more efficient handovers, a HOKEY architecture should support an efficient domain name discovery mechanism (for example, see Zorn, Wu & Wang [RFC6440]) and allow it to integrate with ERP implicit bootstrapping. even with explicit bootstrapping, LDN discovery should be optimized so it doesn't require contacting the home AAA server, which is how it currently works 💅
3.3. Fault-Tolerant Re-Authentication 🛡️
if every authentication service depends on a remote server, a network partition can cause a denial of service for valid users, and that's giving chaos 💀 but if, say, an ER server lives in the local network, previously authenticated users can still re-authenticate even when there's no link to the home or main authentication server 🙌
3.4. Improved Deployment Scalability 🌈
for better deployment scalability, there should be no requirement for entities providing handover keying services (like ER servers) to be co-located with AAA servers or proxies. separating these entities might cause routing problems, but it gives way more flexibility in deployment and implementation 🦋
4. Required Functionality 🧩
4.1. Authentication Subsystem Functional Overview 🌟
okay so the authentication subsystem HOKEY provides also relies on a bunch of discovery functions 👀
- discovery of CAPs by the peer, by the SAP, or by some other entity;
- discovery of the authentication services supported at a given CAP;
- discovery of the required server in the home domain when a CAP is not in the same domain as the SAP, or no local server is available;
- peer discovery of the LDN when EAP re-authentication is used with a local server.
these functions are assumed to be provided by the environment the authentication subsystem runs in, so they're outside the scope of the subsystem itself. LDN discovery is a possible exception 🤷♀️
here's how the major functions fit together and depend on each other 🧠
- when AAA is invoked to authorize network access, it uses one of two services the authentication subsystem offers: full EAP authentication or EAP re-authentication. although AAA may do authentication directly in some cases, when EAP is used, AAA only acts as a transport for EAP messages and for the encryption keys (if any) that come out of a successful EAP authentication 📦
- pre-authentication triggers AAA network access authorization at each CAP, which in turn causes full EAP authentication to be invoked 🔁
- EAP re-authentication invokes ER key management at the time of authentication, to create and distribute keying material to ER servers 🗝️
- AAK relies on ER key management to establish keying material on ER/AAK servers, but it uses an extension to ER key management to derive and establish keying material on candidate authenticators. AAK also uses an extension to EAP re-authentication to communicate with ER/AAK servers 💫
EAP authentication, EAP re-authentication, and handover key distribution all depend on the routing and secure transport service AAA provides 🚚 discovery functions and the function of authenticating and authorizing network entities (access points, ER servers) aren't shown. like we said above, those are external to the authentication subsystem 💅
4.2. Pre-Authentication Function (Direct or Indirect) 🚪
the pre-authentication function is responsible for discovering CAPs and completing network access authentication and authorization at each CAP in advance of a handover ⏩ Ohba, et al. [RFC5836] describes how this works in general terms. there's no document yet that describes how to implement pre-authentication with specific protocols, though pre-authentication support for the Protocol for Carrying Authentication for Network Access (PANA) [RFC5873] could be part of the solution 🌸
4.3. EAP Re-Authentication Function 🔄
the EAP re-authentication function is responsible for authenticating the peer at a specific access point using keying material derived from a prior full EAP authentication 🫶 RFC 5169 [RFC5169] provides the design objectives for implementing this function, and ERP [RFC6696] describes a protocol to implement EAP re-authentication 🧚
4.4. EAP Authentication Function 🪪
the EAP authentication function is responsible for authenticating the peer at a specific access point using a full EAP exchange. Aboba, et al. [RFC3748] defines the associated protocol, while Ohba, et al. [RFC5836] describes using EAP as part of pre-authentication. heads up: the HOKEY Working Group has not specified the non-AAA protocol needed to carry EAP frames over IP that is shown in Figures 3 and 5 of Ohba, et al. [RFC5836], although PANA [RFC5873] is a candidate 👀
4.5. Authenticated Anticipatory Keying (AAK) Function 🔮
the AAK function is responsible for pre-placing keying material, derived from an initial full EAP authentication, on CAPs. it happens in two steps. first, ER key management (with a trigger that isn't currently specified) places root keys derived from initial EAP authentication onto an ER/AAK server associated with the peer. then, when the peer asks for it, the ER/AAK server derives and pushes predefined master session keys to one or more CAPs 💖 Ohba, et al. [RFC5836] describes the operation of the AAK function in very general terms, and a protocol specification exists (see Cao, et al. [RFC6630]) 🙌
4.6. Management of EAP-Based Handover Keys 🗝️
handover key management is EAP method-independent key derivation and distribution, and it includes these specific functions 🧩
- handover key derivation
- handover key distribution
the derivation of handover keys is specified in Salowey, et al. [RFC5295], and AAA-based key distribution is specified in Hoeper, Nakhjiri & Ohba [RFC5749] 🍓
5. Components of the HOKEY Architecture 🏗️
this section breaks down the HOKEY architecture components by the functions they perform 🧠 the components work together the way this section describes, to carry out the functions from the previous section. Section 6 covers the different deployment scenarios you can get with these functions 🌈
the components of the HOKEY architecture are:
- the peer;
- the authenticator, which is a part of the SAP and CAPs;
- the EAP server;
- the ER server; and
- the ER/AAK server [RFC6630], either in the home domain or local to the authenticator.
5.1. Functions of the Peer 💖
Okay bestie, the peer is the one doing the main work here 💅 It takes part in the functions from Section 4, and Table 1 is your cheat sheet 🎀
+--------------------+----------------------------------------------+
| Function | Peer Role |
+--------------------+----------------------------------------------+
| EAP authentication | Determines that full EAP authentication is |
| | needed based on context (e.g., initial |
| | authentication), prompting from the |
| | authenticator, or discovery that only EAP |
| | authentication is supported. Participates |
| | in the EAP exchange with the EAP server. |
| - | - |
| Direct | Discovers CAPs. Initiates |
| pre-authentication | pre-authentication with each, followed by |
| | EAP authentication as above, but using IP |
| | rather than L2 transport for the EAP frames. |
| - | - |
| Indirect | Enters into a full EAP exchange when |
| pre-authentication | triggered, using either L2 or L3 transport |
| | for the frames. |
| - | - |
| EAP | Determines that EAP re-authentication is |
| re-authentication | possible based on discovery or authenticator |
| | prompting. Participates in ERP exchange |
| | with the ER server. |
| - | - |
| AAK | Determines that AAK is possible based on |
| | discovery or serving authenticator |
| | prompting. Discovers CAPs. Participates in |
| | ERP/AAK exchange, requesting distribution of |
| | keying material to the CAPs. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 1: Functions of the Peer5.2. Functions of the Serving Authenticator 🦋
The serving authenticator is also part of the Section 4 functions, and Table 2 spells out exactly what it does for each one ✨
+--------------------+----------------------------------------------+
| Function | Serving Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | Discovers CAPs. Initiates an EAP exchange |
| pre-authentication | between the peer and the EAP server through |
| | each candidate authenticator. Mediates |
| | between L2 transport of EAP frames on the |
| | peer side and a non-AAA protocol over IP |
| | toward the CAP. |
| - | - |
| EAP | No role. |
| re-authentication | |
| - | - |
| AAK | Mediates between L2 transport of AAK frames |
| | on the peer side and AAA transport toward |
| | the ER/AAK server. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 2: Functions of the Serving Authenticator5.3. Functions of the Candidate Authenticator 🌸
The candidate authenticator also shows up for the Section 4 functions, and Table 3 is where you'll find its role for each one 🧚
+--------------------+----------------------------------------------+
| Function | Candidate Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | Invokes AAA network access authentication |
| | and authorization upon handover/initial |
| | attachment. Mediates between L2 transport |
| | of EAP frames on the peer link and AAA |
| | transport toward the EAP server. |
| - | - |
| Direct | Invokes AAA network access authentication |
| pre-authentication | and authorization when the peer initiates |
| | authentication. Mediates between non-AAA L3 |
| | transport of EAP frames on the peer side and |
| | AAA transport toward the EAP server. |
| - | - |
| Indirect | Same as direct pre-authentication, except |
| pre-authentication | that it communicates with the serving |
| | authenticator rather than the peer. |
| - | - |
| EAP | Invokes AAA network access authentication |
| re-authentication | and authorization upon handover. Discovers |
| | or is configured with the address of the ER |
| | server. Mediates between L2 transport of |
| | ERP frames on the peer side and AAA |
| | transport toward the ER server. |
| - | - |
| AAK | Receives and saves the pMSK. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 3: Functions of the Candidate Authenticator5.4. Functions of the EAP Server 👑
The EAP server joins in on the Section 4 functions too, and Table 4 lays out its part ✨
+--------------------+----------------------------------------------+
| Function | EAP Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | Terminates EAP signaling between it and the |
| | peer via the candidate authenticator. |
| | Determines whether network access |
| | authentication succeeds or fails. Provides |
| | the MSK to the authenticator (via AAA). |
| - | - |
| Direct | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| Indirect | Same as for EAP authentication. |
| pre-authentication | |
| - | - |
| EAP | Provides an rRK or DS-rRK to the ER server |
| re-authentication | (via AAA). |
| - | - |
| AAK | Same as for EAP re-authentication. |
| - | - |
| ER key management | Creates an rRK or DS-rRK and distributes it |
| | to the ER server requesting the information. |
+--------------------+----------------------------------------------+
Table 4: Functions of the EAP Server5.5. Functions of the ER Server 💜
The ER server takes part in the Section 4 functions as well, and Table 5 shows its roles 🦋
+--------------------+----------------------------------------------+
| Function | ER Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | No role. |
| pre-authentication | |
| - | - |
| EAP | Acquires an rRK or DS-rRK as applicable when |
| re-authentication | necessary. Terminates ERP signaling between |
| | it and the peer via the candidate |
| | authenticator. Determines whether network |
| | access authentication succeeds or fails. |
| | Provides an MSK to the authenticator. |
| - | - |
| AAK | Acquires an rRK or DS-rRK as applicable when |
| | necessary. Derives pMSKs and passes them to |
| | the CAPs. |
| - | - |
| ER key management | Receives and saves an rRK or DS-rRK as |
| | applicable. |
+--------------------+----------------------------------------------+
Table 5: Functions of the ER Server6. Usage Scenarios 🌈
Depending on whether a domain change or an access technology change is involved, there are a few usage scenarios to look at 🍓
6.1. Simple Re-Authentication 🎀
Here the peer stays put and re-authenticates to the original access point 🙈 Quick note: in this case, the SAP plays the role of the CAP from the discussion above ✨
6.2. Intra-Domain Handover 🦋
The peer moves between two authenticators in the same domain 🚶♀️ In this one, the peer talks to the ER server through the ER authenticator inside that same network 💖
6.3. Inter-Domain Handover 🌍
The peer moves between two different domains, and this is where things get busy 😭 It communicates with more than one ER server through one or two different ER authenticators. One ER server is in the network the peer is currently in, and another is in the network the peer just left. The last ER server sits in the home network the peer belongs to 🏠
6.4. Inter-Technology Handover ✈️
Okay, so the peer is moving between two different kinds of networks 🫠. For this to work, the peer needs to support at least two access technologies. The coverage of those two technologies usually overlaps during handover, and that's the key part 🔑. In this case, only the authentication from intra-domain handover is required. The peer can talk to the same local ER server to finish authentication and get the keying material that belongs to the peer ✨. Iykyk, it's giving "why make it harder than it needs to be" 💅
7. AAA Considerations 💜
This section analyzes how the AAA protocol can be applied in the HOKEY architecture, following Section 4.1 ("Authentication Subsystem Functional Overview") 🧠.
7.1. Authorization 👑
Authorization is a big deal in real deployments 😭. Wherever the peer roams, the home AAA server handles authorization for the peer during its handover. But here's the tea: it's not necessary to couple authorization with authentication at every single handover 🙅♀️. Authorization is only needed when the peer first attaches to the network or moves between two different AAA domains.
The EAP key management document [RFC5247] talks about several vulnerabilities that are common to handover mechanisms 🚨. One important issue comes from how authorization decisions might get handled at the AAA server during network access authentication. If AAA proxies are involved, they may also influence those decisions 👀. Also, the reasons for a particular decision aren't communicated to the AAA clients. The AAA client only knows the final authorization result, and that is lowkey so sus 💀.
Another issue is session management 🎀. Sometimes, when the peer moves from one authenticator to another, the peer may get authenticated by the different authenticator for a period of time. The authenticator the peer is currently attached to needs to create a new AAA user session. However, the AAA server should not view these handoffs as different sessions. If it does, it can mess up user experience and cause accounting or logging issues 😩.
For example, session ID creation is, in most cases, done by each authenticator the peer attaches to 🦋. So the new authenticator, acting as AAA client, needs to create a new AAA user session from scratch. That forces its AAA server to terminate the existing user session with the previous authenticator and set up a brand-new one with the new authenticator 🙃. Honestly, this can complicate the setup and maintenance of the AAA user session, and it's giving a lot of unnecessary drama 🌪️.
7.2. Transport Aspect 🚚
The existing AAA protocols can carry EAP and ERP messages between the AAA server and AAA clients 📦. AAA transport of ERP messages is specified in Hoeper, Nakhjiri & Ohba [RFC5749] and Bournelle, et al. [DIAMETER-ERP]. AAA transport of EAP messages is specified in [RFC4072]. Key transport can also be done through an AAA protocol 🔐. Zorn, Wu & Cakulev [DIAMETER-AVP] specify a set of Attribute-Value Pairs (AVPs) that give native Diameter support for cryptographic key delivery. Main character energy for sure 👑✨.
8. Security Considerations 🛡️
This document does not introduce any new security vulnerabilities 🫶. Phew, no new drama here. Still, the rest of this doc is full of very real security stakes, so keep those in mind 🔥.
9. Acknowledgments 🌸
The authors would like to thank Mark Jones, Zhen Cao, Semyon Mizikovsky, Stephen Farrell, Ondrej Sury, Richard Barnes, Jari Arkko, and Lionel Morand for their reviews and comments. Literally the whole squad 💖🙌.
10. References 📚
10.1. Normative References 🌷
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008.
[RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed., "Extensible
Authentication Protocol (EAP) Early Authentication Problem
Statement", RFC 5836, April 2010.
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed.,
"EAP Extensions for the EAP Re-authentication Protocol
(ERP)", RFC 6696, July 2012.10.2. Informative References 🦋
[DIAMETER-AVP]
Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute-
Value Pairs for Cryptographic Key Transport", Work
in Progress, August 2011.
[DIAMETER-ERP]
Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G.
Zorn, "Diameter Support for the EAP Re-authentication
Protocol (ERP)", Work in Progress, June 2012.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application",
RFC 4072, August 2005.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295,
August 2008.
[RFC5749] Hoeper, K., Ed., Nakhjiri, M., and Y. Ohba, Ed.,
"Distribution of EAP-Based Keys for Handover and
Re-Authentication", RFC 5749, March 2010.
[RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the
Protocol for Carrying Authentication for Network Access
(PANA)", RFC 5873, May 2010.
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011.
[RFC6630] Cao, Z., Deng, H., Wu, Q., and G. Zorn, Ed., "EAP
Re-authentication Protocol Extensions for Authenticated
Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012.Authors' Addresses 💌
Glen Zorn (editor)
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 909 201060
EMail: glenzorn@gmail.com
Qin Wu
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012
China
Phone: +86-25-84565892
EMail: bill.wu@huawei.com
Tom Taylor
Huawei Technologies Co., Ltd.
Ottawa, Ontario
Canada
EMail: tom.taylor.stds@gmail.com
Yoav Nir
Check Point
5 Hasolelim St.
Tel Aviv 67897
Israel
EMail: ynir@checkpoint.com
Katrin Hoeper
Motorola Solutions, Inc.
1301 E. Algonquin Road
Schaumburg, IL 60196
USA
EMail: khoeper@motorolasolutions.com
Sebastien Decugis
INSIDE Secure
41 Parc Club du Golf
Aix-en-Provence 13856
France
Phone: +33 (0)4 42 39 63 00
EMail: sdecugis@freediameter.netThat's the whole spec, bestie! 🌈✨ You made it through 💅🎀
📦 where this page comes from
- ietf: rfc6697 2012-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms