EAP Working Group M.Yanagiya INTERNET DRAFT H.Ohnishi Expires: April 2003 NTT Corporation Oct 2003 Service Authentication Architecture Using Extensible Authentication Protocol (EAP) Key Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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. Comments should be submitted to the eap@frascone.com mailing list. Table of Contents 1. Introduction 2. Terminology 3. Public roaming network service 3.1 Assumed network architecture 3.2 Requirement for network element (NE) and mobile node (MN) security 3.3 Existing technology for NE and MN security 3.4 Issues of existing technology 4. Proposed Dynamic Shared Key Authentication Architecture 5. Example of application 6. References 7. Author's Addresses Abstract In a public wireless Local Area Network (WLAN) access service using Yanagiya, et al. [Page 1] Internet Draft Service Authentication Using EAP Key Oct 2003 Mobile IP, network elements, such as access points, access routers, home agents and mobility anchor points, are required to authenticate the user to prevent unauthorized usage. Therefore, a mobile node needs to execute the authentication process many times to use the Mobile IP function. It will increase the connection delay. The connection delay can be reduced by using a preshared key as an authentication method. But it is necessary to share the symmetric secret key between network element (NE) and mobile node (MN) in advance. It is impossible for the MN to configure the key of all network elements in advance. In this document we discuss a secure access architecture using an Extensible Authentication Protocol (EAP) key as a shared key between NEs and an MN. 1.Introduction In a public wireless LAN (WLAN) access service, network elements (NEs), such as WLAN access points (APs) and access routers (ARs), will be shared by mobile nodes (MNs) that do not trust each other. In order to prevent unauthorized usage, APs is required to authenticate MNs. When an MN wants to use a Mobile IP (MIP) function, MN is also required to be authenticated with a mobility anchor point (MAP) and a home agent (HA). In addition to these authentication, in order to avoid spoofing router or service steal, a MN and a router need to verify Router Advertisement and Neighbor Advertisement message. Therefore, it is necessary to execute two or more authentication process. It may increase the connection delay, and user of MN is required to configure information for each authentication process. To improve user's convenience, it is necessary to establish an authentication architecture that can decrease connection delay and configuration. The processing time of PreShared Key (PSK) based authentication is shorter than Public Key Infrastructure (PKI) based. But, since the relation between MN and NW is changed along with the movement, it is difficult to share secret key in advance. 802.1x is used as the access authentication technology for APs. 802.1x allows MNs and Authentication, "Authorization and Accounting (AAA)" server to share a symmetric key called the "EAP Key", during the access authentication process. It seems to be reasonable to use the key as a symmetric key between MNs and NEs. In this document, we discuss the authentication architecture using the EAP key as a symmetric key between NEs and MNs. 2.Terminology Network Element (NE) a node that provide network service such as Home agent and Mobility Anchor Point Yanagiya, et al. [Page 2] Internet Draft Service Authentication Using EAP Key Oct 2003 Mobile Node (MN) Mobile IP mobile node as defined in [4,5] Access Router (AR) An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MNs. Access Point (AP) A radio transceiver by which a MN obtains Layer 2 connectivity with the wired network. 3.Public roaming network service 3.1. Assumed network architecture The public roaming network service provides a mobility function to public WLAN users by using Mobile IP. The assumed network architecture of a public roaming service network is illustrated in fig. 1. The network consists of a WLAN AP, AR, HA, and MAP. An MN is connected to the WLAN AP. These NEs are shared among MNs, which do not trust each other. +----+ +----+ | MN |------| AP |\ +----+ +----+ \ +----+ +-----+ +----+ | AR |---| MAP |---| HA | /+----+ +-----+ +----+ +----+ +----+ / | MN |------| AP | +----+ +----+ Figure 1: assumed network architecture of public roaming network service 3.2 Requirement for NE and MN security In order to avoid unauthenticated access and unauthorized usage, the following three authentication phases may be processed in a public roaming service network. 1) Access authentication Phase In order to avoid unauthenticated access, an AP must authenticate an MN when it requests access. 2) IPv6 address auto configuration phase Since APs provide only layer two functionality, an access link will be shared by MNs that access the same AP. In a public roaming service network, these MNs may not trust each other. This network environment is called "Multiaccess Link" described in [SEND-THREAT]. When MNs use the Neighbor Discovery Protocol (NDP) in a multiaccess link, because the destination addresses of the Router Solicitation and Neighbor Solicitation messages are multicast, any MN on the same link can receive these solicitation messages and send a false advertisement message. If an MN receives a false Router Advertisement Yanagiya, et al. [Page 3] Internet Draft Service Authentication Using EAP Key Oct 2003 or Neighbor Advertisement, it will obstruct normal IP communication. Therefore, it is necessary for ARs and MNs to verify Router Advertisement messages and Neighbor Advertisement messages. 3) Binding update phase After access authentication and IPv6 address auto configuration have been completed successfully, all MNs are able to send Binding Update messages to MAPs and HAs. To protect the integrity and authenticity of the Binding Updates, Mobile IPv6 must or may use IPsec security association between the mobile agents (HA and MAP) and the MN.[MIP] [HMIP] 3.3 Existing technology of NE and MN security The existing security technology is shown below. 1) Authentication technology for WLAN access point 802.1x is used to execute the access authentication at an AP. 802.1x uses the EAP and is able to carry authentication methods such as Transport Layer Security(TLS), Tunneled Transport Layer Security (TTLS), and Protected EAP, which allow MN and AAA to share a symmetric key during the authentication process. In general, an AAA sends the shared symmetric key to the AP, and the AP and the MN use it as a key to encrypt messages on the wireless network. 2) Authentication technology for access router NDP messages are protected by using Authentication Header, as defined in RFC 2461. However, Internet Key Exchange (IKE) is only capable of negotiating Security Associations (SAs) for unicast communications. It is difficult to use IPsec SAs for MNs which dynamically change ARs while moving. Therefore, Secure Neighbor Discovery Protocol(SEND), which uses certificates and public key encryption to achieve mutual authentication between an AR and an MN, is being discussed in the SEND Working Group. 3) Authentication technology for an MIP agent An MIP agent is used in IPsec SA as described in MIP. Since the relationship between HA and MN is static, HA and MN can use a manual SA configuration or execute IKE with a preshared key between them. However, the relationship between an MAP and an MN changes dynamically. As a result the SA between the MN and the MAP will be established using key establishment protocols such as IKE as described in [HMIP] 3.4 Issues of existing technology 3.4.1 Connection delay The authentic method is roughly divided into the PKI-based method and the PSK-based method. The PKI-based method uses a public key certificate to authenticate. Therefore, it is not necessary to share a secret key between the NEs and the MNs in advance. But the process Yanagiya, et al. [Page 4] Internet Draft Service Authentication Using EAP Key Oct 2003 to verify a certificate is complicated and it will require a longer time than a PSK-based method. Since it is assumed that a MN roams between not only APs but also networks, the trusted root of the certification agent may differ. When the trusted root differs, the MN and the NE must verify a certificate with a certification delegation chain, which may require more processing time. On the other hand, a PSK-based method is a simple process whose authentication processing time is said to be shorter than that of a PKI-based method in general. However, a symmetric key must be shared between NEs and MNs in advance. In a public roaming network service, the relationship between MNs and NEs changes dynamically. By using a PKI-based method, an MN and an NE authenticate without presetting individual authentication information. However, a longer time is needed to execute authentication, which increases the connection delay. In order to reduce connection delay, a PSK- based method seems to be suitable, but it is impossible for an MN to configure the symmetric keys of all NEs in a public network. Therefore, it is necessary to develop a new authentication architecture that solves the problem of an increase in processing time and encryption key presetting at the same time. During access authentication with EAP-TLS, EAP-TTLS and PEAP such as 802.1x and Protocol for carrying Authentication for Network Access (PANA), MN and Authentication, Authorization and Accounting (AAA) sever are able to share a symmetric key dynamically. In [PANA-BOOT], it is proposed that the shared EAP key is applied to bootstrap security association for Dynamic Host Configuration Protocol (DHCP) messages. So, we will apply the same concept to NEs and MNs in the public roaming service. 3.4.3 Authentication of Roaming MN In order to expand service area, Network Service Provider (NSP) allows MN to roam between NSPs. In authentication process of roamed MN, the AAA server of the foreign NSP behaves (AAA-F) as proxy, and the AAA server of home NSP or ISP (AAA-H) authenticates MN. AAA-F will permit the connection to own network according to the authentication result of the AAA-H. Thus, AAA-H is not required to manage the authentication information of roamed MNs. When NSP provide network service such as MIP, NEs in the foreign network is required to authenticate MNs. It may be achieved that NEs execute authentication process by using AAA-H. But, as the roaming network increases, NEs are required to configure information concerning AAA-H. 4. Proposed dynamic shared-key authentication architecture In this chapter, we discuss the PSK-based service authentication Yanagiya, et al. [Page 5] Internet Draft Service Authentication Using EAP Key Oct 2003 architecture which does not need symmetric key presetting between NEs and MNs. This service authentication architecture is achieved by using an EAP key. 4.1 Protocol overview In this section, we propose an architecture that allows NEs to authenticate an MN with a dynamic shared symmetric key by using 802.1x. When 802.1x is used as an access authentication technology with EAP-TLS, EAP-TTLS or PEAP, it allows an MN and an AAA to share a symmetric key during the authentication process. In general, the AAA sends the shared key to the AP when access authentication has been completed successfully. It makes possible the mutual authentication between the AP and MN, and encrypts the message that is transmitted on the radio. If an AAA sends the key to other NEs, it becomes possible for the NEs to use the symmetric key to authenticate the MN without presetting, for example, Figs. 2 to 4 depict examples of message flow. Figure 2 shows the example of message flow when an MN connects to an AP. When the access authentication has been successfully completed, the MN and AAA have shared a symmetric key, such as a Master Secret Key (MSK). In this architecture, the key will also be shared between NEs and the AAA. In this example, the shared key is stored in a key management database (Key-DB) once, and notifies NEs. Key-DB also manages the MN profile and the NE profile. The MN profile contains the kind of service that the MN has joined and the current logical location of the MN such as the IP address of the AP. The NE profile contains the IP addresses and logical locations of NEs. The Key-DB selects the target NE by using these profiles. MN AP NE AAA Key-DB Message |<---->| | | | MN associates with AP |<------------------>| | 802.1x authentication process |<-------------------| | AAA sends gaccess accepth | |------------>| | AP sends "accounting request | | | | | " | | | |----->| AAA request to Key-DB to | | | | | store the shared key | | | |<-----| ACK | |<------------| | AAA replies Accounting ACK | | |<------------| Key-DB pushes the shared key identifier of MN Figure 2: Message flow (connection phase) Figure 3 shows an example of message flow when an MN disconnects from an AP. When an MN sends a disconnect message or a timeout has occurred, the AP sends an Accounting Stop message to an AAA. The AAA Yanagiya, et al. [Page 6] Internet Draft Service Authentication Using EAP Key Oct 2003 requests that the Key-DB delete the key, and the Key-DB requests that NEs delete the key. MN AP NE AAA Key-DB Message |<---->| | | | MN disassociates with AP | |------------>| | AP sends "accounting request | | | | | " | | | |----->| AAA request Key-DB to | | | | | delete key | | | |<-----| ACK | |<------------| | AAA replies ACK | | |<------------| Key-DB request NE to delete key Figure 3 Message flow (disconnect phase) Figure 4 shows an example of message flow when an MN handoff occurs from AP1 to AP2. In this example, AP1 is connected to NE1 and AP2 is connected to NE2. When an MN disconnects from AP1, the key deletion process described in Fig. 3 is executed. The key registration process described in Fig. 2 is continuously executed. MN AP1 AP2 NE1 NE2 AAA Key-DB Message |<--->| | | | | | MN disassociates with AP1 |<--------------------------->| | 802.1x | |---------------------->| | AP sends "accounting | | | | | | | request " | | | | | |----->| AAA requests Key-DB to | | | | | | | delete key | | | | | |<---- | ACK | |<----------------------| | AAA replies ACK | | | |<-----------------| Key-DB request NE to delete key |<--------->| | | | | MN associates with AP2 |<--------------------------->| | 802.1x | | |<----------------| | AAA sends "access accept" | | |---------------->| | AP sends | | | | | | | "accounting request " | | | | | |----->| AAA requests Key-DB to | | | | | | | store the shared key | | | | | |<-----| ACK | | |<----------------| | AAA replies ACK | | | | |<-----------| Key-DB pushes the shared | | | | | | | key and identifier of MN Figure 4 Message flow (MN handoff from AP1 to AP2) Yanagiya, et al. [Page 7] Internet Draft Service Authentication Using EAP Key Oct 2003 4.2 MN Consideration To share a symmetric key with AAA during authentication process, MN must use 802.1x that uses TLS, TTLS, PEAP, etc as EAP method. When MN execute service authentication with NEs, MN use MSK or Temporary Session Key (TSK) which is derived from MSK by using a method such as described in [EAP-KEY-MULTI]. In order to execute service authentication process by using MSK or TSK, MN must select the key by using the identifier of NE. If the identifiers change dynamically such as the IP address of an AR or MAP, the MN may obtain the IP address from Route Advertisement or DHCP. If the identifiers do not change such as "Home Address" or "User Name", MN will be able to be configured in advance. When the MN completed access authentication successfully, it stores the relationship between the identifier of the NE and the shared key in its own device. And when an MN wants to execute service authentication with NE, MN will select the key by using the identifier of NE. 4.3 AAA and Key-DB Consideration To derive a symmetric key with a MN during the authentication process, an AAA must use 802.1x which uses TLS, TTLS, and PEAP as EAP methods for access authentication. To provide the key to NEs later, an AAA must manage the relationship between the identifier of the MN and the key. During access authentication with 802.1x, AAA can get two identities from the RADIUS attribute. These are "User name" and "MAC address of the MN" which are obtained from "User-Name" and "Calling-Station-Id"[RADIUS-1X]. If the MN is assigned a Home Address, AAA will be able to manage the relationship between the MN and the Home Address in advance. There are two ways in which the AAA provides the key to NEs. One way is push, the other is pull. The operation of each type is shown as follows. For both types, it is assumed that a secure association has already been established by using a preset configuration. 1) Push key providing method For the push key providing method, the AAA pushes the key and the identifier of the MN to the NEs when access authentication is successfully completed. In order to select suitable NEs, the AAA needs to manage the MN and NE profiles. The MN profile contains the current logical location of the MN and the kind of service that the MN has joined. When the MN has connected to the AP, the current logical location of the MN is dynamically set by using a RADIUS attribute such as an "Network Access Server (NAS)-IP-Address". The kind of service is statically configured when the MN is contacted. In the NE profile, the IP address of the NE and the network prefix is assigned to MNs that connect to the NE. The AAA selects suitable NEs, by mapping the current location of an MN by its network prefix and by using its network service type. Yanagiya, et al. [Page 8] Internet Draft Service Authentication Using EAP Key Oct 2003 2) Pull key providing method For the pull key providing method, NEs require an AAA to send the key when NEs have received an access request such as the initiation message of IKE from an MN. The key-request message must contain the identifier of the MN to allow the AAA to select the key. The way to obtain the identifier from an access request message is described in section 4.4. Since the AAA only replies to the key-request message, the AAA only has to manage the relationship between the identifier of the MN and the shared key. 4.4 NEs Consideration When an NE uses the pull key providing method, it must select a key from the local database or acquire the key from an AAA to share a symmetric key with a MN dynamically. To require the key corresponding to an MN, it is necessary that an NE obtain the identifier of a MN during the service authentication process. 5. Example of application In this chapter, we discuss examples of applying the proposed authentication architecture to Neighbor Discovery Protocol. 5.1. Neighbor Discovery with EAP Key In [SEND], it is defined that MNs and ARs use PKI based authentication method to verify advertisement message. MNs can use this method to prevent spoofing. Since SEND use certification based method, the connection delay may be increased. In public WLAN access network, MNs which connect same AP share a link. In order to avoid spoofing routers, user traffic should be separated in each AP by using VLAN or physical link, and APs do not permit the communication between MNs which connect same MN. In such a network environment, only ARs verify the Neighbor Advertisement message from MN. Then, we propose the method to use the shared key during access authentication. Fig.5 shows the example of message flow. When the MN and AAA have shared a symmetric key, such as a Master Secret Key (MSK), the access authentication has been successfully completed. In the proposed architecture, the key will also be shared between NEs and the AAA. In this example, the shared key is stored in a key management database (Key-DB) once, and notifies NEs of the update time of the database. Key-DB also manages the MN profile and the NE profile. The MN profile contains the kind of service that the MN has joined and the current logical location of the MN such as the IP address of the AP. The NE profile contains the IP addresses and logical locations of NEs. The Key-DB selects the target NE by using these profiles. Yanagiya, et al. [Page 9] Internet Draft Service Authentication Using EAP Key Oct 2003 In this example, the authentication process execute by using challenge and response. The AR sends Neighbor Solicitation message with a "challenge". The MN responds with a value calculated using a "one-way hash" function. The AR checks the response against its own calculation of the expected hash value. If the values match, the AR generate interface ID by using EUI-64 and verify it with interface ID of target IP address. If these values match, AR adds the MAC address to neighbor cache entry. MN AP AR AAA Key-DB Message |<---->| | | | MN associates with AP |<------------------>| | 802.1x authentication process |<-------------------| | AAA sends "access accept" | |------------>| | AP sends "accounting request | | | | | " | | | |----->| AAA request to Key-DB to store | | | | | the shared key | | | |<-----| ACK | |<------------| | AAA replies Accounting ACK | | |<------------| Key-DB pushes the shared key | | | | | identifier of MN | | | | | |<----------->| | | IPv6 Address auto configuration |<------------| | | AAA sends Neighbor Solicitation | | | | | MN> | | | | | with "challenge" * | | | | MN calculate "response" with | | | | | shared key |------------>| | | MN send Neihbor Solicitation | | | | | with "responce" | | * | | AR verifies "response" with | | | | | shared key | | | | | Figure 5 Message flow (Neighbor solicitation and advertisement) 5.2 Identifier management In order to select the key, both the AR and AAA need to be able to manage the relationship between the identifier of the MN and the key. AR uses the MAC address included in ICMP Option of Neighbor Advertisement [NDP]. AAA server is able to obtain MAC address of MN during access authentication process, because "Calling-station- Id" includes MAC address of MN [RADIUS-1X] . Thus AAA and AR can use MAC address as identifier. Yanagiya, et al. [Page 10] Internet Draft Service Authentication Using EAP Key Oct 2003 6. References [SEND-THREAT] Kempf, J, Nordmark, E,"IPv6 Neighbor Discovery trust models and threats", draft-ietf-send-psreq-04,October 15, 2003 [MIPv6] Johnson, D., Perkins, C., Arkko, J.,"Mobility Support in IPv6",draft-ietf-mobileip-ipv6-24.txt,June 30, 2003 [HMIP] Soliman, H.,"Hierarchical Mobile IPv6 mobility management (HMIPv6)",draft-ietf-mobileip-hmipv6-08.txt,June, 2003 [PANA-BOOT] Tschofenig, H.,"Bootstrapping RFC3118 Delayed authentication using PANA",draft-tschofenig-pana-bootstrap-rfc3118-00.txt,June 2003 [EAP-KEY-MULTI] Salowey, J., Eronen, P.,"EAP Key Derivation for Multiple Applications",draft-salowey-eap-key-deriv-01.txt,June 2003 [RADIUS-1X] "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines",RFC3580 [NDP] "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461 7. Author's Addresses Mayumi Yanagiya Hiroyuki Ohnishi NTT Corporation 3-9-11 Midori-cho, Musashino-shi Tokyo, Japan Email: yanagiya.mayumi@lab.ntt.co.jp ohnishi.hiroyuki@lab.ntt.co.jp Yanagiya, et al. [Page 11]