Network Working Group K. Hoeper Internet-Draft Motorola Intended status: Standards Track S. Decugis Expires: September 2, 2010 NICT G. Zorn Network Zen Q. Wu T. Taylor Huawei March 1, 2010 HOKEY Architecture Design draft-hoeper-hokey-arch-design-02 Abstract HOKEY seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reducing handover delay: early authentication, and reuse of cryptographic material generated during an initial authentication to save time during re- authentication. A starting assumption is that the mobile host or "peer" is initially authenticated using EAP, and the source of keying material used to authenticate the peer is an EAP authentication server in the peer's home network. This document describes the HOKEY architecture. Specifically, it describes design objectives for the architecture, main components of the HOKEY architecture, HOKEY deployment scenarios in the wireless environment, and the message flows that must pass between the architectural components in those various scenarios. Other documents describe the protocol(s) needed to implement the message flows. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Hoeper, et al. Expires September 2, 2010 [Page 1] Internet-Draft Architecture Design March 2010 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Hoeper, et al. Expires September 2, 2010 [Page 2] Internet-Draft Architecture Design March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Reducing Signalling Overhead . . . . . . . . . . . . . . . 7 3.1.1. Minimized Communications with Home Servers . . . . . . 7 3.1.2. Integrated Local Domain Name (LDN) Discovery . . . . . 7 3.2. Better Deployment Scalability . . . . . . . . . . . . . . 7 3.3. Enhancing Deployment Reliability . . . . . . . . . . . . . 7 3.4. Enabling Protocol Interoperability . . . . . . . . . . . . 8 4. Functions That Must Be Supported . . . . . . . . . . . . . . . 8 4.1. System Overview . . . . . . . . . . . . . . . . . . . . . 8 4.2. EAP-Based Handover Key Management . . . . . . . . . . . . 9 4.3. HOKEY Authentication Functions . . . . . . . . . . . . . . 9 4.3.1. Local Domain Name (LDN) Discovery . . . . . . . . . . 9 4.3.2. Authentication Capability Discovery . . . . . . . . . 9 4.3.3. Authenticator Discovery . . . . . . . . . . . . . . . 10 4.4. HOKEY Local ER Server Authorization . . . . . . . . . . . 10 5. Components of the HOKEY Architecture . . . . . . . . . . . . . 10 6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 11 6.1. Early Authentication Scenarios . . . . . . . . . . . . . . 11 6.1.1. Direct Pre-Authentication Model . . . . . . . . . . . 11 6.1.2. Indirect Pre-Authentication Model . . . . . . . . . . 12 6.1.3. Anticipatory Authentication Keying Model . . . . . . . 13 6.2. EAP Re-authentication . . . . . . . . . . . . . . . . . . 14 6.2.1. ER Server Located In the Home Domain . . . . . . . . . 14 6.2.2. ER Server In the Local Domain . . . . . . . . . . . . 16 6.3. EAP Early Re-authentication . . . . . . . . . . . . . . . 17 7. AAA Consideration . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Standalone HOKEY server . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Hoeper, et al. Expires September 2, 2010 [Page 3] Internet-Draft Architecture Design March 2010 1. Introduction The Extensible Authentication Protocol (EAP) [RFC3748] 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 wireless 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 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 round-trip time. [RFC5169] describes this problem more fully and establishes design goals for solutions to reduce re-authentication delay for transfers within a single administrative domain. [RFC5169] also suggests a number of ways to achieve a solution: o specification of a method-independent, efficient, re- authentication protocol; o reuse of keying material from the initial authentication; o deployment of re-authentication servers local to the peer to reduce round-trip delay; and o specification of the additional protocol needed to allow the EAP server to pass authentication information to the local re- authentication servers. Section 5.4 of [RFC5169] points out requirements related to authorization that must be satisfied by a solution providing improved re-authentication performance. These requirements are addressed as part of the discussion of the architecture specified by this document. [RFC5295] 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. [RFC5296] specifies a method-independent re- authentication protocol (ERP) applicable to two specific deployment scenarios: o where the peer's home EAP server also performs re-authentication; and o where a local re-authentication server exists but is collocated with a AAA proxy within the domain. One of the objectives of this document is to generalize the HOKEY Hoeper, et al. Expires September 2, 2010 [Page 4] Internet-Draft Architecture Design March 2010 architecture beyond the specific cases dealt with by [RFC5296]. As described below, this generalization entails further protocol specification. Other works in progress provide further pieces of the solution or insight into the problem. [I-D.ietf-HOKEY-key-mgm] provides an abstract mechanism for distribution of keying material from the EAP server to re-authentication servers. (The stated scope is more general, but is restated in terms consistent with the present summary.) [I-D.ietf-HOKEY-preauth-ps] contrasts the EAP re- authentication (ER) strategy provided by [RFC5296] (which [I-D.ietf-HOKEY-preauth-ps] calls "vertical context transfer") with an alternative strategy called "early authentication". [I-D.ietf-HOKEY-preauth-ps] 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. Here, a full EAP execution occurs before the handover of the peer takes place. Hence, the goal of EAP early authentication is to complete all EAP-related communications in preparation for the handover including AAA signaling before the mobile device moves. Both EAP re-authentication and early authentication enable faster inter-authenticator handovers. Early ER is also possible, combining the benefits of early authentication with the reduction in signalling offered by EAP re-authentication. However, it is currently unclear how the necessary handover infrastructure for ER is deployed and can be integrated into existing EAP infrastructures. In particular, previous work has not described how ER servers should be integrated into local and home domain networks. This document proposes a general HOKEY architecture and demonstrates how it can be adapted to different deployment scenarios. To begin with, Section 3 states 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. Finally, Section 6 describes the different deployment scenarios that the architecture supports and describes the information flows that must occur within those scenarios, by reference to the documents summarized above where possible and otherwise within this document itself. 2. Terminology The keywords "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]. Hoeper, et al. Expires September 2, 2010 [Page 5] Internet-Draft Architecture Design March 2010 In addition, the following terms are defined. In some cases, as noted below, the definitions extend the terminology used in previous documents, in order to accommodate a more general architecture. EAP Re-authentication (ER) The use of keying material derived from an initial EAP authentication to enable single-roundtrip re-authentication of a mobile peer. EAP Re-authentication Protocol (ERP) The collection of messages and behaviour required to support ER in the HOKEY architecture described by this document. Note that this is an extension of the ERP messages and behaviour described in [RFC5296]. HOKEY Authentication Services The services of EAP early authentication, EAP re-authentication, and EAP early re-authentication as defined below. EAP Early Authentication Service The service provided by the HOKEY architecture that allows a mobile peer to use EAP to establish authenticated keying material on a candidate attachment point prior to the peer's arrival. This is the same definition as in [I-D.ietf-HOKEY-preauth-ps]. EAP (Early) Re-authentication Service The service provided by the HOKEY architecture that allows a mobile peer to use EAP re-authentication to establish authenticated keying material on a candidate attachment point. This is termed "early" if it takes place prior to the peer's arrival. ER Server A component of the HOKEY architecture that holds the keying material (rRK and rIK) which is used to re-authenticate the peer and derive the keying material (rMSK) used by the authenticator to generate session keys. 3. Design Goals This section investigates the design goals for the HOKEY architecture. These include reducing the signaling overhead for re- authentication and early authentication, improving deployment scalability, enhancing deployment reliability, and enabling protocol interoperability. Hoeper, et al. Expires September 2, 2010 [Page 6] Internet-Draft Architecture Design March 2010 3.1. Reducing Signalling Overhead 3.1.1. Minimized Communications with Home Servers ERP requires only one round trip, however, this roundtrip may require communications between a peer and its home ER and/or home AAA server 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 home ER and home AAA servers may be distant from the peer. To lower the 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. 3.1.2. Integrated Local Domain Name (LDN) Discovery Ideally, whenever a peer performs a handover, ERP is executed between the peer and a local ER server, thus, reducing handover latency by avoiding a full EAP authentication with the peer's home EAP server. For this to work, ERP bootstrapping must occur before (implicit) or during (explicit) a handover to transport the necessary re- authentication root keys to the local ER server involved. Implicit bootstrapping is preferable because it does not require communication with the home ER server during handover (see previous section), but it requires the peer to know the domain name of the ER server in order to derive the necessary re-authentication keying material. [RFC5296] 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. To allow more efficient handovers, a HOKEY architecture should support an efficient domain name discovery mechanism 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. 3.2. Better Deployment Scalability To provide better deployment scalability, it should not be required that the HOKEY server and AAA servers or proxies are collocated. Separation of these entities may cause problems with routing, but allows flexibility in deployment and implementation. 3.3. Enhancing Deployment Reliability There may be situations where the peer moves from a previous access network supporting HOKEY service to a new access network not supporting HOKEY service or moves from a previous access network not Hoeper, et al. Expires September 2, 2010 [Page 7] Internet-Draft Architecture Design March 2010 supporting HOKEY service to a new access network supporting HOKEY service. To enhance deployment reliability, the HOKEY architecture should be designed such that a peer not supporting HOKEY service will still function in a network supporting HOKEY service, and also a peer supporting HOKEY service will still function in a network not supporting HOKEY service. 3.4. Enabling Protocol Interoperability TBD. The authors have not agreed on a statement of requirements under this heading, but invite comments. A suggestion was that messages associated with one HOKEY authentication service could be interworked with messages associated with another HOKEY authentication service (e.g. because the peer and network devices do not support the same service) to achieve authentication, presumably with some benefits over full EAP authen tication at the time of handover. 4. Functions That Must Be Supported 4.1. System Overview +------------------------------------------------------------+ | Functions of the HOKEY Architecture | | +-----------------------------+ | | |HOKEY Key Management | | | +-------------+ |+------------+ +------------+| | | |LDN Discovery|->||Handover Key| |Handover Key|| | | +-------------+ || Derivation | |Distribution|| | |+--------------+ |+------------+ +------------+| | || Capability | +-----/\-----------/\-----/\--+ | || Discovery | ||_ _ _ _ _ _|| || | |++-------------+ ||- - - - - -/ || | | | +----------------------\/----+ +-----------\/--------+ | | | | HOKEY Authentication | |[HOKEY Authorization]| | | | | +------------------------+ | | +---------------+ | | | | | |EAP Re-authentication | | | |Local ER Server| | | | +-->| +------------------------+ | | |authorization | | | | | +------------------------+ | | +---------------+ | | | | | Early EAP Re-authen | | +---------------------+ | | | +------------------------+ | +-------------+ | | | +------------------------+ | |Authenticator| | | | |Early EAP Authentication|<---------| Discovery | | | | +------------------------+ | +-------------+ | +-----+----------------------------+-------------------------+ Hoeper, et al. Expires September 2, 2010 [Page 8] Internet-Draft Architecture Design March 2010 System Overview The functions to be performed by the HOKEY architecture can be classified broadly as EAP-based handover key management, HOKEY authentication using handover key and optionally HOKEY ER server authorization. 4.2. EAP-Based Handover Key Management EAP-based handover key management consists of EAP method independent key derivation and distribution and comprises the following specific functions: o handover key derivation; and o handover key distribution. The derivation of handover keys is specified in [RFC5295], and key distribution is specified in [I-D.ietf-HOKEY-key-mgm]. 4.3. HOKEY Authentication Functions HOKEY authentication is focused on inter-authenticator handover or inter-technology handover and comprises the following alternatives: o early EAP authentication; o EAP re-authentication; o early EAP re-authentication. Definitions of these three alternatives were given in Section 2. The different modes of early EAP authentication are described in [I-D.ietf-HOKEY-preauth-ps]. [RFC5296] provides a protocol specification for two special cases of EAP re-authentication. A description of early EAP re-authentication is given below. [[[Cross- reference to be added.]]] 4.3.1. Local Domain Name (LDN) Discovery A LDN discovery mechanism is currently not defined for ERP even though it is necessary for implicit bootstrapping. [RFC5295] suggests learning local domain names via the lower layer (e.g., L2 or L3 announcements) or from the EAP-Initiate/Re-auth-Start message. An efficient mechanism needs to be defined and supported by the HOKEY architecture. 4.3.2. Authentication Capability Discovery This function allows the peer to determine which HOKEY authentication services are offered to it at a given candidate authenticator, and in which configurations (to the extent that the peer must be aware of them). The different possible configurations are described in Section 6. Hoeper, et al. Expires September 2, 2010 [Page 9] Internet-Draft Architecture Design March 2010 4.3.3. Authenticator Discovery This function allows the peer to discover candidate authenticators prior to handover. As explained in [I-D.ietf-HOKEY-preauth-ps], such a discovery capability is essential to permit early authentication or re-authentication. 4.4. HOKEY Local ER Server Authorization HOKEY local ER server authorization is optional and can be used to verify whether a local ER server is authorized to advertise the domain name known to the peer. This mechanism is currently implemented using an optional TLV payload in the EAP-Finished/Re-auth packet defined in [RFC5296]. Note that this is separate from any authorization of the peer that is required for it to operate at its new point of attachment. 5. Components of the HOKEY Architecture This section describes the components of the HOKEY architecture, in terms of the functions they perform. Section 6 describes the different configurations that are possible and the corresponding information flows. The components of the HOKEY architecture are as follows: o the peer; o the authenticator; o the EAP server in the home domain; and o the ER server, either in the home domain or in same domain as the authenticator. [Editor's note: Additional components may be needed to support authenticator and capability discovery. Comments are invited.] The HOKEY peer is service-aware. That is, the HOKEY peer understands and is capable of invoking one or more of the HOKEY authentication services. The HOKEY peer communicates directly with its serving authenticator and through the authenticator to the other components of the architecture. The authenticator supports the functions specified in [RFC3748] for purposes of initial EAP authentication. In addition, the authenticator is capable of supporting the HOKEY authentication services. Specifically, the authenticator has the following responsibilities: [[[[ To be continued ]]]] Hoeper, et al. Expires September 2, 2010 [Page 10] Internet-Draft Architecture Design March 2010 6. Deployment Scenarios 6.1. Early Authentication Scenarios The scenarios of this section are taken from [I-D.ietf-HOKEY-preauth-ps]. A pre-condition of these scenarios is that the peer is aware of the HOKEY early authentication service and is prepared to invoke it. The peer needs to be aware of whether the direct pre-authentication model is used or one of the other two models, but does not have to distinguish between those latter two because the serving authenticator hides the difference between them. An obvious preliminary remark is that the three models require different protocols and procedures, and it would be desirable to standardize just one of them to avoid redundant implementation effort. 6.1.1. Direct Pre-Authentication Model The direct pre-authentication model is described in Section 6.1.1 of [I-D.ietf-HOKEY-preauth-ps] and illustrated in Figure 1. While the signalling is routed by the serving authenticator, the latter has no other role to play in the early authentication process. +---------+ +-------------+ +----------+ | | IP | Candidate | | EAP | | Peer +------------|Authenticator|-----| Server | | | New | | | | +---------+ protocol +-------------+ +----------+ Figure 1: Early Authentication, Direct Pre-Authentication Model For this configuration, the procedure is as follows: 1. The peer discovers the IP address of a candidate authenticator. Section 7.1 of [I-D.ietf-HOKEY-preauth-ps] suggests some possible ways this might be accomplished. 2. The peer sends a message to the candidate authenticator containing the information needed to initiate an EAP exchange with the EAP server. The protocol for this message requires specification, and must include message authentication and integrity. 3. The candidate authenticator recognizes that the message is a request to initiate early EAP authentication. It encapsulates the EAP portion as a AAA message and sends to the EAP server. Remark: the EAP initiation message should probably contain an Hoeper, et al. Expires September 2, 2010 [Page 11] Internet-Draft Architecture Design March 2010 indication that this is an early authentication request. That way, AAA can know not to apply a session limit to the request. Further, AAA can provide a limited lifetime for the generated information so that it expires naturally if the peer ends up connecting to a different candidate authenticator. Conveyance of this lifetime would require an extension to the existing EAP. 4. The EAP exchange continues as usual to its completion. The candidate authenticator is left holding the keying material needed to establish a session with the peer when and if the latter connects to it. 5. Handover to the candidate authenticator occurs. The peer secures the link to the chosen authenticator and then completes channel binding. Remark: the obvious way to perform channel binding is for the peer to authenticate over the channel using EAP re- authentication. If it does so, one of the configurations described in Section 6.3 is applicable, along with the accompanying procedures. 6.1.2. Indirect Pre-Authentication Model The indirect pre-authentication model is described in Section 6.1.2 of [I-D.ietf-HOKEY-preauth-ps] and illustrated in Figure 2. The serving authenticator plays a more active role than in the direct model, by re-encapsulating the EAP exchanges within a AAA protocol. The serving authenticator then acts as a AAA client to the candidate authenticator as AAA server. +-----+ +---------+ +---------+ +-------+ | | L2 or | Serv'g | AAA | Cand. | AAA | EAP | |Peer +---------|Authen'r |-----|Authen'r |-----|Server | | | L3 | | L3 | | | | +-----+ +---------+ +---------+ +-------+ Figure 2: Early Authentication, Indirect Pre-Authentication Model The procedures required in this configuration are broadly similar to those for the previous one, but with specific points of difference: 1. The peer discovers the IP address or FQDN of the candidate authenticator, as in the previous case. If the candidate is in the same subnet, or possibly in the same domain, a layer 2 endpoint identifier may be sufficient for the serving authenticator to get the address of the candidate authenticator. Hoeper, et al. Expires September 2, 2010 [Page 12] Internet-Draft Architecture Design March 2010 2. The peer sends a request for pre-authentication to the serving authenticator, as a layer 2 frame or layer 3 packet. This identifies/gives the address of the candidate authenticator and has content to initiate EAP authentication. 3. The serving authenticator encapsulates the content in a layer 3 protocol (e.g., Diameter) and passes the request for pre- authentication on to the candidate authenticator. Remark: a AAA protocol may not be the most suitable for this purpose, since the request must reach a specific host rather than any entity in the domain that supports an application. If another protocol is chosen, thought has to be given to securing the content. 4. The remaining steps are as for the previous case. 6.1.3. Anticipatory Authentication Keying Model The anticipatory authentication keying model is described in Section 6.2 of [I-D.ietf-HOKEY-preauth-ps] and illustrated in Figure 3. The difference from the previous models is that the serving authenticator communicates directly with the EAP server and asks it to push the keying material to the candidate authenticator. This has a simpler trust model than the one required for the previous models. +-----+ +---------+ +-------+ +---------+ | | L2 or | Serv'g | AAA | EAP | AAA | Cand. | |Peer +---------|Authen'r |-----|Server |-----|Authen'r | | | L3 | | | | | | +-----+ +---------+ +-------+ +---------+ Figure 3: Early Authentication, Indirect Pre-Authentication Model For this model, the procedure is as follows: 1. The peer discovers the FQDN of the candidate authenticator. It is possible that a L2 endpoint identifier combined with realm would be sufficient, if the candidate authenticator can be assumed to have provided this information to the EAP server previously. 2. The peer sends a request to the serving authenticator to initiate early authentication to the candidate authenticator. The request includes the discovered identifier. 3. The serving authenticator repackages the request as a AAA message and sends it to the peer's home EAP server as indicated by the NAI in the request. Hoeper, et al. Expires September 2, 2010 [Page 13] Internet-Draft Architecture Design March 2010 4. A normal EAP exchange ensues. 5. Following successful conclusion of the exchange, the EAP server acting as client pushes the resulting keying material to the candidate authenticator. As noted in the previous section, the fact that this message must go to a specific host raises the question of whether AAA is the appropriate transport. On the other hand, using AAA as transport resolves issues regarding trust and policy. 6. Handover follows as with the previous two cases. 6.2. EAP Re-authentication This section assumes, unlike the previous one, that (re-)authentication occurs at the time of handover. As a result, the only authenticator considered is the one to which the peer has moved. EAP re-authentication requires the use of an ER server as defined in Section 2. This section considers two configurations: where the ER server is in the home domain, and where it is in the domain local to the authenticator. In general, it is likely that ER servers are present in both locations. Clearly the architecture must operate properly under such circumstances, ensuring that both the local and the home server can get access to the necessary keying material and giving precedence to the local server for the actual re- authentication when it is available. Section 2 defined ERP as the collection of messages and behaviours supporting EAP re-authentication. In truth, the authors are uncomfortable calling this collection a protocol, since different messages over different interfaces are involved. The descriptions below avoid the term by speaking of messages only. 6.2.1. ER Server Located In the Home Domain This configuration is shown in Figure 4. The original EAP authentication is done through the serving authenticator. When the peer moves to the new authenticator, it requests re-authentication. The request is routed to the ER server, which requests the necessary keying material from the EAP server. After receiving it, the ER server authenticates the peer and responds, thereby achieving single- round-trip authentication. Hoeper, et al. Expires September 2, 2010 [Page 14] Internet-Draft Architecture Design March 2010 +---------+ +-------------+ +----------+ | | | Serving | | EAP | | Peer +-------|Authenticator|-------| Server | | | | | | | +---------+ +-------------+ +----------+ | | Pulled Moves | keying | | material V V +---------+ +-------------+ +----------+ | | | Target | AAA | Home | | Peer +-------|Authenticator|-------| ER | | | | | | Server | +---------+ +-------------+ +----------+ Figure 4: EAP Re-authentication With ER Server Located In Home Domain The detailed procedures associated with this configuration are as follows: 1. At the time of the initial authentication, the EAP server caches the information (i.e., the key name and EMSK) necessary to produce an rMSK when it is required. 2. The peer moves to the target authenticator. 3. The peer determines that the target authenticator supports EAP re-authentication. OPEN ISSUE: how to achieve this capability discovery step. 4. The peer sends a request for EAP re-authentication to the target authenticator. The content is as described in Section 3 of [RFC5296]. 5. The target authenticator packages the request as an AAA message. The target authenticator is aware that there is no ER server in the local domain, and therefore routes the request to the ER server in the home domain. 6. The ER server in the home domain provides a response to the authenticator. The content is as described in Section 3 of [RFC5296]. 7. The authenticator authorizes the peer and passes the response on to it. Hoeper, et al. Expires September 2, 2010 [Page 15] Internet-Draft Architecture Design March 2010 6.2.2. ER Server In the Local Domain This configuration is shown in Figure 5. As in the previous case, the original authentication is done through the serving authenticator. +---------+ +-------------+ +----------+ | | | Serving | | EAP | | Peer +-------|Authenticator|-------| Server | | | | | | | +---------+ +-------------+ +----------+ | | Moves | | | +----------+ | | | Local | AAA | | ER |---------------- | | Server | +-----+----+ | | AAA | Re-authen request V | +---------+ +-------------+ | | | Target | | Peer +-------|Authenticator| | | | | +---------+ +-------------+ Figure 5: EAP Re-authentication With ER Server Located In Local Domain The detailed procedure in this case is as follows: 1. The peer moves to the target authenticator. 2. The peer determines that the authenticator supports EAP re- authentication. Also at this point, the peer discovers the local domain name, so that it can generate the domain-specific rRK and rIK for itself. OPEN ISSUEs: how to achieve capability and local domain name discovery. 3. The peer sends a request for EAP re-authentication to the target authenticator. The content is as described in Section 3 of [RFC5296]. 4. The target authenticator packages the request as a AAA message and forwards it to the local ER server. Hoeper, et al. Expires September 2, 2010 [Page 16] Internet-Draft Architecture Design March 2010 5. The local ER server checks whether it has the DSrRK and DSrIK corresponding to the peer. If not, it sends a request to the EAP server to obtain that keying material. The request includes credentials of the local ER server itself, so that the EAP server can authenticate and authorize it. 6. The local ER server authenticates the peer, generates an rMSK from the DSrRK, and returns it to the target authenticator. 7. The authenticator authorizes the peer and passes the response on to it. 6.3. EAP Early Re-authentication This is a sketch only, put out for comment: 1. The peer discovers the existence of candidate authenticator, with support for ERP + Early auth, and the local (ERP) domain name of that authenticator (how TBD). 2. The peer initiates a new ERP exchange (i.e. new sequence number) with the acting ER server, with an indication of the new candidate authenticator inside (extension to ERP, TBD). This is sent through the serving authenticator, which processes it as usual (encaps in AAA, send to ER server). 3. The ER server processes the message, and if successful derives a new rMSK. *But* it does not include this rMSK in the answer. 4. The ERP answer (success) is sent back to the peer through the serving authenticator, so that the peer can derive the same rMSK. 5. The new rMSK is sent with a different message to the candidate authenticator. From this point, the Secure Association Protocol may start between the peer and the candidate authenticator, should it choose to move there. 7. AAA Consideration 7.1. Standalone HOKEY server TBD. 8. Security Considerations TBD Hoeper, et al. Expires September 2, 2010 [Page 17] Internet-Draft Architecture Design March 2010 9. IANA Considerations This document has no actions for IANA. 10. Acknowledgments The authors would like to thank all colleagues for their review and comments of this draft. 11. References 11.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. [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. [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)", RFC 5296, August 2008. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [I-D.ietf-HOKEY-preauth-ps] Wu, Q., Ohba, Y., and G. Zorn, "EAP Early authentication problem statement", draft-ietf-HOKEY-preauth-ps-09 (work in progress), May 2009. 11.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Hoeper, et al. Expires September 2, 2010 [Page 18] Internet-Draft Architecture Design March 2010 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008. [I-D.ietf-HOKEY-key-mgm] Hoeper, K. and Y. Ohba, "Distribution of EAP based keys for handover and re-authentication", draft-ietf-HOKEY-key-mgm-09 (work in progress), April 2009. Authors' Addresses Katrin Hoeper Motorola, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA Email: khoeper@motorola.com Sebastien Decugis NICT 4-2-1 Nukui-Kitamachi Tokyo, Koganei 184-8795 Japan Email: sdecugis@nict.go.jp Glen Zorn Network Zen 1310 East Thomas Street Seattle, Washington 98102 USA Email: gwz@net-zen.net Hoeper, et al. Expires September 2, 2010 [Page 19] Internet-Draft Architecture Design March 2010 Qin Wu Huawei Technologies Co.,Ltd Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. Nanjing, JiangSu 210001 China Phone: +86-25-84565892 Email: sunseawq@huawei.com Tom Taylor Huawei Technologies Co., Ltd 1852 Lorraine Ave Ottawa Canada Email: tom111.taylor@bell.net Hoeper, et al. Expires September 2, 2010 [Page 20]