Network Working Group Q. Wu Internet-Draft Huawei Intended status: Standards Track K. Hoeper Expires: April 29, 2010 Motorola S. Decugis NICT G. Zorn Network Zen October 26, 2009 HOKEY Architecture Design draft-hoeper-hokey-arch-design-01 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 29, 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 29, 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. Minimized Communications with Home Servers . . . . . . . . 4 3.2. Integrated Local Domain Name (LDN) Discovery . . . . . . . 5 4. HOKEY Architecture Design . . . . . . . . . . . . . . . . . . 5 4.1. System Overview . . . . . . . . . . . . . . . . . . . . . 6 4.2. Local Domain Name (LDN) Discovery . . . . . . . . . . . . 7 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 5.1. Scenario 1: Peer attached to home network, ER server in home network . . . . . . . . . . . . . . . . . . . . . 7 5.2. Scenario 2: Peer attached to visted network, ER server in visited network . . . . . . . . . . . . . . . . . . . . 8 5.3. Scenario 3: Peer attached to visited network, ER server in home and visited network . . . . . . . . . . . . 9 6. ERP Integration with HOKEY Architecture . . . . . . . . . . . 10 6.1. Combine Full EAP Auth with Local ERP Auth . . . . . . . . 11 6.2. Combine Full ERP Auth with Local ERP Auth . . . . . . . . 12 6.3. Combine Local Domain Name Discovery with Local ERP Auth . 13 7. HOKEY Authorization . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Wu, et al. Expires April 29, 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 all EAP-related communications in preparation 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 how EAP re-authentication (ER) servers should be integrated into local as well as home domain networks to allow optmized signalling overhead during handovers as well as better scalability. This document focuses on different deployment scenarios of HOKEY architectures 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]. In addition, the following terms are defined: Wu, et al. Expires April 29, 2010 [Page 3] Internet-Draft HOKEY Architecture Design October 2009 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 not necessarily be co-located with, or physically part of, a full EAP 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/ER server to the peer. HkSh Home HOKEY Service Re-authentication service or Early authentication service provided by the home server with ERP support in the home domain to the peer. HkSv Visited HOKEY Service Re-authentication service or Early authentication service provided by the local server with ERP support in the visited domain of the peer. 3. Design Goals This section investigates design goals for HOKEY architectures that help lowering the signalling overhead of re-authentications. 3.1. Minimized Communications with Home Servers ERP requires only one rountrip, however, this rountrip may contain 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 rountrip may introduce long delays because home ER and home AAA servers may be far removed. In order to lower Wu, et al. Expires April 29, 2010 [Page 4] Internet-Draft HOKEY Architecture Design October 2009 the signalling overhead, any communication with home ER and home AAA server should be minimized. Ideally, a peer should only need to communicates with local servers and other local entities. 3.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. In order for this to work, ERP bootstrapping must occur before (implicit) or during (explicit) a handover to tranport the necessary re-authentication root keys to the respective local ER server. Implicit bootstrapping is preferable because it does not require the communication with the home ER server during the 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 way for a 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 it is currentlty the case. 4. HOKEY Architecture Design Wu, et al. Expires April 29, 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 | |[HOKEY Authorization]| | || +------------------------+ | | +---------------+ | | || |Full ERP Authentication | | | |Local ER Server| | | || +------------------------+ | | |authorization | | | || +------------------------+ | | +---------------+ | | || |Local ERP Authentication| | +---------------------+ | || +------------------------+ | | || +------------------------+ | | || |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 optionally HOKEY authorization. The EAP-based handover key management consists of EAP method independent key derivation and distribution and comprises the following functional elements: o Handover key derivation o Handover key distribution The derivation and distribution of handover keys are defined in [RFC5295] and [I-D.ietf-hokey-key-mgm], respectively. The HOKEY authentication is focused on the inter-authenticator handover or inter-technology handover and comprises the following functional elements: Wu, et al. Expires April 29, 2010 [Page 6] Internet-Draft HOKEY Architecture Design October 2009 o Full ERP authentication o Local ERP authentication o Early EAP Authentication ERP is defined in [RFC5296] and the early EAP authentication problem is described in [I-D.ietf-hokey-preauth-ps]. HOKEY authorization is optional and can be used to verify whether a local ER server is authorized to advertize 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]. 4.2. 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. 5. Deployment Scenarios 5.1. Scenario 1: Peer attached to home network, ER server in home network This scenario concentrates on the non-roaming case. In this scenario, the HOKEY peer is attached to its home network which supports HOKEY service, as show in Figure 2. In the home network, the ER server can be collocated with the EAP Server or separated from the EAP Server. The NAS is on the path between the HOKEY peer and EAP/ER server. When the NAS is on the path between the HOKEY peer and DHCP Server, it acts as DHCP relay. Wu, et al. Expires April 29, 2010 [Page 7] Internet-Draft HOKEY Architecture Design October 2009 +----------+ +---------+ +------+ |EAP Server| |ER Server| | DHCP | +---/\-----+ +---/\----+ |Server| || || +------+ || || A ||_____________|| | -------/\-------- | ||+======+ | ||| HkSh | | ||+======+ | +--||--+ | | NAS |---------------| Home Network +------+ -------------- /\ ------------------------- || || \/ +----------+ |HOKEY Peer| +----------+ Figure 2 Home HOKEY Service(HkSh) 5.2. Scenario 2: Peer attached to visted network, ER server in visited network In this scenario, the HOKEY peer is located in the visited network and moves between NASs while the HOKEY services are provided by the local ER server in the visited network. We refer to this as HkSv as shown in Figure 3. The home EAP server located in the home network exports EAP-based root keys for handovers through full EAP exchanges and distributes them to local ER servers in the visited network. The DHCP Server locating in the visited network may provide local domain name discovery to the local ER server and to the HOKEY peer. Wu, et al. Expires April 29, 2010 [Page 8] Internet-Draft HOKEY Architecture Design October 2009 +-----------+ | Home | | EAP Server| +----/\-----+ || Home Network || -------------- || ------------------------- Visited network || +---------------+ | EAP Proxy/ |---- |Local ER Server| || +---------------+ || || +------+ || +======+ || | DHCP | || | HkSv | || |Server| || +======+ || +------+ || || A A || || | | || +-------+ | | +-------+ | Prev |<---- ---->| NEW | | NAS | | NAS | +-------+ +--/\---+ ------> || || +----------+ || |HOKEY Peer|----- +----------+ Figure 3 Visited HOKEY Service(HkSv) 5.3. Scenario 3: Peer attached to visited network, ER server in home and visited network In this scenario, the HOKEY Peer is attached to a visited network and moves from previous NAS to the new NAS. All HOKEY services are provided by both the home network and the visited network, as shown in Figure 4. Therefore it is referred as hybrid case. The Home ER Server can be collocated with Home EAP Server or separated from the home EAP Server in the home network. The local ER Server can be collocated with EAP proxy or separated from EAP proxy in the visited network. Wu, et al. Expires April 29, 2010 [Page 9] Internet-Draft HOKEY Architecture Design October 2009 +----------------+ |Home EAP Server/| |Home ER Server | +-------/\-------+ || +======+ || | HkSh | Home Network || +======+ -------------- || ------------------------- Visited network || +---------------+ | EAP Proxy/ |---- |Local ER Server| || +======+ +---------------+ || | HkSv | || || +======+ || || +-------+ +-------+ | Prev | | NEW | | NAS | ------> | NAS | +-------+ +--/\---+ || || +----------+ || |HOKEY Peer|----- +----------+ Figure 4 Home and Visited HOKEY service 6. ERP Integration with HOKEY Architecture Wu, et al. Expires April 29, 2010 [Page 10] Internet-Draft HOKEY Architecture Design October 2009 6.1. Combine Full EAP Auth with Local ERP Auth +----+ +----+ +----------------+ +----------+ +----+ |Prev| | New| | EAP Proxy | |Home EAP | |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 | | | /LDN Discovery | | |<------->| | | | | | | | | | 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 29, 2010 [Page 11] Internet-Draft HOKEY Architecture Design October 2009 6.2. Combine Full ERP Auth with Local ERP Auth +----+ +----+ +----------------+ +----------+ +----+ |Prev| | New| | EAP Proxy | |Home EAP | |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 first 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 29, 2010 [Page 12] Internet-Draft HOKEY Architecture Design October 2009 6.3. Combine Local Domain Name Discovery with Local ERP Auth +--------+ +----+ +------+ +---------+ +----------+ +----+ |Prev NAS| | New| |DHCP | |EAP Proxy| |Home EAP | |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 | | | |/LDN 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 29, 2010 [Page 13] 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 29, 2010 [Page 14] 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 29, 2010 [Page 15] Internet-Draft HOKEY Architecture Design October 2009 Glen Zorn Network Zen 1310 East Thomas Street Seattle, Washington 98102 USA Email: gwz@net-zen.net Wu, et al. Expires April 29, 2010 [Page 16]