Internet Draft Benoit de Boursetty Document: Florent Bersani draft-boursetty-eap-cst-00.txt France Telecom R&D Expires: September 2003 March 2003 EAP client-side transport Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 This document defines a new architecture on the client-side for authentication by EAP. This architecture complements the usual setup considered in EAP by making it become symmetric: the client-side is divided in two parts, the Authentication Token and the client, which are analogous respectively to the Authentication Server and the Authenticator on the server-side. Moreover, this document describes a framework for the use of Authentication Tokens with the EAP protocol. Boursetty and Bersani Expires - September 2003 [Page 1] EAP client-side transport March 2003 Table of Contents 1. Introduction...................................................2 1.1 Reminder of a Typical EAP Setup............................2 1.2 Purpose of this draft......................................3 1.3 Requirements language......................................4 1.4 Terminology................................................4 1.5 Related work...............................................5 2. Architecture...................................................6 2.1 Overall Architecture.......................................6 2.2 Protocol stack.............................................7 3. Rationale for our proposal.....................................8 3.1 Security on the client side................................8 3.2 Flexibility on the Client side.............................8 3.3 Ease of deployment of the authentication method............9 4. Protocol specifications.......................................10 4.1 EAP-CST (EAP Client-Side Transport).......................10 4.2 EAP-CST-LDA (EAP-CST Link-layer Dependent Adaptation).....11 5. Example.......................................................11 6. Provisions for the evolution of EAP-CST.......................13 6.1 MK and MSK transport between AuthToken and Client.........13 6.2 Initialization of the authentication......................13 7. Security Considerations.......................................13 Acknowledgements.................................................14 References.......................................................14 Authors' Addresses...............................................16 1. Introduction 1.1 Reminder of a Typical EAP Setup Let us begin this draft with a reminder of a typical EAP Setup. For a more detailed description, the reader is referred to [1]. +--------+ +--------+ | Client | | NAS | | +--( Access Network )--+ +-----( Target Network ) +--------+ +----+---+ | | +----+----+ | AAA | | Server | +---------+ Fig. 1 û A typical EAP Setup Boursetty and Bersani Expires - September 2003 [Page 2] EAP client-side transport March 2003 As represented on Fig 1., a client wants to connect to a Target Network through a Network Access Server (NAS), which is first reached via an Access Network (e.g. 802.11 [6]). The NAS requires authentication using EAP [2,3] from the client, but it does not perform authentication itself. It instead relays EAP authentication exchanges to an AAA server (e.g. using the RADIUS protocol [4]). After a successful authentication, an EAP Master Key (MK) may be shared between the AAA Server and the Client, depending on the EAP Method used. An example of EAP Method providing MK establishment is EAP-TLS [5]. The data encryption or integrity protocol between the client and the NAS that is used after the authentication (e.g. WEP, TKIP or CCMP [6,7]) will use keying material which is termed in [1] the Master Session Key (MSK). This MSK may be provided by the AAA server or derived from the MK. Since the NAS does not know this keying material right after the authentication procedure, it needs to be transmitted from the AAA. This problem is explained for PPP [8] in section 6.2 of [4]. In [1], the data containing keying material transferred from the AAA server to the NAS is called the AN-Token. Transport from the AAA server to the NAS is sometimes dealt with, when using RADIUS, by using MS-MPPE- Send-Key and MS-MPPE-Recv-Key between the NAS and the RADIUS server as described in [9]. RADIUS Support For Extensible Authentication Protocol (EAP) is dealt with in [10]. We want to stress the separation on the server-side between authentication and its later use. In this setup, authentication is performed between the Client and the AAA Server, but it is used between the Client and the NAS. 1.2 Purpose of this draft We propose in this draft a client-side mechanism which also separates authentication from its later use (for instance, session keys used to encrypt the communications between the NAS and the client). We would additionally like to provide the basis for an interoperable framework for the use of Authentication Tokens with EAP. We however do not intend to define a general transaction protocol on the client side. A typical use case for such a transaction protocol is the following: the user wants to digitally sign an e-mail that he wrote on his laptop but his credentials are stored on his mobile phone. The transaction protocol would handle the communication between the laptop and the mobile phone so as to deliver the expected Boursetty and Bersani Expires - September 2003 [Page 3] EAP client-side transport March 2003 service. Such a protocol is outside of our scope: our sole purpose is to enhance EAP's typical setup on the client-side. 1.3 Requirements language 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 [11]. 1.4 Terminology AN-Token This terminology is defined in [1] and has the same meaning in this document. Client and Server Two main entities are considered in this draft: the Client and the Server. These two entities communicate with one another. The Client initiates the dialog to the Server. In this document, the Client and the Server wish to authenticate to each other, mutually or not. The Client and the Server may then wish to use cryptographic confidentiality and integrity protection mechanisms to safeguard their communications. We adopt this terminology of "Client" and "Server", although in [1] the corresponding notions would be called "Client" and "NAS". This is to abstract our work from the network access control problem to address other sorts of access control, between any client and server. Authentication Server (AuthServer or AS) An Authentication Server is an entity that provides an authentication service to the Server. Most implementations would probably feature Authorization and Accounting, making it an AAA server. But this is not mandatory for the purpose of this draft. Authentication Token (AuthToken or AT) An Authentication Token is a device which a Client can use to prove its identity and gain access to services suchas network services or application services. An Authentication Token not only stores the user's credentials but also handles the authentication protocol and provides additional management features like enabling multiple identities to be stored on the same Token. In addition, Authentication Tokens have the ability to communicate with other devices. A token card without a communication port shall therefore not be considered an Authentication Token in this draft. Boursetty and Bersani Expires - September 2003 [Page 4] EAP client-side transport March 2003 Authentication Tokens may be for instance: smart cards, token cards, mobile phones or even laptops. An instance of Authentication Token is the smart card performing EAP as presented in [12]. 1.5 Related work Our work is closely related to [12]. The approach of [12] is to perform end-to-end authentication between a smart card and an AAA Server, then transmit session keys (fragments of the MSK) from the smart card to the authenticating device which will then be communicating with the NAS using these session keys for security. The main value of this approach is to lower the risk of fraud. When secrets are stored on a device like a PC, historically known to be prone to Trojan horses, they can easily be misused without the legitimate user noticing it. Also, the memory of a "borrowed" PC (e.g. hard drives) can be read with little time and investment. Thus, by keeping the secrets on a secure authentication Token hardened against Trojan horse and physical attacks, the overall fraud risk is lowered. Acknowledging the value of this approach, we propose an architecture that generalizes it in several ways. First, we would like to broaden the scope and not be restricted to smart cards. An Authentication Token might well be, for instance, a mobile phone regardless of whether a smart card (like the GSM SIM) is present in the mobile phone. We would therefore like to specify a more general protocol that would enable EAP exchanges to be relayed from a Client to an Authentication Token. Second, we wish to split this protocol in two sublayers: a logical sublayer, independent of the networking technology used to link the Authentication Token to the Client, and a physical sublayer taking care of the adaptation to the particular technology used. To take [12] as an example, this would imply separating the four abstract primitives used (EAP-Packet, Get-Next-Identity, Set-Identity, Get- PairwiseMasterKey) from the specific ISO 7816-4 case. In our approach, we make a clear distinction between the link used by the Authentication Token and the Client (in [12], ISO 7816-4) and the Token itself (in [12], a smart card). Thanks to our approach, the same Authentication Token (e.g. a mobile phone) can be used with various links (e.g. Infra-red or Bluetooth). Similarly, the same link (e.g. Bluetooth) can be used by different Authentication Tokens (e.g. a Linux PDA or a Java phone). Boursetty and Bersani Expires - September 2003 [Page 5] EAP client-side transport March 2003 2. Architecture 2.1 Overall Architecture The architecture that we define is represented on Fig. 2. +---------+ +----------+ |AuthToken| <====== Authentication ======> |AuthServer| +----+----+ +-----+----+ | Integrity & | | +------------+ <= Encryption => +-----------+ | '----+ Client |------------------+ Server +-' +------------+ +-----------+ Fig. 2. A new EAP setup A Client and a Server want to communicate with each other (e.g. a client laptop and an 802.11 Access Point). At some point, authentication needs to be performed between the Client and the Server. This authentication is delegated on the client-side to an Authentication Token (AuthToken), and on the server-side to an Authentication Server (AuthServer). Authentication then takes place using EAP between the Authentication Token and the Authentication Server at the logical level, while the Client and the Server simply relay exchanges between the two, such as Challenges, Responses, etc. Optionally, an EAP Master Key (MK) is derived during the authentication phase. At the end of this phase, the MK is shared between the Authentication Token and the Authentication Server. If the Client and the Server then wish to establish a secure link, they need to share some keying material. This keying material derives from the MSK that is provided either by derivation from the MK or by the Authentication Server (depending on the particular EAP method used). The Client and the Server then use the MSK (more precisely the TSK derived from the MSK) to encrypt and integrity-protect their communications in a service-specific way. The setup that we propose in Fig. 2 makes the typical setup of Fig. 1 become symmetric. In Fig 2, the client of Fig 1. has been split up in two parts (the Authentication Token and the Client), the NAS has become the Server and the AAA Server, the Authentication Server. Boursetty and Bersani Expires - September 2003 [Page 6] EAP client-side transport March 2003 2.2 Protocol stack The protocol stack defined for our architecture is represented on Fig. 3. +------------+ | EAP-X |<== Authentication to the AuthServer => +------------+ +------------++--------+ +--------++--------+ | EAP | | EAP || EAP | | EAP || EAP | +------------+ +------------++--------+ +--------++--------+ | EAP-CST | | EAP-CST || | | || EAP | +------------+ +------------+|Service | |Service || over | |EAP-CST-LDA | |EAP-CST-LDA ||Protocol| |Protocol|| AAA | +------------+ +------------+| | | |+--------+ | Local link |---| Local link || +-------+ || AAA | +------------+ +------------++--------+ +--------++--------+ AuthToken Client Server Fig. 3(a). Protocol stack on the client side +---------+ <= Authentication from the AuthToken => | EAP-X | +--------++--------+ +---------+ | EAP || EAP | | EAP | +--------++--------+ +---------+ | || EAP | | EAP | |Service || over | + over | |Protocol|| AAA | | AAA | | |+--------+ +---------+ | || AAA |----------------------------| AAA | +--------++--------+ +---------+ Server AuthServer Fig. 3(b). Protocol stack on the server side It is assumed that the Server and the Client authenticate each other using EAP. EAP is used to encapsulate a given method represented on Fig. 3. as EAP-X, for instance EAP-TLS. Any method can be used there (e.g. EAP- SIM [13], EAP-TLS, ...). The layer represented as "Service Protocol" is an abstract layer, that is to say that its choice does not have any importance for the definition of our architecture. It could be instantiated for example by EAPoverLAN over 802.3 [14], or by PPP over a serial line. Boursetty and Bersani Expires - September 2003 [Page 7] EAP client-side transport March 2003 Similarly, it is not relevant to specify the AAA and EAP-over-AAA protocols for the purpose of this Draft. The two layers that we define in this document are EAP-CST (which stands for EAP Client-Side Transport) and EAP-CST-LDA (which stands for EAP-CST Link-layer Dependent Adaptation). 3. Rationale for our proposal In our opinion, the benefits of our approach are: a. Security on the client side. b. Flexibility on the client side. c. Ease of deployment of the authentication method. Additionally, when compared to [12], our approach enhances the security of the client's credentials. Although smart cards provide good protection against physical attacks, they provide little protection so far against Trojan horses on the host to which they are connected. It is easier to provide security against these threats by encapsulating the smart card in a component which can be hardened against Trojan horses more efficiently than a PC, e.g. a mobile phone. 3.1 Security on the client side Thanks to an adequate Authentication Token, it will be harder for an attacker to steal the client's credentials, to use them without his consent, to destroy them or to make them unusable. For instance, if a Trojan horse on the host to which a smartcard is connected performs enough wrong PIN entries, it may block that smartcard. Alternatively, if a Trojan horse knew the user's PIN code (for example by keylogging previous PIN entries), it could relay the smartcard's capabilities to an outside attacker. By placing a smartcard inside an Authentication Token which has a User Interface, and only performs authentication once the User Interface has been properly activated, the risk can greatly be reduced. For instance, an Authentication Token may be a closed OS device featuring a keyboard for PIN entry and comprising a smart card; PIN entry being performed locally to the Authentication Token, a Trojan horse located on a different host would have no way of keylogging the PIN or entering it secretly to the smartcard unbeknownst to the user. 3.2 Flexibility on the Client side Boursetty and Bersani Expires - September 2003 [Page 8] EAP client-side transport March 2003 The same Client (e.g. a laptop) supports a wide range of authentication Tokens (mobile phone, smart card, Token card...). The client will be able to use at his/her convenience a wide range of media for authentication transport (Bluetooth, Ir, etc.). The client will be able to authenticate to multiple services simultaneously (e.g. cellular and WLAN services). The client won't have to do any cumbersome manipulation (e.g. taking the SIM out of a GSM mobile phone to plug it into an appropriate reader on his laptop, when the GSM mobile phone could instead act as an Authentication Token for the laptop). 3.3 Ease of deployment of the authentication method Only the Authentication Token needs to implement the EAP method, not the Client. This may simplify the user configuration: for instance, no specific adjustments would need to be made to a user's laptop when an EAP method upgrade is performed. Boursetty and Bersani Expires - September 2003 [Page 9] EAP client-side transport March 2003 4. Protocol specifications These sections should be completed in future versions of this draft. 4.1 EAP-CST (EAP Client-Side Transport) The following specification of EAP-CST is currently only at the functional level. In the future, the definition of the primitives below shall be completed by parameter syntax and more precise semantics. EAP-CST includes the following primitives, exchanged between AuthToken (AT) and the Client (C). Primitive name Direction Description ==================================================================== EAP-Packet AT <-> C Relay an EAP packet -------------------------------------------------------------------- Auth-Status AT --> C Indicate the success or failure of the authentication. If successful, a MasterSessionKey-Give message may follow -------------------------------------------------------------------- MasterSessionKey- AT --> C Transmit the Master Session Key Give generated by the last authentication, if successful -------------------------------------------------------------------- IdentityList-Get AT <-- C Request a list of identities supported by the Authentication Token -------------------------------------------------------------------- IdentityList-Give AT --> C Give a list of supported identities -------------------------------------------------------------------- Identity-Select AT <-> C Select an identity for use for the next authentication -------------------------------------------------------------------- Prompt-Request AT --> C Request an entry from the user (e.g. "Please enter your PIN code") -------------------------------------------------------------------- Prompt-Answer AT <-- C Give the user's response to a Prompt request. -------------------------------------------------------------------- Control-Start AT <-> C Require the start of a session -------------------------------------------------------------------- Control-Stop AT <-> C Close the current session -------------------------------------------------------------------- Boursetty and Bersani Expires - September 2003 [Page 10] EAP client-side transport March 2003 4.2 EAP-CST-LDA (EAP-CST Link-layer Dependent Adaptation) EAP-CST-LDA may be specified in future versions of this draft, or in separate drafts. It will define a mapping of the abstract primitives of EAP-CST to actual data exchanges on the local link layer. EAP-CST-LDA will also be responsible for ensuring security; to take an example where EAP-CST-LDA would be required to provide security, the unprotected client-side transport of EAP over an IrCOMM link would not be protected against eavesdropping; an attacker would be able to learn the session key from listening to SessionKey-Response messages. In this case, EAP-CST-LDA would be required to add a security mechanism similar to the BlueTooth pairing mechanism. 5. Example Let us illustrate our architecture with a use case: Alice ("A") wants to connect to an 802.11 wireless LAN using her mobile phone as an Authentication Token. A's Wireless Internet Service Provider authenticates its users through a RADIUS server interrogated by wireless Access Points. This example is an instance of the above architecture, with the following mapping: * AuthToken = A's mobile phone * Client = A's laptop * Server = the wireless Access Point A wishes to use * AuthServer = the wireless ISP's RADIUS server. The local link layer is a BlueTooth pseudo-serial link [15]. The "Service Protocol" abstract layer is 802.1x. At first, the Access Point will require A to provide her identity and start an authentication session with the RADIUS server. Boursetty and Bersani Expires - September 2003 [Page 11] EAP client-side transport March 2003 A's Mobile Phone A's Laptop Access Point RADIUS AuthToken Client Server AuthServer | | | | | | EAP-Request/Identity | | | |<---------------------| | | EAP-Request/Identity| | | |<--------------------| | | | | | | | EAP-Respon./Identity| | | |-------------------->| | | | | | | | | EAP-Respon./Identity | | | |--------------------->| EAP-Respon./Id. | | | |----------------->| The Wireless ISP's RADIUS server then starts an EAP method (EAP-SIM for instance) A's Mobile Phone A's Laptop Access Point RADIUS AuthToken Client Server AuthServer | | | | | | |EAP-Req./SIM/Start| | | |<-----------------| | | EAP-Request/SIM/Start| | | |<---------------------| | | EAP-Req./SIM/Start | | | |<--------------------| | | The EAP-SIM dialog continues between the Wireless ISP's RADIUS and A's mobile phone, relayed by the Access Point and A's laptop, until the RADIUS issues an EAP-Success message. During this phase, A's mobile phone may ask A to enter a PIN code. Upon success of authentication, A's mobile phone delivers to A the session keys derived from the successful EAP-SIM exchange. A's Mobile Phone A's Laptop Access Point RADIUS AuthToken Client Server AuthServer | | | | | | | EAP-Success | | | |<-----------------| | | EAP-Success | | | |<---------------------| | | EAP-Success | | | |<--------------------| | | | Auth-Success | | | |-------------------->| | | | SessionKey-Give | | | |-------------------->| | | Boursetty and Bersani Expires - September 2003 [Page 12] EAP client-side transport March 2003 6. Provisions for the evolution of EAP-CST 6.1 MK and MSK transport between AuthToken and Client At this point, the table of section 4.1 contains a primitive to transport the Master Session Key. This scheme is satisfactory e.g. in the case of EAP-TLS, where the MSK is derived using the sole knowledge of the EAP Master Key. But considering for example that in services allowing roaming, several MSKs may need to be created from the EAP Master Key, and particularized for each Server to which they relate (cf. the definition of Client-Server Token, page 4 of [1]), we think that this scheme may need to be evolved to take into account multiple Client-Server Tokens. 6.2 Initialization of the authentication At this point, the table of section 4.1 contains two very simple primitives to start and stop an authentication session. As of now, more evolved scenarios (e.g Client scans for all available AuthTokens and asks the user to choose which one to use) do not fall in the scope of this document, since it is merely focused on EAP exchanges. 7. Security Considerations As highlighted in [12] and in section 3.1, we feel that our architecture enhances the overall security of the client-side by preventing malicious use of critical credentials because of their connection to a potentially insecure environment. However, we must carefully examine various threats on our architecture, because the EAP-CST interface exposes confidential data. An initial assessment of threats follows. It is inspired from section 14.3 of MeT Personal Transactions Protocol [16] (an architecture which shares the same kind of vulnerabilities). a. Impersonation of the Authentication Token to the Client b. Impersonation of the Client to the Authentication Token c. Eavesdropping on the link between the Authentication Token and the Client d. Modification or insertion of packets (including replay attacks) on the link between the Authentication Token and the Client e. Man in the Middle Attack between the Authentication Token and the Client f. Denial of Service on the link between the Authentication Token and the Cilent As mentioned in section 4.2, EAP-CST-LDA is responsible for providing EAP-CST with a secure link that enforces confidentiality, data origin authentication and replay protection and thus tackle all the threats listed above. Boursetty and Bersani Expires - September 2003 [Page 13] EAP client-side transport March 2003 Of course, if the Authentication Token is compromised (e.g. infected by a Trojan Horse), our security enhancements are voided: our central assumption is that the Authentication Token is a much safer application execution environment than the Client. Acknowledgements We would like to express our deep thanks to Julien Bournelle of INT and Stefan Andersson of Ericsson for their very valuable feedback on preliminary versions of this document. Additionally, we thank Laurent Butti and Jean-Michel Combes of France Telecom R&D for their support and input on the preparation of this document. References 1 Aboba, B., Simon, D., "EAP Keying Framework", Internet Draft (work in progress) draft-aboba-pppext-key-problem-06.txt, March 2003 2 Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998 3 Blunk, L., et al., "Extensible Authentication Protocol (EAP)", Internet Draft (work in progress) draft-ietf-eap-rfc2284bis- 01.txt, January 2003 4 Rigney, C., et al., "Remote Authentication Dial-In User Service (RADIUS)", RFC 2865, June 2000 5 Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999 6 Institute of Electrical and Electronics Engineers, "Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Network - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999. 7 Institute of Electrical and Electronics Engineers, "Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Network - Specific Boursetty and Bersani Expires - September 2003 [Page 14] EAP client-side transport March 2003 Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Robust Security", IEEE Standard 802.11i, Drat 3.1 (work in progress), February 2003 8 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 9 Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2458, March 1999 10 Aboba, B., Calhoun, P., "RADIUS Support For Extensible Authentication Protocol (EAP)", draft-aboba-radius-rfc2869bis- 10.txt, March 2003 11 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 12 Urien, P., et al., "EAP support in smartcards", Internet Draft (work in progress) draft-urien-eap-smartcard-01.txt, February 2003 13 Haverinen, H. Salowey, J., "EAP SIM Authentication", Internet Draft (work in progress) draft-haverinen-pppext-eap-sim-09.txt, January 2003 14 Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. 15 Bluetooth SIG, "Bluetooth specifications v1.1", February 2001 16 Mobile electronic Transactions, "MeT Personal Transactions Protocol v1.0", November 2002. Boursetty and Bersani Expires - September 2003 [Page 15] EAP client-side transport March 2003 Authors' Addresses Benoit de Boursetty Phone: +33-1-4529-5926 France Telecom R&D Email: benoit.deboursetty 38, rue du General-Leclerc @francetelecom.com 92794 Issy-les-Moulineaux Cedex 9 France Florent Bersani Phone: +33-1-4529-6220 France Telecom R&D Email: florent.bersani 38, rue du General-Leclerc @francetelecom.com 92794 Issy-les-Moulineaux Cedex 9 France Boursetty and Bersani Expires - September 2003 [Page 16]