EAP Working Group Mayumi. Yanagiya Internet Draft Hiroyuki. Ohnishi Document: draft-yanagiya-eap-saa-01.txt NTT Expires: August 17,2004 February 16,2004 Service Authentication Architecture Using Extensible Authentication Protocol (EAP) Key Status of this Memo This document is an Internet-Draft and is in full conformance with 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. Abstract In a public wireless local area network (WLAN) access service using Mobile IP, network elements (NEs), such as access points, access routers, home agents (HAs), and mobility anchor points (MAPs), are required to authenticate users to prevent unauthorized usage. Therefore, a mobile node (MN) must execute the authentication process many times in order to use Mobile IP functionality. This has the effect of increasing the connection delay. The delay can be reduced by employing a symmetric key as an authentication method, but it then becomes necessary to share the symmetric key among network elements, such as HAs or MAPs, and the MN, in advance. It is impossible for an MN to configure the keys of all NEs 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. Yanagiya, et al. Expires - August 2004 [Page 1] draft-yanagiya-eap-saa-01.txt Feb.2004 Conventions used in this document 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...................................................3 3. Public roaming network service................................3 3.1. Assumed network architecture.............................3 3.2. Requirements for NE and MN security......................4 3.3. Existing technology for NE and MN security...............4 3.4. Issues with existing technology..........................5 4. Proposed dynamic shared-key authentication architecture.......6 4.1. Overview.................................................6 4.2. MN considerations........................................9 4.3. AAA considerations.......................................9 4.4. NE considerations........................................9 5. Application example..........................................10 5.1. Authentication of Neighbor Advertisements...............10 5.2. Authentication of Binding Updates.......................11 References.......................................................13 Author's addresses...............................................13 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. To prevent unauthorized usage, APs must authenticate MNs. When an MN wants to use a Mobile IP (MIP) function, it must be authenticated with a mobility anchor point (MAP) and a home agent (HA). In addition to these authentications, to prevent spoofing of ARs or stealing service, an MN and AR must verify Router Advertisement and Neighbor Advertisement messages. As a result, it is necessary to execute two or more authentication processes. This may increase the connection delay, and the user of the MN must configure information for each authentication process. To make this more convenient for the user, it is necessary to establish an authentication architecture that can decrease the connection delay and the configuration time. The processing time for pre-shared key- (PSK-) based authentication is shorter than that for authentication based on the Public Key Infrastructure (PKI). However, since the relationship between an MN and an NE changes as the MN moves, it is difficult to share a symmetric key in advance. Yanagiya, et al. Expires - August 2004 [Page 2] draft-yanagiya-eap-saa-01.txt Feb.2004 802.1x is used as the access authentication technology for APs. It allows MNs and an "Authentication, Authorization and Accounting" (AAA) server to share a symmetric key, called an "EAP key", during the access authentication process. It seems reasonable to use this key as a symmetric key between MNs and NEs. In this document, we discuss 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, including access routers, home agents, and mobility anchor points. 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 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 an MN obtains layer-2 connectivity with a wired network. 3. Public roaming network service 3.1. Assumed network architecture The assumed network architecture is illustrated in Figure 1. The public roaming network service can provide mobility functions to public WLAN users by using Mobile IP. The network consists of APs, ARs, HAs, and MAPs. MNs are connected to APs. These NEs are shared by the MNs connected to the network, which do not trust each other. +----+ +----+ | MN |<-radio->| AP |\ +----+ +----+ \ : +----+ +-----+ +----+ : | AR |---| MAP |---| HA | : /+----+ +-----+ +----+ +----+ +----+ / : : | MN |<-radio->| AP | : : +----+ +----+ Figure 1: Assumed network architecture Yanagiya, et al. Expires - August 2004 [Page 3] draft-yanagiya-eap-saa-01.txt Feb.2004 The relationship between an MN and an AP or MAP changes dynamically as the MN moves. On the other hand, the relationship between an HA and an MN is static, in general. If we use dynamic assignment for HAs, this relationship will also change dynamically. 3.2. Requirements for NE and MN security To prevent unauthenticated access and unauthorized usage, the following three authentication phases may be utilized in a public roaming service network. 1) Access authentication phase To prevent unauthenticated access, an AP must authenticate an MN when it requests access. 2) IPv6 address auto-configuration phase Since APs provide only layer-2 functionality, an access link will be shared by all MNs connected to the same AP. In a public roaming service network, these MNs may not trust each other. This type of network environment is called a "Multiaccess Link" environment, as described in [SEND-THREAT]. When the MNs use the Neighbor Discovery Protocol (NDP) in a multi-access 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 or Neighbor Advertisement, it will obstruct normal IP communication. Therefore, it is necessary for ARs and MNs to verify Router Advertisement and Neighbor Advertisement messages. 3) Binding update phase After access authentication and IPv6 address auto-configuration have been completed successfully, 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. [MIPv6] [HMIP] 3.3. Existing technology for NE and MN security The existing security technology is described below. 1) Access authentication phase 802.1x is used to perform access authentication at an AP. 802.1x uses the EAP and can carry out authentication methods such as Transport Layer Security (TLS), Tunneled Transport Layer Security (TTLS), and Protected EAP, which allowing an MN and an AAA server to share a symmetric key during the authentication process. In general, Yanagiya, et al. Expires - August 2004 [Page 4] draft-yanagiya-eap-saa-01.txt Feb.2004 the AAA server sends the shared symmetric key to the AP, which uses it as a key with the MN to encrypt messages on the wireless network. 2) IPv6 address auto-configuration phase NDP messages are protected by using an 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 that dynamically change their ARs while moving. As a result, the 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) Binding update phase An MIP agent is used in IPsec SAs, as described in [MIPv6]. Since the relationship between an HA and an MN is static, they can employ a manual SA configuration or execute IKE with a preshared key between them. The relationship between an MAP and an MN, however, changes dynamically. As a result, the SA between the MN and MAP will be established through key establishment protocols like IKE, as described in [HMIP] 3.4. Issues with existing technology The authentication methods can be roughly divided into PKI-based methods and PSK-based methods. A PKI-based method uses a public key certificate to authenticate users. Therefore, it is not necessary to share a symmetric key between NEs and MNs in advance. The process of verifying a certificate, however, is complicated and requires a longer time than with a PSK-based method. Since MNs are assumed to roam between not only APs but also networks, the trusted root of the certification agent may differ. When the trusted root differs, an MN and 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 simpler process, whose authentication processing time is said to be shorter than that of a PKI-based method, in general. In a PSK-based method, however, a symmetric key must be shared between NEs and MNs in advance. In a public roaming network service, the relationships between MNs and NEs change dynamically. By using a PKI-based method, an MN and an NE can authenticate each other without presetting any individual authentication information. However, a longer time is required to complete authentication, which increases the connection delay. Thus, to reduce the delay, a PSK-based method seems more suitable, but it is impossible for an MN to configure the symmetric keys of all the NEs in a public network. Therefore, it is necessary to develop a new authentication architecture to solve the problem of keeping the processing time short while avoiding the need for encryption key presetting at the same time. Yanagiya, et al. Expires - August 2004 [Page 5] draft-yanagiya-eap-saa-01.txt Feb.2004 During access authentication with EAP-TLS, EAP-TTLS, and PEAP, through methods such as 802.1x and the Protocol for carrying out[?] Authentication for Network Access (PANA), an MN and an Authentication, Authorization and Accounting (AAA) server can share a symmetric key dynamically. In [PANA-BOOT], it is proposed that a shared EAP key be applied to bootstrap security association for Dynamic Host Configuration Protocol (DHCP) messages. Thus, we will apply the same concept to NEs and MNs in the public roaming service. 4. Proposed dynamic shared-key authentication architecture In this chapter, we discuss a PSK-based service authentication architecture that does not require symmetric key presetting between NEs and MNs. This architecture is implemented by using an 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, such as through 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 server to share a symmetric key during the authentication process. In general, the AAA server sends the shared key to the AP 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. If 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 Master Session Key (MSK) or an Extended Master Session Key (EMSK). 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. MN AP NE AAA | | : | | 802.11 | : | |[association] | : | |<-------------->| : | | | : | | 802.1x | : | | Authentication | : | | Request | RADIUS or DIAMETER | | | [Authentication Request] | |--------------->|------------------------->| | | : | Yanagiya, et al. Expires - August 2004 [Page 6] draft-yanagiya-eap-saa-01.txt Feb.2004 : : : : +-------------+ | : +-------------+ |derive | | : |derive | |Symmetric Key| | : |Symmetric Key| +-------------+ | : +-------------+ | | : | : : : : | | RADIUS or DIAMETER | | | [success] : | | |<-------------------------| | | : | | +------------+ : | | |Logical Port| : | | | Open | : | | +------------+ : | | | | | | Authentication Request | | |----------------------------->| | | | | Key-Request| | | |----------->| | | | | | | | Send Key | | | |<-----------| | | | | | | +------------+ | | | |Authenticate| | | | |MN with key | | | | +------------+ | | | | | | Authentication Reply | | |<-----------------------------| | | | | | Figure 2: Message flow in the secure access architecture 4.1.2 Key derivation 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. Since only one key, such as an MSK or EMSK, is shared when access authentication completes, it is necessary to derive cryptographically separate keys from the MSK or EMSK. In [EAP-KEY- MULTI], a mechanism is proposed for deriving cryptographically separate keys for more than one application from an EMSK. To apply this method in the proposed architecture, an MN and an AAA server or NE must be able to get a "key label" and/or "optional application data" during the access authentication or service authentication phase. Yanagiya, et al. Expires - August 2004 [Page 7] draft-yanagiya-eap-saa-01.txt Feb.2004 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. For both types, it is assumed that a secure association has already been established by using a preset configuration. 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. 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. In addition to managing the logical locations of MNs and NEs, the AAA server must obtain a "key label" and/or "optional application data" until access authentication is completed. If a "key label" and "optional application data" are assigned statically to an NE, this can be achieved by managing these values within the NE's profile. 2) Pull For the "pull" key distribution method, NEs require the AAA server to send the key when they received access 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 select the appropriate key, and a "key label" and/or "optional application data" to derive an AMSK. 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. If the architecture supports the "pull" method, a Diameter-based protocol [DIAMETER] can be applied to distribute the key protocol. Figure 3 shows an example of the message flow. AMSK-REQUEST is a newly specified command. The AAA server can determine the EMSK by using a "User-Name" or "Calling-Station-Id" AVP. "NAS-Identifier" can be used as a "key label". "Application-Master-Key" is a newly specified attribute for distributing AMSKs to NEs. MN NE AAA | | | |Service Authentication | | |Request | AMSK-REQUEST| |---------------------->| [Auth-Request-Type=| | | AUTHORIZATION_ONLY]| | | [NAS-Identifier],| Yanagiya, et al. Expires - August 2004 [Page 8] draft-yanagiya-eap-saa-01.txt Feb.2004 | | [User-Name] or| | | [Calling-Station-Id]| | |------------------------------->| | | | | | +-----------+ | | |Select EMSK| | | +-----------+ | | | | | +-----------+ | | |derive AMSK| | | +-----------+ | | | | | AMSK-Answer| | | [Result-Code=DIAMETER_SUCCESS]| | |[Application-Master-Session-Key]| | |<-------------------------------| | +---------+ | | |evaluates| | | | request | | | +---------+ | | | | | Access Success/NG | | |<----------------------| | Figure 3: Message flow for key distribution using Diameter 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, using TLS, TTLS, PEAP, and similar protocols as EAP methods. To share a symmetric key dynamically, an MN must support the key derivation function described in 4.1.2. 4.3. AAA considerations 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, using TLS, TTLS, PEAP, and similar protocols as EAP methods. To share symmetric keys dynamically, an AAA server must support the key derivation and distribution function described in 4.1.2. 4.4. NE considerations To share a symmetric key dynamically, an NE must support the key distribution function described in 4.1.3. Yanagiya, et al. Expires - August 2004 [Page 9] draft-yanagiya-eap-saa-01.txt Feb.2004 5. Application example In this chapter, we discuss examples of applying the proposed authentication architecture with Neighbor Discovery Protocol (NDP) and Mobile IP (MIP). 5.1. Authentication of Neighbor Advertisements In a public WLAN access network, MNs connected to the same AP share a link. To prevent spoofing of ARs and MNs, user traffic should be separated in each AP by implementing VLANs, and the APs should not permit communication between MNs connected to the same AP. In such a network environment, only ARs verify Neighbor Advertisement messages from MNs. Figure 4 shows an example of the message flow. The MN and the AAA server have shared a symmetric key since access authentication was successfully completed. In this example, the authentication process executes by using the challenge and response method. The AR sends a Neighbor Solicitation message with a "challenge" value. The MN responds with a "response" value calculated with a one-way hash function. The AR then checks the response against its own calculation of the expected hash value. If the values match, the AR registers the relationship between the IP address and the MAC address of the MN. The MN must obtain a "key label" and/or "optional application data" and a derived ASMK until it replies with an NA to the AR. The AR must obtain these values and derive an AMSK until it registers the MAC address. It can obtain the MAC address from the NA message, and the AAA server can obtain the MAC address from the attribute of RADIUS/DIAMETER. Thus, the source and/or MAC address can be used as a "key label" and/or "optional application data". MN AP AR AAA | | | | | | | | | Neighbor Solicitation | | | [challenge] | | |<----------------------| | +-----------+ | | | |derive AMSK| | | | +-----------+ | | | | | | | +---------+ | | | |calculate| | | | |Response | | | | +---------+ | | | | | | AMSK-REQUEST| | Neighbor Advertisement| [Auth-Request-Type=| Yanagiya, et al. Expires - August 2004 [Page 10] draft-yanagiya-eap-saa-01.txt Feb.2004 | [Response] | AUTHORIZATION_ONLY]| |---------------------->| [NAS-Identifier= | | | | MAC address of AR],| | | | [Calling-Station-Id=| | | | MAC address of MN]| | | |----------------------->| | | | +-----------+ | | | |Select EMSK| | | | +-----------+ | | | | | | | +-----------+ | | | |derive AMSK| | | | +-----------+ | | | | | | | AMSK-Answer| | | | [Result-Code= | | | | DIAMETER_SUCCESS]| | | |[Application-Master- | | | | Session-Key]| | | |<-----------------------| | | | | | | +-----------------+ | | | |evaluate Response| | | | +-----------------+ | | | | | | | | | Figure 4: Message flow for neighbor solicitation and advertisement) 5.2. 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 establish an IPsec SA in the proposed architecture. An application example for a Binding Update is shown in Figure 5. If IKE version 1 is used with preshared secrets in main mode, it determines which shared secret to use from the IP address of the peer. However, this may be a care-of address and does not indicate which MN is attempting to contact the Mobility Agent. Therefore, if PSK-based authentication is used in IKEv1, then aggressive mode MUST be used. Thus, the MN must obtain a "key label" and/or "optional application data" and derive an AMSK before calculating HASH_I, and the HA must obtain these values and derive an AMSK before calculating HASH_R. In this case, IDii and IDir can use as a "key label" and/or "optional application data". In the example shown here, a combination of IDii and IDir is used as a "key label". MN Mobility Agent AAA Yanagiya, et al. Expires - August 2004 [Page 11] draft-yanagiya-eap-saa-01.txt Feb.2004 | | | |IKE | | |[HDR, SA, KE, Ni, IDii] | AMSK-REQUEST| |----------------------->| [Auth-Request-Type=| | | AUTHORIZATION_ONLY],| | | [NAS-Identifier =IDir],| | | [User-Name= IDir]| | |------------------------------->| | | | | | +-----------+ | | |select EMSK| | | +-----------+ | | | | | +-----------+ | | |derive AMSK| | | +-----------+ | | | | | AMSK-Answer | | | [Result-Code=DIAMETER_SUCCESS],| | |[Application-Master-Session-Key]| | |<-------------------------------| | +-----------------+ | | |calculate SKEYIDs| | | +-----------------+ | | | | | +----------------+ | | |calculate HASH_R| | | +----------------+ | |IKE | | |[HDR, SA, KE,] | | | Nr, IDir,HASH_R] | | |<-----------------------| | | | | +-----------+ | | |derive AMSK| | | +-----------+ | | | | | +-----------------+ | | |calculate SKEYIDs| | | +-----------------+ | | | | | +----------------+ | | |calculate HASH_I| | | +----------------+ | | |IKE [HDR, HASH_I] | | |----------------------->| | | | | Fig. 5: Application example for establishing an ISAKMP SA for BU Yanagiya, et al. Expires - August 2004 [Page 12] draft-yanagiya-eap-saa-01.txt Feb.2004 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 [DIAMETER] "Diameter Base Protocol", RFC3588 Author's addresses Mayumi Yanagiya Hiroyuki Ohnishi NTT Corporation 3-9-11 Midori-cho, Musashino-shi Tokyo, Japan Phone: 81-422-5967893 Email: yanagiya.mayumi@lab.ntt.co.jp ohnishi.hiroyuki@lab.ntt.co.jp Yanagiya, et al. Expires - August 2004 [Page 13]