EAP WG M. Yanagiya Internet Draft H. Ohnishi Document: draft-yanagiya-eap-saa-02.txt NTT Expires: August 21, 2005 February 21, 2005 Service Authentication Architecture Using Extensible Authentication Protocol (EAP) Key Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 August 14, 2005. Abstract In a public wireless local area network (WLAN) access service using Mobile IP, network elements (NEs), such as access points (APs), DHCP server (DHCPS) and home agents (HAs), are required to authenticate users to prevent unauthorized usage. In this document, we discuss authentication/authorization process using Extensible Authentication Protocol (EAP) key derived during access authentication. Conventions used in this document M.Yanagiya Expires - 21August 2005 [Page 1] draft-yanagiya-eap-saa-02.txt Feb.2004 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 RFC-2119 [i]. Table of Contents 1. Introduction..................................................2 2. Terminology...................................................2 3. Assumed network architecture..................................3 4. Service authentication architecture using EAP key.............3 4.1. Overview.................................................3 4.2. MN considerations........................................5 4.3. AAA considerations.......................................5 4.4. NE considerations........................................6 5. Security Consideration........................................6 6. IANA Consideration............................................6 7. Informative References........................................6 Author's addresses................................................6 Appendix-A Authentication of Binding Updates......................7 1. Introduction In a public wireless LAN (WLAN) access service, network elements (NEs), such as WLAN access points (APs) and DHCP servers (DHCPSs) and home agent (HA) will be shared by mobile nodes (MNs) that do not trust each other. To prevent unauthorized usage, these NEs must authenticate MNs. Access authentication based on EAP, such as 802.1x or PANA, may be used as the access authentication technology. These authentication technologies allow MNs and an AAA server to share a symmetric key (EAP-key) during the access authentication process. Thus, we proposed an authentication architecture using an EAP-key as a symmetric key between NEs and MNs. 2. Terminology Network Element (NE) A node that provides network services such as home agents. Mobile Node (MN) A node that can change its point of attachment from one link to another, while remaining reachable via its home address. Access Point (AP) A radio transceiver by which an MN obtains layer-2 connectivity with a wired network. M.Yanagiya Expires - 21August 2005 [Page 2] draft-yanagiya-eap-saa-02.txt Feb.2004 3. Assumed network architecture The assumed network architecture is illustrated in Figure 1. The assumed network provides mobility functions to public WLAN users by using Mobile IP. And MN will be configured some parameters by using DHCP. The network consists of APs, ARs, DHCPSs and HAs. MNs are connected to APs. These NEs are shared by the MNs connected to the network, which do not trust each other. MN, AP and AAA server support authentication technology based on EAP, such as 802.1x. DHCPSs and HAs do not support EAP. We assumed that security association is pre- set between NEs and AAA server. +----+ +----+ +-----+ | MN |<-radio->| AP |\ +-------| AAA | +----+ +----+ \ | +------+ : \+-------+ | : | AR | +------+ : /|(DHCPS)|---| (HA) | +----+ +----+ / +-------+ +------+ | MN |<-radio->| AP |/ : +----+ +----+ Figure 1: Assumed network architecture 4. Service authentication architecture using EAP key. 4.1. Overview 4.1.1 Protocol overview In this section, we describe an architecture that allows NEs to authenticate MNs by using a symmetric key derived during access authentication. EAP based access authentication technology allow MN and AAA server to share a symmetric key during the access authentication process. In general, the AAA server sends the shared key to the AP (EAP Authenticator) when access authentication has been completed successfully. This enables the mutual authentication between the AP and MN and encrypts the message transmitted with a radio signal. When the AAA server sends the key to other NEs, it allows them to use the symmetric key for service authentication without presetting. Figure 2 shows an example of the message flow. When access authentication has been successfully completed, the MN and AAA server have shared a symmetric key, such as a MSK, EMSK or AAA-key. In this example, the shared key is stored in the AAA server once, and NEs then request it to send the key when they receive Authentication Request messages from the MN. After sharing symmetric key derived M.Yanagiya Expires - 21August 2005 [Page 3] draft-yanagiya-eap-saa-02.txt Feb.2004 from EAP key, MN and NE can execute service authentication/authorization process with the key. MN AP NE AAA | | : | | 802.11 | : | |[association] | : | |<-------------->| : | | | : | | 802.1x | : | | Authentication | : | | Request | RADIUS or DIAMETER | | | [Authentication Request] | |--------------->|------------------------->| | | : | : : : : +-------------+ | : +-------------+ |derive | | : |derive | |Symmetric Key| | : |Symmetric Key| +-------------+ | : +-------------+ | | : | : : : : | | RADIUS or DIAMETER | | | [success] : | | |<-------------------------| | | : | | +------------+ : | | |Logical Port| : | | | Open | : | | +------------+ : | | | | | | Service Authentication | | | Request | | |----------------------------->| | | | | Key-Request| | | |----------->| | | | | | | | Send Key | | | |<-----------| | | | | | | +-------------+ | | | |Authorization| | | | |MN with key | | | | +-------------+ | | | | | | Service Authentication | | | Reply | | |<-----------------------------| | | | | | M.Yanagiya Expires - 21August 2005 [Page 4] draft-yanagiya-eap-saa-02.txt Feb.2004 Figure 2: Message flow in the secure access architecture 4.1.2 Key for service authentication When the authentication process executes by using a shared key, it is desirable that the key be different for each NE or application. It is also desirable that these keys be cryptographically separate. 4.1.3 Key Distribution There are two ways in which the AAA server distributes the key to NEs: "push" and "pull". The operation of each type is described as follows. In this document, the protocol which used between NEs and AAA server is out of scope. 1) Push For the "push" key distribution method, the AAA server pushes the key and the MN's identifier to the NEs when access authentication is successfully completed. To select suitable NEs for the MN, the AAA server must manage the profiles of the MN and NEs. The MN's profile contains its current logical location and the kind of service that it has joined. (e.g. When the MN has connected to the AP, its current logical location is dynamically set by using a RADIUS/DIAMETER attribute, such as a "Network Access Server (NAS)-IP-Address".) In an NE's profile, its logical location, based on information such as a network prefix or IP address, is managed. Thus, the AAA server can select suitable NEs by mapping their current logical locations and that of the MN. And AAA server can execute service authorization according to the MN's profile. 2) Pull For the "pull" key distribution method, NEs require the AAA server to send the key when NEs received service request messages, such as an initiation message for IKE from an MN. The key request message must contain the MN's identifier, to enable the AAA to execute service authorization and to select the appropriate key. Since the AAA server only replies to the key request message, it only has to manage the relationship between the identifier of the MN and the shared key. (Appendix-A shows an example of message flows.) 4.2. MN considerations To share a symmetric key with an AAA server during the authentication process, an MN must employ EAP-based access authentication, such as 802.1x or PANA. To share a symmetric key dynamically, an MN must support the key derivation function. 4.3. AAA considerations M.Yanagiya Expires - 21August 2005 [Page 5] draft-yanagiya-eap-saa-02.txt Feb.2004 To derive a symmetric key with an MN during the access authentication process, an AAA server must employ EAP-based access authentication, such as 802.1x or PANA. To share symmetric keys dynamically, an AAA server must support the key derivation and distribution function. 4.4. NE considerations To share a symmetric key dynamically, an NE must support the key distribution function described in 4.1.3. 5. Security Consideration [IBD] 6. IANA Consideration [TBD] 7. Informative References [RFC3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC3775, June, 2004 [ID-EAP-KEY-04] B.Aboba, D. Simon, J.Arkko, P,Eronen, H,Kevkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-04.txt, November 14, 2004 Author's addresses Mayumi Yanagiya NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi Tokyo, Japan Phone: 81-422-5967893 Email: yanagiya.mayumi@lab.ntt.co.jp Hiroyuki Ohnishi NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi Tokyo, Japan Phone: 81-422-594132 Email: ohnishi.hiroyuki@lab.ntt.co.jp 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 M.Yanagiya Expires - 21August 2005 [Page 6] draft-yanagiya-eap-saa-02.txt Feb.2004 made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Appendix-A Authentication of Binding Updates In [MIPv6], it is specified that an MN and a Mobility Agent, such as an HA or MAP, should use an IPsec SA when the Binding Update process is executed. In this section, we specify how an MN establishes an IPsec SA in the proposed architecture. An application example for a Binding Update is shown in Figure 5. MN Mobility Agent AAA M.Yanagiya Expires - 21August 2005 [Page 7] draft-yanagiya-eap-saa-02.txt Feb.2004 | | | | | | | share EAP-key during access authentication | |<------------------------------------------------------->| | | | | | | |IKE | | |[HDR, SA, KE, Ni, IDii] | Key-REQUEST| |----------------------->| [Auth-Request-Type=| | | AUTHORIZATION_ONLY],| | | [NAS-Identifier =IDir],| | | [User-Name= IDii]| | |------------------------------->| | | | | | +-----------+ | | |select EMSK| | | +-----------+ | | | | | +-----------+ | | |derive TSK | | | +-----------+ | | | | | Key-Answer | | | [Result-Code=DIAMETER_SUCCESS],| | | [Transient-Session-Key=TSK]| | |<-------------------------------| | +-----------------+ | | |calculate SKEYIDs| | | +-----------------+ | | | | | +----------------+ | | |calculate HASH_R| | | +----------------+ | |IKE | | |[HDR, SA, KE,] | | | Nr, IDir,HASH_R] | | |<-----------------------| | | | | +----------+ | | |derive TSK| | | +----------+ | | | | | +-----------------+ | | |calculate SKEYIDs| | | +-----------------+ | | | | | +----------------+ | | |calculate HASH_I| | | +----------------+ | | M.Yanagiya Expires - 21August 2005 [Page 8] draft-yanagiya-eap-saa-02.txt Feb.2004 |IKE [HDR, HASH_I] | | |----------------------->| | | | | Fig. A1: Application example for establishing an ISAKMP SA for BU M.Yanagiya Expires - 21August 2005 [Page 9]