Handover Keying (HOKEY) Architecture Design

The Extensible Authentication Protocol (EAP) is an authentication framework that supports different types of authentication methods. Originally designed for dial-up connections, EAP is now commonly used for authentication in in a variety of access networks. When a host (or "peer", the term used from this point onward) changes its point of attachment to the network, it must be re-authenticated. If a full EAP authentication must be repeated, several message round-trips between the peer and the home EAP server may be involved. The resulting delay will result in degradation or in the worst case loss of any service session in progress if communication is suspended while re-authentication is carried out. The delay is worse if the new point of attachment is in a visited network rather than the peer's home network, because of the extra procedural steps involved as well as because of the probable increase in round-trip time. RFC 5169 describes this problem more fully and establishes design goals for solutions to reduce re-authentication delay for transfers within a single administrative domain. It also suggests a number of ways to achieve a solution: 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. RFC 5295 tackles the problem of 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, while Wu, et al. specifies a method-independent re-authentication protocol (ERP) applicable to 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 collocated with a AAA proxy within the domain. Other work provides further pieces of the solution or insight into the problem. For the purpose of this memo, RFC 5749 provides an abstract mechanism for distribution of keying material from the EAP server to re-authentication servers. RFC 5836 contrasts the EAP re-authentication (ER) strategy provided by ERP 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 prior to its arrival. Hence, the goal of EAP early authentication is to complete all 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 as well as Authenticated Anticipatory Keying (AAK). All three early authentication mechanisms provide means to securely establish authenticated keying material on a Candidate Access Point (CAP) while still being connected to the Serving Access Point (SAP) but vary in their respective system assumptions and communication paths. In particular, direct pre-authentication assumes that clients are capable of discovering candidate access points and all communications are routed through the serving access point. On the other hand, indirect pre-authentication assumes an existing relationship between SAP and CAP, whereas the discovery and selection of Candidate Access Points is outside the scope of AAK. Furthermore, both direct and indirect pre-authentication require a full EAP execution to occur before the handover of the peer takes place, while AAK (like ERP ) uses keys derived from the initial EAP authentication. Both EAP re-authentication and early authentication enable faster inter-authenticator handovers. However, it is currently unclear how the necessary handover infrastructure can be deployed and integrated into existing EAP infrastructures. In particular, previous work has not described how ER servers that act as endpoints in the re-authentication process should be integrated into local and home domain networks. Furthermore, it is currently unspecified how EAP infrastructure can support the timely triggering of early authentications and aid with the selection of candidate access points. This document proposes a general HOKEY architecture and demonstrates how it can be adapted to different deployment scenarios. To begin with, recalls the design objectives for the HOKEY architecture. reviews the functions that must be supported within the architecture. describes the components of the HOKEY architecture. describes the different deployment scenarios that the HOKEY Working Group has addressed and the information flows that must occur within those scenarios, by reference to the documents summarized above where possible and otherwise within this document itself. Finally, provides an analysis of how AAA protocols can be applied in the HOKEY architecture.

This document contains no normative language, hence language does not apply. This document reuses terms defined in Section 2.2 of Ohba, et al. and Section 2 of Wu, et al.. In addition, it defines the following: Domain-Specific reauthentication Root Key. 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.. An instantiation of the mechanism described in Hoeper, et al. for creating and delivering root keys from an EAP server to an ER server. The use of keying material derived from an initial EAP authentication to enable single-roundtrip re-authentication of a mobile peer. For a detailed description of the keying material see Section 4 of Wu, et al.. A component of the HOKEY architecture that terminates the EAP re-authentication exchange with the peer.

This section investigates the design goals for the HOKEY architecture. These include reducing the signaling overhead for re- authentication and early authentication, integrating local domain name discovery, enabling fault-tolerant re-authentication and improving deployment scalability. These goals supplement those discussed in Section 4 of RFC 5169. Note that the identification and selection of Candidate Access Points is not a goal of the architecture, since those operations are generally specific to the lower layer in use.

ERP requires only one round trip; however, this roundtrip may require communication between a peer and its home ER and/or home AAA server in explicit bootstrapping and communication between local servers and home server in implicit bootstrapping even if the peer is currently attached to a visited (local) network. As a result, even this one round trip may introduce long delays because the home ER and home AAA servers may be distant from the peer and the network to which it is attached. To lower signaling overhead, communication with the home ER server and home AAA server should be minimized. Ideally, a peer should only need to communicate with local servers and other local entities.

When the peer is initially attached to the network or moves between heterogeneous networks, full EAP authentication between the peer and EAP server occurs and user interaction may be needed, e.g., a dialog to prompt the user for credentials. To reduce latency, user interaction for authentication at each handover should be minimized. Ideally, user involvement should take place only during initial authentication and subsequent re-authentication should occur transparently.

ERP bootstrapping must occur before (implicit) or during (explicit) a handover to transport the necessary keys to the local ER server involved. Implicit bootstrapping is preferable because it does not require communication with the home ER server during handover, but it requires the peer to know the domain name of the ER server before the subsequent local ERP exchange happens in order to derive the necessary re-authentication keying material. ERP does not specify such a domain name discovery mechanism and suggests that the peer may learn the domain name through the EAP-Initiate/ Re-auth-Start message or via lower-layer announcements. However, domain name discovery happens after the implicit bootstrapping completes, which may introduce extra latency. To allow more efficient handovers, a HOKEY architecture should support an efficient domain name discovery mechanism (for example, see Zorn, Wu & Wang) and allow its integration with ERP implicit bootstrapping. Even in the case of explicit bootstrapping, local domain name discovery should be optimized such that it does not require contacting the home AAA server, as is currently the case.

If all authentication services depend upon a remote server, a network partition can result in the denial of service to valid users. However, if for example an ER server exists in the local network, previously authenticated users can re-authenticate even though a link to the home or main authentication server doesn't exist.

To provide better deployment scalability, there should be no requirement for the co-location of entities proving handover keying services (e.g., ER servers) and AAA servers or proxies. Separation of these entities may cause problems with routing, but allows greater flexibility in deployment and implementation.

The operation of the authentication subsystem provided by HOKEY also depends on the availability of a number of discovery functions: discovery of candidate access points, by the peer, by the serving attachment point, or by some other entity; discovery of the authentication services supported at a given candidate access point; discovery of the required server in the home domain when a candidate access point is not in the same domain as the serving attachment point, or no local server is available; peer discovery of the local domain name (LDN) when EAP re-authentication is used with a local server. It is assumed that these functions are provided by the environment within which the authentication subsystem operates, and are outside the scope of the authentication subsystem itself. Local domain name discovery is a possible exception. The major functions comprising the authentication subsystem and their inter-dependencies are discussed in greater detail below. When AAA is invoked to authorize network access, it uses one of two services offered by the authentication subsystem: full EAP authentication, or EAP re-authentication. Note that although AAA may perform authentication directly in some cases, when EAP is utilized AAA functions only as a transport for EAP messages and the encryption keys (if any) resulting from successful EAP authentication. Pre-authentication triggers AAA network access authorization at each candidate access point, 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. Authenticated anticipatory keying (AAK) relies on ER key management to establish keying material on ER/AAK servers, but uses an extension to ER key management to derive and establish keying material on candidate authenticators. AAK uses an extension to EAP re-authentication to communicate with ER/AAK servers. EAP authentication, EAP re-authentication, and handover key distribution depend on the routing and secure transport service provided by AAA. Discovery functions and the function of authentication and authorization of network entities (access points, ER servers) are not shown. As stated above, these are external to the authentication subsystem.

The pre-authentication function is responsible for discovery of candidate access points and completion of network access authentication and authorization at each candidate access point in advance of handover. The operation of this function is described in general terms in Ohba, et al.. No document is yet available to describe the implementation of pre-authentication in terms of specific protocols; Pre-Authentication Support for PANA could be part of the solution.

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 provides the design objectives for an implementation of this function. ERP describes a protocol to implement EAP re-authentication.

The EAP authentication function is responsible for authenticating the peer at a specific access point using a full EAP exchange. Aboba, et al. defines the associated protocol, while Ohba, et al. describe the use of EAP as part of pre-authentication. Note that the HOKEY Working Group has not specified the non-AAA protocol required to transport EAP frames over IP that is shown in Figures 3 and 5 of Ohba, et al., although PANA is a candidate.

The authenticated anticipatory keying function is responsible for pre-placing keying material derived from an initial full EAP authentication on candidate access points. The operation is carried out in two steps: ER key management (with trigger not currently specified) places root keys derived from initial EAP authentication onto an ER/AAK server associated with the peer. When requested by the peer, the ER/AAK server derives and pushes predefined master session keys to one or more candidate access points. The operation of the authenticated anticipatory keying function is described in very general terms in Ohba, et al.. A protocol specification exists (see Cao, et al.).

Handover key management consists of EAP method independent key derivation and distribution and comprises the following specific functions: handover key derivation; and handover key distribution. The derivation of handover keys is specified in Salowey, et al., and AAA-based key distribution is specified in Hoeper, Nakhjiri & Ohba.

This section describes the components of the HOKEY architecture in terms of the functions they perform. The components cooperate as described in this section to carry out the functions described in the previous section. describes the different deployment scenarios that are possible using these functions. The components of the HOKEY architecture are as follows: the peer; the authenticator, which is a part of the serving access point and candidate access points; the EAP server; and the ER server, and the ER/AAK server , either in the home domain or local to the authenticator.

The peer participates in the functions described in as shown in . 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 pre-authentication Discovers candidate access points. Initiates pre-authentication with each, followed by EAP authentication as above, but using IP rather than L2 transport for the EAP frames. - - Indirect pre-authentication Enters into a full EAP exchange when triggered, using either L2 or L3 transport for the frames. - - EAP re-authentication Determines that EAP re-authentication is possible based on discovery or authenticator prompting. Participates in ERP exchange with ER server. - - Authenticated anticipatory keying Determines that AAK is possible based on discovery or serving authenticator prompting. Discovers candidate access points. Participates in ERP/AAK exchange, requesting distribution of keying material to the candidate access points. - - ER key management No role.

The serving authenticator participates in the functions described in as shown in . Function Serving Authenticator Role EAP authentication No role. - - Direct pre-authentication No role. - - Indirect pre-authentication Discovers candidate access points. Initiates an EAP exchange 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 candidate access point. - - EAP re-authentication No role. - - Authenticated anticipatory keying Mediates between L2 transport of AAK frames on the peer side and AAA transport toward the ER/AAK server. - - ER key management No role.

The candidate authenticator participates in the functions described in as shown in . 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 pre-authentication Invokes AAA network access 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 pre-authentication Same as direct pre-authentication, except that it communicates with the serving authenticator rather than the peer. - - EAP re-authentication Invokes AAA network access authentication and authorization upon handover. Discovers or is configured with the address of the ER server. Mediates between L2 transport of a ERP frames on the peer side and AAA transport toward the ER server. - - Authenticated anticipatory keying Receives and saves pMSK. - - ER key management No role.

The EAP server participates in the functions described in as shown in . 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 MSK to authenticator (via AAA). - - Direct pre-authentication As for EAP authentication. - - Indirect pre-authentication As for EAP authentication. - - EAP re-authentication Provides rRK or DSrRK to the ER server (via AAA). - - Authenticated anticipatory keying As for EAP re-authentication. - - ER key management Creates rRK or DSrRK and distributes it to ER server requesting the information.

The ER server participates in the functions described in as shown in . Function ER Server Role EAP authentication No role. - - Direct pre-authentication No role. - - Indirect pre-authentication No role. - - EAP re-authentication Acquires rRK or DSrRK as applicable when necessary. Terminates ERP signaling between it and the peer via the candidate authenticator. Determines whether network access authentication succeeds or fails. Provides MSK to authenticator. - - Authenticated anticipatory keying And acquires rRK or DSrRK as applicable when necessary. Derives pMSKs and passes them to the candidate access points. - - ER key management Receives and saves rRK or DSrRK as applicable.

Depending upon whether it involves a change in a domain or access technology, we have the following the usage scenarios.

The peer remains stationary and re-authenticates to the original access point. Note that in this case, the SAP takes the role of the CAP in the discussion above.

The peer moves between two authenticators in the same domain. In this scenario, the peer communicates with the ER server via the ER authenticator within the same network.

The peer moves between two different domains. In this scenario, the peer communicates with more than one ER server via one or two different ER authenticators. One ER server is located in the current network as the peer, one is located in the previous network from which the peer moves. Another ER server is located in the home network to which the peer belongs.

The peer moves between two heterogeneous networks. In this scenario, the peer needs to support at least two access technologies. The coverage of two access technologies usually is overlapped during handover. In this case, only authentication corresponding to intra-domain handover is required, i.e., the peer can communicate with the same local ER server to complete authentication and obtain keying materials corresponding to the peer.

This section provides an analysis of how the AAA protocol can be applied in the hokey architecture in accordance with the Authentication Subsystem Functional Overview (see )

Authorization is a major issue in deployments. Wherever the peer moves around, the home AAA server provides authorization for the peer during its handover. However, it is unnecessary to couple authorization with authentication at every handover, since authorization is only needed when the peer is initially attached to the network or moves between two different AAA domains. The EAP key management document discusses several vulnerabilities that are common to handover mechanisms. One important issue arises from the way the authorization decisions which might be handled at the AAA server during network access authentication. For example, if AAA proxies are involved, they may also influence in the authorization decision. Furthermore, the reasons for choosing a particular decision are not communicated to the AAA clients. In fact, the AAA client only knows the final authorization result. Another issue regards session management. In some circumstances when the peer moves from one authenticator to another, the peer may be authenticated by the different authenticator during a period of time and the authenticator to which the peer is currently attached needs to create a new AAA user session, however the AAA server should not view these handoffs as different sessions. Otherwise this may affect user experience and also cause accounting or logging issues. For example, session ID creation, in most cases, is done by each authenticator to which the peer attaches. In this sense, the new authenticator acting as AAA client needs to create a new AAA user session from scratch which forces its corresponding AAA Server to terminate the existing user session with previous authenticator and setup a new user session with the new authenticator. This may complicate the set up and maintenance of the AAA user session.

The existing AAA protocols can be used to carry EAP messages and ERP messages between the AAA server and AAA clients. AAA transport of ERP messages is specified in Hoeper, Nakhjiri & Ohba and Bournelle, et al.. AAA transport of EAP messages is specified in . Key transport also can be performed through a AAA protocol. Zorn, Wu & Cakulev specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery.

This document does not require any actions by IANA.

This note does not introduce any new security vulnerabilities.

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.