Network Working Group Q. Wu Internet-Draft Huawei Intended status: Standards Track K. Hoeper Expires: April 22, 2010 Motorola S. Decugis NICT G. Zorn Network Zen October 19, 2009 HOKEY Architecture Design draft-hoeper-hokey-arch-design-00 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." 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 April 22, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wu, et al. Expires April 22, 2010 [Page 1] Internet-Draft HOKEY Architecture Design October 2009 Abstract This document describes deployment scenarios of HOKEY architectures in the wireless environment. The design objectives and main components of HOKEY architecture are identified, and examples of how the EAP Re-authentication Protocol (ERP) can be integrated into a HOKEY architecture are discussed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Enhance deployment scalability . . . . . . . . . . . . . . 4 3.2. Lower communication overhead . . . . . . . . . . . . . . . 5 4. HOKEY Architecture Design . . . . . . . . . . . . . . . . . . 5 4.1. System Overview . . . . . . . . . . . . . . . . . . . . . 6 4.2. EAP based handover Key Management . . . . . . . . . . . . 7 4.2.1. Handover Key Derivation . . . . . . . . . . . . . . . 7 4.2.2. Handover Key Distribution . . . . . . . . . . . . . . 7 4.3. EAP Authentication . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Full ERP authentication . . . . . . . . . . . . . . . 7 4.3.2. Local ERP authentication . . . . . . . . . . . . . . . 7 4.3.3. Early EAP authentication . . . . . . . . . . . . . . . 7 4.4. Local Domain Name Discovery . . . . . . . . . . . . . . . 7 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 8 5.1. Scenario 1: Home Network HOKEY Service . . . . . . . . . . 8 5.2. Scenario 2: Visited network HOKEY Service . . . . . . . . 8 5.3. Scenario 3: Roaming Case . . . . . . . . . . . . . . . . . 9 6. ERP Integration with HOKEY Architecture . . . . . . . . . . . 9 6.1. Combine Full EAP Auth with Local ERP Auth . . . . . . . . 10 6.2. Combine Full ERP Auth with Local ERP Auth . . . . . . . . 11 6.3. Combine Local domain name discovery with Local ERP Auth . 12 7. HOKEY Authorization . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Wu, et al. Expires April 22, 2010 [Page 2] Internet-Draft HOKEY Architecture Design October 2009 1. Introduction The Extensible Authentication Protocol (EAP) defined in [RFC3748] is an authentication framework that supports different types of authentication methods which are defined in EAP methods. Originally designed for dial up connections, EAP is now commonly used for authentications in wireless access networks. To allow faster re- authentications of previously authenticated peers, the EAP Re- authentication Protocol (ERP) was defined in [RFC5296]. ERP supports two forms of bootstrapping, i.e., "implicit bootstrapping" and "explicit bootstrapping". Both forms of bootstrapping are used to derive EAP-based root keys for re-authentication and transport them to the local server that requested a root key for protecting re- authentication services to a peer. Thus, ERP can be directly performed between a peer and the local server this peer is attached to without the need to communicate with the peer's home server in the home domain. [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 complete all EAP related communication in prepartion for the Handover including AAA signaling before the mobile device moves. Both of these method-independent optimized authentication protocols enable fast inter-authenticator handovers. However, currently it is unclear how the necessary handover infrastructure is deployed and can be integrated into existing EAP infrastructures. In particular, it still needs to be defined where EAP re-authentication (ER) servers are placed in the network and how they can be integrated with the local as well as the home domain network to allow optmized communication overhead during handovers and better scalability. This document focuses on providing deployment scenarios of HOKEY architecture and HOKEY architecture design in the wireless environment. The design objectives for HOKEY architecture and main components of HOKEY architecture will be discussed, and examples of how ERP and early authentication can be integrated into HOKEY architecture will be taken into account. 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]. Wu, et al. Expires April 22, 2010 [Page 3] Internet-Draft HOKEY Architecture Design October 2009 In addition, the following terms are defined: Early Authentication Service Use of EAP by a mobile peer to establish authenticated keying material on a target attachment point prior to its arrival. Re-authentication Service Use of ERP by a mobile peer to make already existing keying material available to the target attachment point and use it for re-authentication during the handover. ER Server A logical entity that performs the server portion of ERP and may be co-located with an EAP or AAA server, see [RFC5296]. HOKEY Service Re-authentication service provided by the ER server to the peer or early authentication service provided by the EAP server to the peer. HkSh Home HOKEY Service Re-authentication service provided by the home server with ERP support in the home domain to the peer. Hksv Visited HOKEY Service Re-authentication service provided by the local server with ERP support in the visited domain of the peer. 3. Design Goals This section investigates the fundamental design goals for HOKEY architectures. The general goals for HOKEY architecture design are to enhance the deployment scalability and lower the complexity of signaling overhead. 3.1. Enhance deployment scalability Ideally, whenever a peer performs a handover, ERP can be 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. In order for this to work, ERP bootstrapping must occur Wu, et al. Expires April 22, 2010 [Page 4] Internet-Draft HOKEY Architecture Design October 2009 before (implicit) or during (explicit) a handover. Implicit bootstrapping requires the discovery of potential targets including, in case of inter-domain handovers, other local domain names. Explicit bootstrapping, on the other hand, requires the local ER server to contact the peer's home ER server. Note that these discovery capabilities cannot be provided by EAP and typically depend on lower layer announcements. Due to bootstrapping issues in inter- domain handovers, early authentication can be better suited for such handovers. In order to enhance deployment scalability and flexibility, upon entering a new domain, early authentication or re- authentication via ERP should be coupled with implicit ERP bootstrapping to enable seamless transition from inter-domain handovers to intra-domain handovers. 3.2. Lower communication overhead Full EAP exchanges or method specific re-authentication schemes (such as EAP-AKA's fast authentication) take at least two message round trips between a peer and its home EAP server. In order to achieve low latency handovers, there is a need for a method-independent re- authentication protocol that completes in less than two round trips, e.g., ERP takes only one round trip to complete. Ideally, no communication with the home EAP and ER servers should be necessary and instead a peer only communicates with a local servers. The authentication and authorization needs interaction with a central authority (such as an AAA server) in a domain in most cases. However the central authority may be placed far away from the mobile peer. In order to lower signaling exchange complexity, the communications with the central authority should be minimized as well. 4. HOKEY Architecture Design Wu, et al. Expires April 22, 2010 [Page 5] Internet-Draft HOKEY Architecture Design October 2009 4.1. System Overview +---------------------------------------------------------+ |HOKEY Architecture | | +-----------------------------+ | | |HOKEY Key Management | | |+-------------+ |+------------+ +------------+| | ||LDN Discovery|--->Handover Key| |Handover Key|| | |+-------------+ || Derivation | |Distribution|| | | |+------------+ +------------+| | | +-----/\------------------/\--+ | | || || | | || || | |+----------------------\/------+ || | || HOKEY Authen | || | || +--------------------------+ | +------\/-----------+| || |Full ERP Authentication | | |HOKEY Authorization|| || +--------------------------+ | | +---------------+ || || +------------------------+ | | |Local ER Server| || || |Local ERP Authentication| | | |authorization | || || +------------------------+ | | +---------------+ || || +-------------------------+ | +-------------------+| || |Early EAP Authentication | | | || +-------------------------+ | | ++------------------------------+-------------------------+ Figure 1 System Overview The HOKEY architecture is structured as three main EAP-based components, i.e., EAP based handover key management, HOKEY authentication using handover key and HOKEY authorization. The EAP based handover key management is focused on EAP method independent key derivation and distribution and comprises the following functional elements: o Handover key derivation o Handover key distribution The HOKEY authentication is focused on the inter-authenticator handover or inter-technology handover and comprises the following functional elements: o Full ERP authentication Wu, et al. Expires April 22, 2010 [Page 6] Internet-Draft HOKEY Architecture Design October 2009 o Local ERP authentication o Early EAP Authentication 4.2. EAP based handover Key Management 4.2.1. Handover Key Derivation Keying material is derived from the EMSK for inter-authenticator handover usage. 4.2.2. Handover Key Distribution The delivery of the EMSK child keys from the server holding the EMSK or a root key to another network server that requests a root key for providing protected services (such as re-authentication and other usage and domain-specific services) to EAP peers. Handover key distributions support two forms of bootstrapping, implicit ERP bootstrapping and explicit ERP bootstrapping. In both bootstrapping, the root key will be distributed from the home server to the local server. 4.3. EAP Authentication 4.3.1. Full ERP authentication It is full ERP exchange with the home ER server specified in the section 5.1 of [RFC5296]. The Local ER server should be present on the path of full ERP authentication and request DSRK from the home ER server. 4.3.2. Local ERP authentication Local ERP authentication is specified in section 3.2. It is ERP exchange with the local server without EAP method exchange. 4.3.3. Early EAP authentication EAP Early authentication defined in the [I-D.ietf-hokey-preauth-ps]. 4.4. Local Domain Name Discovery Learn local domain name via the lower layer (e.g., L2 or L3 announcement) or from the EAP-Initiate/ Re-auth-Start message. Wu, et al. Expires April 22, 2010 [Page 7] Internet-Draft HOKEY Architecture Design October 2009 5. Deployment Scenarios 5.1. Scenario 1: Home Network HOKEY Service In this scenario, the HOKEY peer and HOKEY Service are located in the home network. We refer to this set of services provided by the HOKEY server as HkSh. As shown in the figure 1, the HOKEY service can be located in the access network the HOKEY peer uses to connect to the home network, or it can be located elsewhere. +------------+ +======+ |Home Network| | HkSh | +------------+ +======+ / \ | | | | | | \ / +----------+ |HOKEY Peer| +----------+ Figure 1 Home Network HOKEY Service 5.2. Scenario 2: Visited network HOKEY Service In this scenario, the HOKEY peer is in the visited network and HOKEY services are provided by the visited network. We refer to this as HkSv as shown in Figure 2. +------------+ |Home Network| +------------+ / \ | | | | \ / +======+ +---------------+ | HkSv | |Visited Network| +======+ +---------------+ / \ | | | | | | \ / +----------+ |HOKEY Peer| +----------+ Figure 2 Visited network HOKEY Service Wu, et al. Expires April 22, 2010 [Page 8] Internet-Draft HOKEY Architecture Design October 2009 5.3. Scenario 3: Roaming Case In this scenario, the HOKEY Peer is located in the visited network and all HOKEY services are provided by both the home network and the visited network, as shown in Figure 4. +======+ +------------+ | HkSh | |Home Network| +======+ +------------+ / \ | | | | \ / +======+ +---------------+ | HkSv | |Visited Network| +======+ +---------------+ / \ | | | | | | \ / +----------+ |HOKEY Peer| +----------+ Figure 4 Roaming Case 6. ERP Integration with HOKEY Architecture Wu, et al. Expires April 22, 2010 [Page 9] Internet-Draft HOKEY Architecture Design October 2009 6.1. Combine Full EAP Auth with Local ERP Auth +----+ +----+ +----------------+ +----------+ +----+ |Prev| | New| | AAA Agent | |Home AAA | |Peer| |NAS | | NAS| |/Local ER Server| |Server/ | +-+--+ +-+--+ +-+--+ +-------+--------+ |EAP Server| | | | | +----+-----+ | | | | Transport DSRK | | | | | rMSK1 to Local | | Initial Full EAP|authentication | ER Server | |<------->|<-------+-------------->|<-------------->| | | Push rMSK1 | | | | to Prev NAS | | | | | | | | Local ERP authentication | | | /Discovery Local Domain Name | | |<------->| | | | | | | | | | Local|ERP authentication | | |<--------+------->|<------------->| | | | | Push rMSK2 | | | | | to New NAS | | | | | | | Figure 5 1. Implicit bootstrapping occurs in the initial full EAP execution when a peer first attaches to one domain or enters into a new domain. The bootstrapping is used to transport local root keys (e.g., DSRK) to the local ER server. 2. Suppose the serving NAS is aware of the local domain name of the target NAS, then local ERP can be used between the peer and the serving NAS to request this local domain name for the peer. In this case, it is out of the scope of this document how the serving NAS knows the local domain names. 3. When the peer moves to the target NAS, the peer uses the local domain name received from the serving NAS to perform ERP with the local ER server without involvement of the home EAP server. Wu, et al. Expires April 22, 2010 [Page 10] Internet-Draft HOKEY Architecture Design October 2009 6.2. Combine Full ERP Auth with Local ERP Auth +----+ +----+ +----------------+ +----------+ +----+ |Prev| | New| | AAA Agent | |Home AAA | |Peer| |NAS | | NAS| |/Local ER Server| |Server/ | +-+--+ +-+--+ +-+--+ +-------+--------+ |ER Server | | | | | +----+-----+ | | | | Transport DSRK | | Full ERP Auth with Home ER Server| rMSK1 to Local | | /Local Domain name Discovery | ER Server | |<------->|<---------------------->|<-------------->| | | Push rMSK1 | | | | to Prev NAS | | | Local ERP Authentication | | |<---------------->|<------------->| | | | | Push rMSK2 | | | | | to New NAS | | | | | | | Figure 6 1. Explicit ERP bootstrapping occurs in the initial full authentication with the home ER server when the peer firstly attaches to one domain or enters into a new domain. It is used to re-authenticate the peer in the home domain and transports the local root key to the local ER server. Also it is used to request the local domain name for the peer. 2. When the peer associates with the target authenticator, ERP in the local domain is used to re-authenticate the peer in the local domain. Wu, et al. Expires April 22, 2010 [Page 11] Internet-Draft HOKEY Architecture Design October 2009 6.3. Combine Local domain name discovery with Local ERP Auth +--------+ +----+ +------+ +---------+ +----------+ +----+ |Prev NAS| | New| |DHCP | |AAA Agent| |Home AAA | |Peer| |/DHCP | | NAS| |Server| |/Local | |Server/ | +-+--+ |Client | +-+--+ +--+---+ |ER Server| |ER Server | | +---+----+ | | +----+----+ +----+-----+ | | | | |Transport DSRK | | | | |rMSK1 to Local | Initial Full EAP|authentication |ER Server |<------->|<------------------------->|<----------->| | | Push rMSK1 | | | | to Prev NAS | | |DCHP Procedure | | | |/Local Domain Name Discovery | | |<------->|<-------------->| | | | | | | | | | Local ERP Authentication | | |<---------------->|<---------------->| | | | | Push rMSK2 | | | | | to New NAS | | | | | | | | Figure 7 1. Implicit bootstrapping occurs in the initial full EAP execution when the peer first attaches to one domain or enters into a new domain and is used to transport local root key to the local ER server. 2. DHCP procedure is used to request local domain name for the peer and compute re-authentication root keys. 3. When the peer moves to the target NAS and knows the local domain name, the peer uses this information to perform ERP with the local ER server without involvement of the home EAP server. 7. HOKEY Authorization TBD 8. Security Considerations TBD Wu, et al. Expires April 22, 2010 [Page 12] Internet-Draft HOKEY Architecture Design October 2009 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. 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. [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-preauth-ps] Wu, et al. Expires April 22, 2010 [Page 13] Internet-Draft HOKEY Architecture Design October 2009 Wu, Q., Ohba, Y., and G. Zorn, "EAP Early authentication problem statement", draft-ietf-hokey-preauth-ps-09 (work in progress), May 2009. [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 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 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 Wu, et al. Expires April 22, 2010 [Page 14] Internet-Draft HOKEY Architecture Design October 2009 Glen Zorn Network Zen 1310 East Thomas Street Seattle, Washington 98102 +1 (206) 377-9035 Email: gwz@net-zen.net Wu, et al. Expires April 22, 2010 [Page 15]