Network Working Group M. Nakhjiri Internet-Draft Huawei USA Expires: October 7, 2007 April 5, 2007 Keying and signaling for wireless access and handover using EAP (EAP-HR) draft-nakhjiri-hokey-hierarchy-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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." 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 October 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Problems related to AAA-based key management for facilitating optimized secure handovers and re-authentications have been described in several problem statements ([I-D.nakhjiri-aaa-hokey-ps], [I-D.ohba-hokey-3party-keydist-ps] and [I-D.ietf-hokey-reauth-ps]). This document provides description of an EAP initiated key hierarchy as part of the solution for those problems. Additionally a modified version of the 3-party key distribution orocess ([I-D.ohba-hokey-3party-keydist-ps]) is proposed to provide a binding between the generated/distributed keys and the parties using the Nakhjiri Expires October 7, 2007 [Page 1] Internet-Draft A Handover Keying Hierarchy Description April 2007 keys. A new EAP method called EAP handover and re-authentication (EAP_HR) is also described to significantly reduce handover keying and re-authentication latency. AAA attributes and EAP type data extensions are also covered. Table of Contents 1. Introduction and Problem statement . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 5 4. 3 party Key distribution exchange (KDE) . . . . . . . . . . . 10 5. Signaling using EAP-HR and AAA . . . . . . . . . . . . . . . . 12 5.1. signaling scenarios . . . . . . . . . . . . . . . . . . . 12 5.1.1. Network setup scenario . . . . . . . . . . . . . . . . 12 5.1.2. Authenticator handover and/or re-authentication scenarios . . . . . . . . . . . . . . . . . . . . . . 14 5.2. AAA and EAP extensions . . . . . . . . . . . . . . . . . . 15 5.2.1. AAA AVPs . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. EAP-HR and EAP-HR Type data fields . . . . . . . . . . 16 5.2.3. backward compatibility with EAP . . . . . . . . . . . 18 6. Security report Card . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.2. Informative references . . . . . . . . . . . . . . . . . . 21 Appendix A. Appendix A: Support of handovers within a mobility domain (intra-authenticator handovers) . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Nakhjiri Expires October 7, 2007 [Page 2] Internet-Draft A Handover Keying Hierarchy Description April 2007 1. Introduction and Problem statement It is becoming more and more common to use the Extensible Authentication Protocol (EAP) framework ([RFC3748] ) for access control authentication and bootstrapping the wireless link security. This is done by performing an EAP authentication method that is capable of generating EAP master sessionkeys, MSK and EMSK ([I-D.ietf-eap-keying]), which are, in turn, used to bootstrap the so called temporary session keys, TSK) for securing the wireless link. The typically deployed model is one where EAP authentication is performed as a peer to peer protocol between the peer and a backend server, without involving much intelligence from the edge of the network. At the edge, the model only uses a logical entity called pass-through authenticator (typically simply called authenticator), which only takes part in changing the form of encapsulation of the EAP, but is otherwise passive until the very end, where the keying material for establishment of TSKs are generated from EAP master session keys and are transported to this authenticator. Deploying this model creates a number of issues that are listed in the problem statement drafts ([I-D.nakhjiri-aaa-hokey-ps] and [I-D.ietf-hokey-reauth-ps]); for instance, the model does suffers from the inherent lack of support for fast re-authentications in EAP when peer's session is expiring. Another issue is that the way the keying material from the initial EAP authentication is distributed to the authenticators does not readily allow for optimized handovers without breaking security principles ([I-D.housley-aaa-key-mgmt]). This document provides a description of how the EAP extended master session key (EMSK) can be used according to [I-D.ietf-hokey-emsk-hierarchy]) to arrive at a handover root key (HRK) for the current administrative domain. The root key is in turn used as root for a key hierarchy that provides a solution for fast re-authentication with the HOKEY server and/or quick and secure handover security provisioning by generating and delivering per authenticator keys (MDMSK) to the authenticators. Such per- authenticator (per-MDC) keys (MDMSK) are generated for each serving MDC as the peer attaches to the network or moves its point of attachment. Signaling to provide a channel binding mechanism that also achieves peer consent in delivery of the key to the authenticators is also described. The signaling proposed for bootstrapping the MDMSKs for MDCs in conjunction to initial network setup or handovers is EAP. Since EAP authentication is a 2 party protocol, additional measures should be taken to properly utilize the EAP generated keys in a 3 party key management (involving peer, authenticator and server) scenarios. This involves channel binding procedures and verification Nakhjiri Expires October 7, 2007 [Page 3] Internet-Draft A Handover Keying Hierarchy Description April 2007 of key sources. This document provides a modified version of the procedures presented in the previous version of this draft and the solution proposed in [I-D.ohba-hokey-3party-keydist-ps]. A new EAP method, called EAP Handover and Re-authentication (EAP-HR), is proposed here to introduce minimal changes to the existing authenticator deployment base. The proposed signaling adds 1.5 round trip in case of initial network setup and approximately 1 round trip for re-authentication in conjunction with session life time expiry and authenticator (MDC) handovers. It should be noted modifications to the current EAP Identity Type signaling (to carry type data) can achieve the same effect. EAP-HR is proposed as an alternative that does not require any changes to the existing EAP Identity type messaging. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. HOKEY server: This is essentially a AAA server, that can receive a domain specific handover root key (HRK) from the EAP server or a HOKEY server and can act as an authority for authorization HOKEY service, perform re-authentiation and/or generate per- authenticator keys (MDMSK) in conjunction to network setup, handovers and re-authentication. Mobility Domain/MDC: The terms mobility domain and Mobility Domain Controller (MDC) are introduced to allow for the architectures where an authenticator is responsible for managing a number of edge devices (Access nodes). A cluster of ANs can form a mobility domain, managed by an mobility domain controller (MDC) acting as authenticator and AAA client on behalf of all those ANs when dealing with the AAA and EAP server. The MDC would receive the master key (MDMSK) sent by the home AAA server (deploying HOKEY server) and generate master keys for the ANs it is managing, as it sees fit. More details on this architecture is provided in the appendix. HRK: Handover root key is a key that will be used as the root key to solve the handover keying and re-authentication problem. The HRK can be derived directly from EMSK as a usage specific and domain independent specific root key for re-authentication and handover, using a Pseudo random function (PRF) that complies with requirements and guidance in [I-D.ietf-hokey-emsk-hierarchy]. For simplicity we refer to this PRF as USRK_PRF. Nakhjiri Expires October 7, 2007 [Page 4] Internet-Draft A Handover Keying Hierarchy Description April 2007 HHRK: Home handover root key is a key that will be used as the root key to solve the handover keying and re-authentication problem within the home AAA domain. The HHRK can be derived directly from EMSK as a usage specific and domain specific root key for re- authentication and handover, using a Pseudo random function (PRF) that complies with requirements and guidance in [I-D.ietf-hokey-emsk-hierarchy] (USRK_PRF). Alternatively, the HHRK can also be generated from HRK as usage specific but domain independent key from EMSK. HO_PRF: The PRF that is used by the peer and the HOKEY server to derive any keys from the HRK. The HO-PRF may or may not comply with requirements specified for USRK (since the HRK and not EMSK is being used to provide entropy), and only needs to be supported by the crypto-engines at both peer and the HOKEY server. The HO_PRF can be access technology agnostic and can be pre-configured based on peer and AAA capabilities to avoid cipher suite negotiations, if desired. IK and CK: Integrity and cipher keys, used to protect the EAP signaling between the peer and the HOKEY server. MDMSK: Mobility Domain Master Session Key: A key derived specifically for each authenticator/MDC at the HOKEY server and at the peer MDC. This key is then used by the peer and the MDC to establish a secure network attachment link. MDC Identifier (MDC_ID): The identifier for the MDC serving the peer. This ID must unequivocally and uniquely identify the MDC to both the peer, the EAP server (and the ANs being served by the MDC, when applicable). 3. Key Hierarchy and Generation Upon successful completion of the EAP authentication method, the EAP server generates the EAP EMSK as defined by the EAP method that was executed. From this EMSK, an USRK designated for handover keying application can be generated, assuming that based on the user profiles, the AAA server can successfully authorize the user (peer) for use of the HOKEY (handover keying and re-authentication) service instead of EAP service. We called this usage specific root key (USRK) the HRK. Specification of generation of USRKs is work under progress ([I-D.ietf-hokey-emsk-hierarchy]), but it is expected that since the EAP layer does not export EMSK, the HOKEY server needs to, following the authorization, request derivation of the HRK from the EAP server. Nakhjiri Expires October 7, 2007 [Page 5] Internet-Draft A Handover Keying Hierarchy Description April 2007 It should be noted that USRKs are domain indpendent, meaning that an HRK generated for hanodver and re-authentication usage will be the root key for all domains, and a separate root key needs to be generated for each domain, e.g. a home HRK (HHRK) for home domain and a visited HRK (VHRK) for each visited domain. The USRK specification also allows generation of usage and domain specific keys (USDSRK). Thus, it is possible for a single domain operation to simply consider generating a USDSRK for handover keying within home domain (i.e. an HHRK) directly from the EMSK. Upon request, the EAP layer that holds EMSK generates an HRK and delivers it to the HOKEY server (seen as AAA server in this document) that oversees the operation of home and visited domain HOKEY servers. The HRK is stored at this HOKEY server database, where it is fetched for generation of domain HRKs for each domain and keys for each authenticator within home domain. Many wireless networks tend to deploy a gateway (e.g. Access Service Node gateway, ASN-GW in WiMAX architecture), that manages a cluster of edge devices (access nodes, ANs) called to form a mobility domain. The gateway tends to include AAA client functionality, DHCP server/ relay function, mobility management within the mobility domain (without dealing with AAA server) and many other functions, such as Mobile IP agent function. For the purpose of keeping our design generic to serve both two-level deployment models and the flat models, we assume the EAP authenticator, AAA client and other mobility domain functionalities required of such access gateways are embedded in one device which we call mobility domain controller (MDC). Thus we refer to the session key delivered to the mobility domain contoller as mobility domain master session key (MDMSK). As the peer moves from one authenticator/MDC to the next, its continuing operation requires delivery of new MDMSKs to the new serving MDC. Following the key hierarchy specification, the MDMSK is derived at the HOKEY/AAA server using the HRK for the serving domain. The MDMSK for each MDC is kept hidden from other MDCs. The entire key hierarchy is shown in the following figure. Nakhjiri Expires October 7, 2007 [Page 6] Internet-Draft A Handover Keying Hierarchy Description April 2007 EMSK | HRK ________________|____________________________ | | | | | VHRK1 .. VHRKn HHRK CK IK _____________________|___________________......______ | | | | | HCK HIK MDMSK1 MDMSK2 MDMSKm Figure 1: A keying hierarchy to support handover and re- authentications HRK | HRK_name_Key=HRK-PRF (EMSK, Usage_label | NULL | Peer_ID | Key_length) Where, it is assumed that HRK_PRF generates Z=X+Y bits, where the first X bits are used for HRK, while the remaining Y bits are used for HRK_name_key, which is used to create temporal uniqueness in the key name generation (see below). The HRK-PRF may be negotiated, pre- configured or chosen based on a network policy decision in a manner that is compliant with requirements defined in [I-D.ietf-hokey-emsk-hierarchy] The "Usage_label" value is to be assigned by IANA to the string "Domain Handover Root Key Derivation". NULL as domain label: It should be noted that for the purpose of supporting roaming the HRK is generated as a usage specific but domain independent root key (USRK) and thus a NULL has been used instead of the domain label. Peer_ID is the identifier for the peer as known to the server generating HHRK. This identifier is exchanged in the key distribution exchange (KDE) as described shortly. HRK_name=First (128, HMAC_SHA256(HRK_name_Key, "handover root key derivation"| peer_ID | NULL)) Where, First (N, X) refers to the first N bits of X. The home HRK (HHRK) and visited domain HRKs (VHRK) are generated as a usage and domain specific root key (USDSRK), specifically for home domain and thus Home_domain_ID or Visited_domain_ID serve as a domain label. HHRK | HHRK_name_Key=HO_PRF(HRK, Peer_ID | home_doamin_ID | Nakhjiri Expires October 7, 2007 [Page 7] Internet-Draft A Handover Keying Hierarchy Description April 2007 Key_length) VHRK | VHRK_name_Key=HO_PRF(HRK, Peer_ID | visited_domain_ID | Key_length) Since HHRK and VHRK are no longer derived from the EMSK, the PRF used for generating these keys may or may need to comply with the requirements in [I-D.ietf-hokey-emsk-hierarchy] and thus we have used the notion of HO_PRF to indicate this flexibility. HHRK_name=First (128, HMAC_SHA256(HHRK_name_Key, "domain handover root key derivation"| peer_ID)) VHRK_name=First (128, HMAC_SHA256(VHRK_name_Key, "domain handover root key derivation"| peer_ID)) Home_domain_ID or the Visited_domain_ID is the identifier for the home or visited domain as known to both peer and the server generating HHRK or VHRK. When roaming from one domain to the next, the peer needs to request for the domain handover root key to be generated from the HRK and exchange its own identity as well as the domain identity with the server. To protect the key distribution signaling, the peer and main HOKEY server can use a pair of domain independent integrity key (IK) and cipher key (CK), which are generated as follows. IK | IK_name_key=HO-PRF (HHRK, "Integrity Key" | peer_ID | NULL | Key_length ) IK_name=First(128, HMAC_SHA256(IK_name_key "Integrity Key"| peer_ID) CK | CK_name_key=HO-PRF (HHRK, "Cipher Key" | peer_ID | NULL | Key_length ) CK_name=First(128, HMAC_SHA256(CK_name_key, "Cipher Key"| peer_ID) It is important that the IK and CK used for protecting the signaling in a roaming case can stay domain indepdent and thus the use of NULL instead of the domain identifier. It is assumed that HHRK is delivered to the HOKEY server within the home domain. It should be noted that HHRK is only accessible to the peer and the HOKEY server within home domain, but not to HOKEY servers within other domains. HHRK is not accessible to any authenticators. The HHRK is then used to generate MDMSKs for the MDCs within the home domain and to generate integrity key and cipher key (IK and CK) to protect the EAP signaling between the HOKEY server and the peer. Thus, the HHRK is used to also generate the IK and CK Nakhjiri Expires October 7, 2007 [Page 8] Internet-Draft A Handover Keying Hierarchy Description April 2007 to protect the EAP-HR signaling to perform re-authentication with the HOKEY server or to perform the exchanges required to arrive at an MDMSK for any authenticator the peer attaches to. HIK | HIK_name_key=HO-PRF (HHRK, "domain integrity Key" | peer_ID | Home_domain_ID | Key_length ) HIK_name=First(128, HMAC_SHA256(HIK_name_key "domain integrity Key"| peer_ID) HCK | HCK_name_key=HO-PRF (HHRK, "domain cipher Key" | peer_ID | Home_domain_ID | Key_length ) HCK_name=First(128, HMAC_SHA256(HCK_name_key, "domain cipher Key"| peer_ID) The Integrity and cipher keys (IK and CK) are used to protect the EAP-HR signaling between the peer and the HOKEY servers and are cached by the peer and HOKEY server within the current domain and are not exposed to any outside parties. MDMSK_i= HO-PRF (HHRK, "MDMSK generation" | peer_ID | Home_domain_ID | MDC_ID | Nonce | Key_length) MDMSK_i is the key sent to ith authenticator/ MDC within the domain (in this case the home domain) by the HOKEY server within the domain. This key is then used by the peer and the MDC to establish a secure network attachment link. It should be noted that the distribution of MDMSK to the MDC needs to happen in a manner that provides proper binding between the key and the identity of the peer and the MDC, and must be delivered in a fashion that no other MDC can gain access to this key. The Nonce is added to create temporal uniqueness to avoid generation of the same key during multiple visits of the peer to the same authenticator during the same EAP session. The HOKEY server may delete the MDMSK_i cache after transport, if required for compliance with principle of least privilege. In cases where access nodes are involved, further key hierarchy levels may be required. This is explained in more details in the appendix. Nakhjiri Expires October 7, 2007 [Page 9] Internet-Draft A Handover Keying Hierarchy Description April 2007 4. 3 party Key distribution exchange (KDE) In this section we attempt to describe how the earlier proposed key hierarchy can be used for improving the latency involved in handover and re-authentication. Using the key hierarchy would mean that an MDMSK (generated from an EMSK-based hierarchy) would have to be installed in the authenticator dealing with the peer both at the time of network setup (bootstrapping) and at the time of authenticator handover. However, as explained in [I-D.ohba-hokey-3party-keydist-ps], the EMSK is generated as a result of an EAP method, which is a two party exchange, while the resulting MDMSK must be transported to an authenticator, which is considered a third party for the initial EAP exchange. Thus, both the initial 2 parties in the EAP process, i.e. The peer and the server need to make sure that they are dealing with the same third party (authenticator) before allowing the authenticator access to the MDMSK. [I-D.ohba-hokey-3party-keydist-ps] proposes a modified version of the Otway-Rees protocol that meets the requirements for such 3-party lay-out. This document provides an slight adaptation of that proposal to carry the MDMSK from the HOKEY server to the authenticator. The description below can be carried over a generic transport and thus is independent of the exact type of protocol that is used. However for the purpose of this document the assumption is that the 3 party mechanism parameters are carried for EAP messages that are themselves encapsulated over an access technology suited transport between the peer and the authenticator and over AAA protocols between the authenticator and the HOKEY server. The exchange proposed below is to perform a channel binding and avoid the lying NAS scenario, where the authenticator announces a down link ID to the peer (DAID) and a different uplink ID to the server (UAID). The peer uses DAID in its token towards the server, while the authenticator uses its UAID in its token to the server. Server must use the UAID from peer token to calculate the MIC in the authenticator ([PID, UAID]Kas) and if there is a match, then the server can verify that DAID and UAID are the same as the AID and proceed with generating and provisioning of MDMSK, otherwise the server MUST return a failure code instead of generating an MDMSK. The 3 party key distribution basically consists of 1 exchange, i.e. 2 messages between the peer and the HOKEY server. However, each message traverses over two logical hops (peer-authentcator) and (authenticator-HOKEY server) and thus the exchange can be seen as 4 logical messages. It should be noted that message 0 below is adding to comply with EAP request/response state machine requirements and can be eliminated otherwise as the information in message 0 can be advertised through other means. Nakhjiri Expires October 7, 2007 [Page 10] Internet-Draft A Handover Keying Hierarchy Description April 2007 0 Authenticator to peer: EAP(DAID, DID) 1 Peer to Authenticator: EAP((PID, DAID, DID, Np,KNps), [PID, DAID, Np,KNps]Kps) 2 Authenticator to Server: AAA(PID, UAID, [PID, UAID]Kas), AAA(EAP((PID, DAID, DID, Np,KNps), [PID, DAID, DID, Np,KNps]Kps)) 3 Server to Authenticator: AAA({PID,AID,KNpa, KLpa, Kpa}KEas), AAA(EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa, KNps]Kps)) 4 Authenticator to Peer: EAP(KNpa, KLpa, KNps, [PID, AID, DID, Np+1, KNpa,KLpa, KNps]Kps]) the notation is as follows: PID: peer ID. The information is expected by carried by an existing attribute within EAP and/or AAA protocols. DID: Domain ID, used for generation of domain specific keys, such as HHRK (see key generation). AID: Authenticator ID (obtained by the peer through beacon announcements or as part of EAP Identity Request) DAID: Authenticator ID as perceived by the peer (down link ID) UAID: Authenticator ID as perceived by the server (uplink ID) {X}K: X encrypted with key K [X]K: Message Authentication Code over X with key K. X(Y): Y carried with X protocol Kps: A symmetric key shared between peer and Server for signing (IK, provisioned by EAP/HOKEY hierarchy) and identified by KNps. KEps: A symmetric key shared between peer and Server for encryption (CK, provisioning by EAP/HOKEY hierarchy) and identified by KEpsid KEas: A symmetric key shared between authenticator and Server for encryption (provisioned out of band). Kas: A symmetric key between authentication and server for MDCs for signing (provisioned out of band). Nakhjiri Expires October 7, 2007 [Page 11] Internet-Draft A Handover Keying Hierarchy Description April 2007 Kpa: A symmetric key to be shared between peer and authenticator (key to be distributed to authenticator, the MDMSK in this document). The key is named as KNpa. KLx : Key lifetime for key x KNx: Key name for Key x, e.g. KENas: key name for KEas Nx : Nonce provided by the party X (PID,DAID, DID, Np), [PID, DAID, DID, Np]Kps is called the peer request token (PRT), which carries the identities of both peer and authenticator along with a signature. The signature is called the peer request authenticator (PRA). (PID, UAID, [PID, UAID]Kas) is called Authenticator_ID_token (AIT), which carries a signature, called Authenticator ID authenticator. {PID, AID, KNpa, KLpa, Kpa}KEas is called Authenticator_key_token (AKT), which carries the Kpa wrapped with KEas (encryption key shared between authenticator and server). KNpa, KLpa, KNps, [PID, AID, DID, Np+1,KNpa,KLpa, KNps]Kps is called Server_authorization_token (SAT). 5. Signaling using EAP-HR and AAA The exchange for key distribution to a 3th party after an initial two-party authentication was explained above. Our intention is to show that is possible to perform the 3-party key distribution exchange (KDE) with maximum 1 1/2 round trip and in most cases with 1 round trip by using an EAP method, called EAP-HR. The method simply consists of an EAP-HR request/response and completes with an EAP success. In cases where the EAP-HR request starts from the authenticator, the number of round trips is almost 1 (EAP-HR response + EAP Success), since the authenticator-peer trip time is negligible compared to server-peer trip time. in cases where EAP-HR request has to start from the server, the number of round trips would be 1 1/2. 5.1. signaling scenarios 5.1.1. Network setup scenario The network setup is the scenario when the peer is attempting to attach to the network for the first time. The assumption is that the peer performs an EAP mutual authentication with the EAP server at the home domain and establishes MSK and EMSK. A HOKEY compliant peer and Nakhjiri Expires October 7, 2007 [Page 12] Internet-Draft A Handover Keying Hierarchy Description April 2007 server peer will now follow the HOKEY key hierarchy, which provides per-authenticator keys (MDMSK) to the authenticator the peer is attaching through. A HOKEY compliant server, may be able indicate its compliance to the peer by setting the value session-life-time attribute to zero, when this attribute is communicated to the authenticator. In a typical deployment, authenticator keys and session life time are carried by the same AAA messages that carry the EAP success ([RFC3579] and [RFC4072]). This will trigger the authenticator to start the 3-party key distribution process (KDE) by sending an EAP-HR request. In cases, where sending trigger to the authenticator is not possible, the EAP-HR request needs to be initiated from the server, adding a 1/2 round trip to the exchange. However, this additional delay would not be critical since no peer applications has started yet. As one can see below, an EAP-HR request can be used to carry authenticator ID (DAID) and the domain identifier and can trigger the 3-party key distribution exchange (KDE) at the peer. The peer will create the PRT token and starts the KDE by sending the content of KDE message 1 as type data within EAP-HR response. The authenticator forwards the EAP-HR response within a AAA request message, while the contents of message 1 within the EAP attribute and the rest within AAA AVPs. The server after calculating the data required for KDE message 3 will include the data as explained earlier, party within the EAP-Success embedded within the AAA response messages and partly as AAA AVPs within the same AAA messsage. The AVPs will include an encrypted copy of the MDMSK calculated for the authenticator The authenticator extracts the AVPs and the EAP-Success message and forwards the EAP success message as described in KDE message 4 to the peer. Nakhjiri Expires October 7, 2007 [Page 13] Internet-Draft A Handover Keying Hierarchy Description April 2007 peer Authenticator server ----- -------- ------- | EAP-Authentication | | <--------------------------------------> | | EAP-Success (lifetime=0) | | <-----------------------------------------| |EAP-HR/Req (KDE 0) | | | <---------------| | | EAP-HR/Res (KDE 1 and 2) | | --------------------------------------> | | EAP-Success (KDE 3 and 4) | | <-----------------------------------------| Figure 2: Network Setup using EAP-HR 5.1.2. Authenticator handover and/or re-authentication scenarios Both authenticator handover and re-authentication scenarios can follow the same signaling process for the following reasons. In case of handover, the peer as a result of scanning process, detects the new point of attachment and the new authenticator and sends a request for attachment/ association to the new authenticator through the lower layer. This can trigger the EAP-HR process at the new authenticator (assuming reactive handover keying). In case of re- authentication, the authenticator based on its configuration state, or through lower layer request from the peer (if peer is aware that its keys are expiring) knows that the peer needs to extend its existing session and keys and thus can act based on internal triggers. peer Authenticator server ----- -------- ------- |EAP-HR/Req (KDE 0) | | | <---------------| | | EAP-HR/Res (KDE 1 and 2) | | --------------------------------------> | | EAP-Success (KDE 3 and 4) | | <-----------------------------------------| Figure 3: Handover using EAP-HR It should be noted that proactive signaling is desired and may be possible in some cases. Proactive signaling would mean the peer and/or authenticator start the acquisition of the MDMSK prior to completion of the link handover to the new authenticator. The 3 party process could only happen if the peer has a link with the new Nakhjiri Expires October 7, 2007 [Page 14] Internet-Draft A Handover Keying Hierarchy Description April 2007 authenticator (direct or indirect through the new or previous point of attachment). This is since the signaling needs to go through the new authenticator so that it can provide its own identity to the server. We do not discuss proactive keying in the current version of this document. 5.2. AAA and EAP extensions The intent is to use EAP signaling between the peer and server. However, as it is customary, the authenticator-server portion of EAP signaling is carried over a AAA protocol between the authenticator and the server. We do not go into the details of the choice the use of the AAA protocol and simply provide a generic description of the attribute value pairs (AVP) that are needed to accomplish the exchanges required for key derivation and distribution. 5.2.1. AAA AVPs This section provides a list of the new AVPs that may be required for the KDE. Authenticator_DID_AVP: Format to follow RADIUS attribute or Diameter AVP syntax. In Diameter, this may be part of a grouped attribute carrying the rest of peer request token information. This AVP is to carry the MDC ID (DAID) reported to the key generating server (HOKEY server) through the peer. Authenticator_UID_AVP: Format to follow RADIUS attribute or Diameter AVP syntax This AVP is to carry the MDC ID (UAID) reported to key generating server directly. A new Authenticator_UID_AVP may not be required since, the MDC may simply act as a NAS and thus the uplink identifier of the MDC is the same as the NAS_ID, which is a well- known RADIUS/ DIameter attribute. Domain_ID_AVP: Format to follow RADIUS attribute or Diameter AVP syntax This AVP is to carry the domain identifier used in generatio of domain specific keys. MDC_ID_AVP: Format to follow RADIUS attribute or Diameter AVP syntax Nakhjiri Expires October 7, 2007 [Page 15] Internet-Draft A Handover Keying Hierarchy Description April 2007 This AVP is to carry the MDC ID from the server to the peer in return AAA message. This is to indicate to the peer what ID was used by the server to generate the MDMSK. When MDC is the same as NAS, the well known NAS_ID can be used. Authenticator_ID_token_AVP: Format to follow RADIUS attribute or Diameter AVP syntax. This AVP is to carry the Authenticator_ID_token, which includes peer and authenticator uplink identities and a signature, signed by the authenticator (i.e. PID, UAID, [PID, UAID]Ka). In case of RADIUS, where grouped attributes may not be supported, the signature portion of the token needs to be carried as a separate attribute. Authenticator_KEY_AVP: Format to follow RADIUS attribute or Diameter AVP syntax. This AVP is to carry the Authenticator_key_token (AKT), including MDMSK from the server to the authenticator. In Diameter a grouped attribute can carry the entire Authenticator_key_token (i.e. Including the key name). When attribute grouping is not allowed (e.g. Current state of RADIUS attributes), information such as KLpa and KNpa need to be carried in separate attributes. 5.2.2. EAP-HR and EAP-HR Type data fields The following data chunks are to be carried by EAP-HR type signaling as EAP type data. They may be carried as part of type data for the new type EAP-HR, or for an EAP-Identity if the IETF decides to allow addition of type data to EAP Identity messaging. In the following we are going to follow the design based on the assumption of use of EAP-HR. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Subtype |KDE Data payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KDE Data payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: EAP-HR Request and Response packet formats Code: Nakhjiri Expires October 7, 2007 [Page 16] Internet-Draft A Handover Keying Hierarchy Description April 2007 1 and 2 for EAP-HR Request and Response 3 for EAP Success Identifier: in case of EAP-HR Requests and Responses is implemented as typical for EAP Request and response pairs. Flags: TBD Type X for EAP-HR (X to be assigned by IANA) Subtype: KDE data SubtypeTo indicate the type of KDE data 0 DID (used in EAP-HR Request and Response) 1 DAID (used in EAP-HR Request and Response) 2 PRT (Peer_Request_Token) used in EAP-HR Response Notes: KDE data stands for 3 party key distribution exchange data and is implemented as EAP-HR Type data (as is conventional for EAP methods) is defined as follows DID (Domain_ID): carrying the domain identifier required for key derivation. DAID (down link Authenticator ID) carrying the authenticator ID seen by the peer. PRT is to include (PID, DAID, Np,KNps), [PID, DAID, Np,KNps]Kps) from the peer to the authenticator and server. The proposed EAP-HR method terminates by an EAP-Success sent from the server to the peer through the authenticator. The proposal includes modification of the EAP Success message to carry additional data. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Type payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type payload +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nakhjiri Expires October 7, 2007 [Page 17] Internet-Draft A Handover Keying Hierarchy Description April 2007 Figure 5: Modified EAP-Success Code: 3 for EAP Success Identifier As typical for EAP success Type Type of data the EAP Success is carrying (it is possible to map the Type space to cover the EAP method types as well, i.e. Type 0-X as assigned for EAP methods by IANA Type X+1-254 for additional type of data to be carried by EAP Success. Here we assume type Y belongs to the allowed type space Y SAT (Sever_Authorization_token) SAT to include KNpa, KLpa, KNps, [PID, AID, Np+1,KNpa,KLpa, KNps]Kps carried from the server to the peer through the authenticator.. 5.2.3. backward compatibility with EAP For simplicity we call an entity (server or peer) that implements HOKEY, hokey-compliant. The same entity is "hokey incompliant" if it only supports EAP keying. A AAA server that implements HOKEY a HOKEY server. Hokey-compliant peer and server can use handover root key (HRK) to generate per-MDC keys (MDMSK). A "hokey compliant" server transports the MDMSK to the MDC/ authenticator. On the other hand, hokey- incompliant (legacy) peers and servers use MSK instead of both HRK and MDMSK. Authenticators may not require much change to comply with the new key hierarchy, except to be able to send EAP-HR if needed. It is also possible to use EAP identity Request/Response instead of EAP-HR to achieve the same effect, but assuming EAP identity messages can modified to carry type data. The other impact is that EAP Success will have to carry additional data, but the legacy authenticator should be oblivious to this, since authenticator will normally carry EAP Success to the peer and receives its own key material through AAA attributes (outside EAP Success) anyhow. When "hokey compliant" MDC and AAA server are dealing with a "hokey non-compliant" peer, the peer will simply not understand the EAP-HR request and responds accordingly, to which the HOKEY server responds by sending the MSK as done in EAP keying framework. However, the HOKEY server should through accessing user profile be able to tell whether the peer is hokey compliant or not. Nakhjiri Expires October 7, 2007 [Page 18] Internet-Draft A Handover Keying Hierarchy Description April 2007 6. Security report Card This section of the document provides a test of the provided key hierarchy against the security goals stated in the handover keying problem statement draft [I-D.nakhjiri-aaa-hokey-ps] Key Context and scope, prevention of domino effect: The context and scope for each key is clearly defined by including the identities of the parties that are to share the key and by including the purpose of the key in the key generation. Key Naming and freshness: All keying material starting from MDMSK and the derivatives are uniquely named, using the identity of the parties sharing the key. EAP session ID, when available can be used to provide freshness and key name uniqueness. However, since generation of EAP session ID is optional for many methods, we have opted for use of cryptographically generated key names using the freshness properties of the parent key. Authentication of all the parties: The key distribution mechanism, described provides authentication of all parties to each other. Channel binding: The key distribution mechanism proposed provides proper binding of the key to the parties that will use it. EAP method independence: The key hierarchy in this document stems from the EAP method generated keys (MSK and EMSK). As long as the method is capable of creating EMSKs, this hierarchy is method independent. 7. Security Considerations The key distribution mechanism described in this document relies on the a pre-established trust infrastructure that wraps and delivers the MDMSK from the server to the authenticator through the AAA architecture. Any vulnerabilities arising from AAA infrastructure insecurity, e.g. existence of transitive trust relationships will directly impact the security of this key delivery mechanism and thus the privacy of the peer, the network and their link. Furthermore, since the entire hierarchy is generated from the EMSK, using PRFs that are possibly dictated by network policy, the cryptographic strength of all such child keys will depend on the strength of the EMSK and the PRFs that are used. Furthermore, life time and caching of these keys are determined by the network policy and implementation and can introduce additional vulnerabilities and targets for attacks. Nakhjiri Expires October 7, 2007 [Page 19] Internet-Draft A Handover Keying Hierarchy Description April 2007 8. IANA consideration This document defines a new EAP method type, along with associated type data as well as number of new AAA AVPs. The values for these types and AVPs need to be assigned by IANA. It may also require a number of new Diameter command codes, if Diameter is used. In that case, allocation of new command codes needs to be done through IANA as well. 9. Acknowledgements The author would like to thank Jari Arkko for useful suggestions on generation of the handover key hierarchy and Mohan Parthasarathy and Hao Zhou for discussions and feedback. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-18 (work in progress), February 2007. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-03 (work in progress), June 2006. [I-D.ietf-hokey-reauth-ps] Clancy, C., "Handover Key Management and Re-authentication Problem Statement", draft-ietf-hokey-reauth-ps-01 (work in progress), January 2007. [I-D.ietf-hokey-emsk-hierarchy] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-00 (work in progress), January 2007. Nakhjiri Expires October 7, 2007 [Page 20] Internet-Draft A Handover Keying Hierarchy Description April 2007 [I-D.ohba-hokey-3party-keydist-ps] Ohba, Y., "Problem Statement and Requirements on a 3-Party Key Distribution Protocol for Handover Keying", draft-ohba-hokey-3party-keydist-ps-01 (work in progress), March 2007. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. 10.2. Informative references [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-09 (work in progress), February 2007. Appendix A. Appendix A: Support of handovers within a mobility domain (intra-authenticator handovers) This appendix intends to provide some suggestions on how to deploy the handover keying mechanisms within a typical wireless network architecture, where the authenticator is implemented inside an access gateway node that manages a mobility domain, consisting of a number of access nodes. The access nodes terminate the wireless link with the peer, but the mobility across many access nodes is managed by the same mobility domain controller (MDC). In such cases the MDMSK transported to the authenticator/MDC is used to create master keys (LSAP_MK) for the link security association protocol (LSAP) that is run between the peer and the AN to produce keys that secure the wireless link between the peer and AN. Again the goal is to provide each AN with its own LSAP_MK that is cryptographically separate from the LSAP_MK that may be provided to the neighbor ANs for dealing with the same peer during the same session. To reduce the handover latency, it is desired that the inter-AN handovers within the same mobility domain are handled at MDC level without interaction with the AAA or HOKEY server. However, since in many architectures, the MDC and ANs are physically disjoint, distribution of LSAP_MK to the AN from the MDC will suffer from the same 3-party key distribution issues as those discussed for MDMSK distribution. A similar approach can be applied to transport keys from the MDC to the AN. However the AAA protocols cannot be used in this case, since the MDC is a AAA client. Nakhjiri Expires October 7, 2007 [Page 21] Internet-Draft A Handover Keying Hierarchy Description April 2007 EMSK | HRK ________________|________________________________ | | | | | VHRK1 .. VHRKn HHRK CK IK _____________________|___________________......______ | | | | | HCK HIK MDMSK1 MDMSK2 MDMSKm ______________________|_________________________ | | | | MDC_CK MDC_IK LSAP_MK1 LSAP_MK2 Figure 6: A keying hierarchy to intra-authenticator handovers Author's Address Madjid Nakhjiri Huawei USA Email: mnakhjiri@huawei.com Nakhjiri Expires October 7, 2007 [Page 22] Internet-Draft A Handover Keying Hierarchy Description April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nakhjiri Expires October 7, 2007 [Page 23]