Internet Engineering Task Force M. Badra INTERNET DRAFT P. Urien Expires May 2005 ENST Paris November 30, 2004 EAP-Double-TLS Authentication Protocol Status By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 1 Abstract EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a full TLS handshake is used to mutually authenticate a client and a server and to share a session key. EAP-Double-TLS extends this authentication negotiation by using a secure connection established by the TLS resumed handshake to exchange additional information between the client and the server. The secure connection established by the resumed handshake may then be used to allow the server and the client to securely exchange their identity and to update security attributes for next sessions. Badra & Urien Informational - Expires May 2005 1 INTERNET DRAFT EAP-Double-TLS November 2004 EAP-Double-TLS allows a client and a server to establish keying material for use in the data connection between the client and the authenticator. The keying material is established implicitly between client and server based on the TLS resumed handshake. Table of Contents 1 Abstract.........................................................1 2 Introduction.....................................................2 2.1 Requirements language.......................................3 3 Protocol overview................................................4 3.1 EAP identity protection.....................................4 3.2 Overview of the EAP-Double-TLS conversation.................4 3.1.1 Phase 1: TLS PSK Handshake............................5 3.1.2 Phase 2...............................................7 3.1.1.1 Case 1: TLS Handshake...............................7 3.1.1.2 Case 2: Other authentication and authorization mechanisms..........................................8 3.2. Retry behavior.............................................8 3.3. Fragmentation..............................................8 3.4. Key derivation.............................................8 3.5. CCP and CCP negotiation....................................8 3.6. Inner method encapsulation.................................8 3.7. Examples...................................................8 4 EAP-Double-TLS protocol within EAP Smartcards...................12 4.1 Fragmentation issues.......................................13 5 Detailed description of the EAP-Double-TLS protocol.............15 5.1 EAP-Double-TLS Packet Format...............................15 5.2 EAP-Double-TLS Request Packet..............................16 5.3 EAP-Double-TLS Response Packet.............................17 6 Security Considerations.........................................19 6.1 Security claims............................................19 6.1.1 Authentication, confidentiality and integrity protection.........................................19 6.1.2 Protected cipher suite negotiation.................19 6.1.3 User identity protection...........................19 6.1.4 Replay protection..................................19 6.1.5 Key derivation (and updating)......................19 6.1.6 Key strength.......................................20 6.1.7 Dictionary attack protection.......................20 6.1.8 Fast reconnect.....................................20 6.1.9 Channel binding and man-in-middle-attacks protection.........................................20 6.1.10 Session independence and forward secrecy...........21 Acknowledgements..................................................21 References........................................................21 Author's Addresses................................................22 2 Introduction The Extensible Authentication Protocol [EAP] defines a mechanism that may be extended with additional authentication protocols within PPP [PPP] such as MD5 [MD5], TLS [TLS] and PEAP [PEAP]. Badra & Urien Informational - Expires May 2005 2 INTERNET DRAFT EAP-Double-TLS November 2004 The EAP-TLS authentication protocol, described in [EAPTLS], provides a standard method for mutual authentication and key generation. The EAP-TLS requires certificates and Public Key Infrastructures (PKI) infrastructures well maintained and that the client and the server MUST be authenticated using X509 certificates. TLS itself allows a client and a server to resume sessions [TLS]. A secure connection may be terminated and resumed later. Secure sessions can be resumed if the client and the server agree. During this phase, the peers will use the old master_secret and the new random numbers to calculate new master_secret and cryptographic keys. This will generate fewer cryptographic computations and less processing time than a full TLS handshake. In addition, it will save the bandwidth which is the bottleneck in the wireless networks. Shared-key TLS runs as resume sessions using pre-installed secret key. A detailed description may be found in [SKTLS]. However, it may be an advantageous to use shared-key authentication handshake instead of PKI based certificates. Further, resumed TLS does not require any asymmetric cryptographic operation like RSA encrypt/decrypt or certificates verification. EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and a server. EAP-Double-TLS extends this authentication negotiation by using the secure connection established by the resumed handshake to securely exchange additional information between the client and the server. In EAP-Double-TLS, the authentication is established using pre installed key on both the client and the server. It uses symmetric encryption to allay the PKI requirements of [EAPTLS], [PEAP] or [EAP-TTLS]. The secure connection established by the resumed handshake may then be used to allow the server to authenticate the client using certificate authentication infrastructures. EAP-Double-TLS allows anonymous exchanges and identity protection against eavesdropping, man-in-the-middle and other cryptographic attacks. It allows also the client and the server to update security attributes for next sessions and then to ensure the PFS (Perfect Forward Secrecy). Further, EAP-Double-TLS provides a mechanism for session key establishment for encryption protocols within PPP such as PPP-DES [PPPDES] and PPP-3DES [PPP3DES] protocols. 2.1 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. Badra & Urien Informational - Expires May 2005 3 INTERNET DRAFT EAP-Double-TLS November 2004 3 Protocol overview 3.1 EAP identity protection At the beginning of an EAP session, EAP identity (EAP-ID) is transmitted in clear text, in the identity response message. This parameter is used by the authenticator to forward EAP packets to the authentication server which in turn uses it as an index for users' database management. In EAP-Double-TLS, EAP-ID SHOULD be replaced either by the TLS session_id value (see 3.2) or by the session_id concatenated to the authentication server address (session_id@server.com). This process will protect the user's privacy against surveillance and make the subscriber's EAP exchanges untraceable to eavesdroppers. In fact, the current session_id will be replaced by a new one computing during phase 2 (see 3.2). 3.2 Overview of the EAP-Double-TLS conversation In order to apply the use of TLS resumed session, we suggest sharing a TLS session between the client and the server. The session is identified by the session_id (in TLS terminology). It corresponds to, among others, the value of the master_secret and the cipher_suite. The cipher_suite represents the cryptographic option supported by both the server and the client and it is initialized by both the client and the server to a particular option. The shared session may be stocked on a client smartcard. In general, EAP-Double-TLS negotiation comprises two phases (figure 1): During phase 1, TLS resumed handshake is used for mutual authentication and key generation. This phase uses a cipher suite allowing phase 2 to securely exchange TLS records or other security protocols payloads. The phase 2 of EAP-Double-TLS may be a full TLS handshakes with mutual authentication, only server-side authentication, or anonymous. It MAY also be established using any mechanism that can generate session key like Kerberos. Note: If servers or clients donĘt care about anonymity and/or PFS, they can be satisfied by the phase 1 negotiation. For authorization or additional authentication requirements, the client and the server can use any mechanism they implement (e.g. MD5, MSCHAP, etc.). Badra & Urien Informational - Expires May 2005 4 INTERNET DRAFT EAP-Double-TLS November 2004 During phase 2, TLS records are exchanged in an encrypted manner using the established tunnel in order to optionally perform authorization and authentication mechanisms and to refresh the parameters of the shared session (e.g. session_id and master_secret). Client server ------ Tunnel TLS ------ ................................... . +----------+ +----------+ . . | Handshake| | Handshake| . . | phase 2 | | phase 2 | . . +-----^----+ +----^-----+ . . | | . +---------+ . | | . +---------+ |Handshake| . | | . |Handshake| | phase 1 | . | | . | phase 1 | +----^----+ . | | . +----^----+ | . | | . | | . | | . | | . +----v----+ +----v----+ . | | . | Record | | Record | . | | . | phase 2 |<----->| phase 2 | . | | . +--^------+ +------^--+ . | | ......|.....................|...... | | | | | | +----+ +----+ | | | | | +-v-------v-+ +-v-------v-+ | Record | | Record | | phase 1 |<------------------------->| phase 1 | +-----^-----+ +-----^-----+ | | <=======================================> Carrier Protocol (PPP, EAPOL, RADIUS, etc) Figure 1 - Relationship between the EAP-Double-TLS peer and the EAP- Double-TLS server. 3.1.1 Phase 1: TLS PSK Handshake In phase 1, the EAP-Double-TLS begins with the authenticator sending an EAP-Request/Identity packet to the peer. The peer will respond with an EAP-Response/Identity packet to the authenticator, containing the peer's UserId. Once this is established, the authenticator MAY act as a pass-through device, with the EAP packets received from the peer being encapsulated for transmission to a RADIUS server or backend security server. Badra & Urien Informational - Expires May 2005 5 INTERNET DRAFT EAP-Double-TLS November 2004 When the server receives the peer's Identity, it MUST respond with an EAP-Double-TLS/Start packet. This is an EAP-Request packet with EAP-Type= EAP-Double-TLS, the Start (S) bit set and no data. When receiving this message, the peer will answer by EAP-Response packet with EAP-Type= EAP-Double-TLS. The data field encapsulates the TLS client_hello resumed handshake message. This message contains, among others parameters, a random number and the session_Id corresponds to the shared session the client wishes to use. The server then checks its sessions' database for a match. If a match is found, the server responses with EAP-Request with EAP-Type= EAP-Double-TLS. This packet will encapsulate the TLS server_hello resumed handshake with the same session_id value sent by the client and another random number. Following the hello messages, the server will send its TLS change cipher spec message and proceed directly to TLS finished message. The TLS finished massage will serve to authenticate the server to the client since it is calculated using the pre-installed key. If the EAP server authenticates successfully (the peer will calculate the same finished value using the pre-installed key), the peer MUST send an EAP-Response packet of EAP-Type= EAP-Double-TLS, that transports the TLS change cipher spec and finished messages. Once this establishment is complete, the client and the server MAY begin to exchange phase 2 data. Otherwise, the server will distribute data connection keying information and other authorization information to the access point. If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type= EAP-Double-TLS containing a TLS Alert message identifying the reason for the failed authentication. Alert messages with a level of fatal result in the immediate termination of the connection. In order to make sure that the server receives the TLS alert message, the peer MUST wait for the server to reply before terminating the conversation. Like in [EAPTLS], the server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition. If the peer authenticates unsuccessfully, the server MAY send an EAP-Response packet of EAP-Type= EAP-Double-TLS containing a TLS Alert message identifying the reason for the failed authentication. Alert messages with a level of fatal result in the immediate termination of the connection. Badra & Urien Informational - Expires May 2005 6 INTERNET DRAFT EAP-Double-TLS November 2004 In order to make sure that the peer receives the TLS alert message, the server MUST wait for the peer to reply before terminating the conversation. 3.1.2 Phase 2 This Phase will occur after establishment of a TLS resumed Handshake in Phase 1 is successful. This phase MAY be established to ensure additional services such as client identity protection and PFS and to apply more authentication and authorization policies. 3.1.1.1 Case 1: TLS Handshake During the phase 2, TLS Record Layer is used to securely tunnel a TLS session. The TLS session information is encapsulated in sequences of TLS attributes, whose use and format are described in [TLS]. TLS Mutual authentication, server-side authentication or TLS anonym may be established, depending on the policies chosen. In this phase, the server begins the exchange by sending the EAP- Double-TLS/HelloRequest to the client. This message is sent to indicate to the peer the success of phase 1 establishment session and the beginning of phase 2 (new TLS session). The hello request message is defined in [TLS] and may be sent by the server at any time. If the client agrees, it and the server continue the exchange of EAP packets to complete the new TLS handshake, as described in [TLS]. This phase is completed when the client and the server exchange change cipher spec and finished messages. If this phase is successfully perfected, the client MUST send an EAP-Response packet of EAP-Type= EAP-Double-TLS, and no data. The EAP-Server then MUST respond with an EAP-Success message. At this point, the server will distribute data connection keying information and other authorization information to the access point. Note that in this case of TLS Handshake, EAP-Double-TLS products, as part of the new TLS handshake protocol, new session key and new master_secret key. Thus, the server will distribute the pre- installed key (used in phase 1). Next, the server and the client replace the shared session used in the first phase with the new session established in the second phase. In other words, they replace the pre-installed key and the correspondent session_id with the session_id and the master_secret generated and calculated during phase 2. The new TLS session will be then used for the next EAP- Double-TLS session. Badra & Urien Informational - Expires May 2005 7 INTERNET DRAFT EAP-Double-TLS November 2004 3.1.1.2 Case 2: Other authentication and authorization mechanisms In order to extend the EAP-Double-TLS with other authentication and authorization mechanisms, EAP-Double-TLS phase 2 MAY be established using any mechanism that can generate session key like Kerberos. In this case and after establishment of a TLS resumed Handshake in Phase 1 is successful, the server MAY request for additional authentication and authorization information. Thus, the server sends an EAP request indicating the EAP method type (method has the ability of generating session keys). 3.2. Retry behavior See section 3.2 of RFC 2716. 3.3. Fragmentation See section 3.3 of RFC 2716. 3.4. Key derivation See section 3.5 of RFC 2716. 3.5. CCP and CCP negotiation See section 3.6 and 3.7 of RFC 2716. 3.6. Inner method encapsulation As stated before, EAP-Double-TLS uses the TLS record layer to tunnel information between the client and the server to, among others operations perform additional authentication and authorization mechanisms. In this optic, EAP-Double-TLS reuses the attribute-value pairs (AVPs) defined in [EAPTTLS]. 3.7. Examples The following exchanges show where TLS Handshake with certificate or anonymous key exchange change within Phase 2, the conversation will be as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/Identity EAP-Response/Identity -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (EAP-Double-TLS Start) Badra & Urien Informational - Expires May 2005 8 INTERNET DRAFT EAP-Double-TLS November 2004 EAP-Response/ EAP-Type= EAP-Double-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS Hello Request) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS client_hello) -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS server_hello, [TLS certificate], [TLS server_key_exchange], [TLS certificate_request], TLS server_hello_done) EAP-Response/ EAP-Type= EAP-Double-TLS ([TLS certificate], TLS client_key_exchange, [TLS certificate_verify], TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type= EAP-Double-TLS -> <- EAP-Success The following exchanges show where EAP/Type=X change within Phase 2, the conversation will be as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/Identity EAP-Response/Identity -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (EAP-Double-TLS Start) Badra & Urien Informational - Expires May 2005 9 INTERNET DRAFT EAP-Double-TLS November 2004 EAP-Response/ EAP-Type= EAP-Double-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (AVP [EAP-Request/EAP-Type=X]) EAP-Response/ EAP-Type= EAP-Double-TLS (AVP [EAP-Response/EAP-Type=X])-> . . . <- EAP-Request/ EAP-Type= EAP-Double-TLS (AVP [EAP-Request/EAP-Type=X, Success]) EAP-Response/ EAP-Type= EAP-Double-TLS (AVP [EAP-Request/EAP-Type=X]) -> <- EAP-Success The following exchanges show where TLS Handshake with certificate or anonymous key exchange change within Phase 2, and fragmentation is required (during the phase 1, no fragmentation is required), the conversation (during the phase 2) will be as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS Hello Request, S bit set) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type= EAP-Double-TLS Badra & Urien Informational - Expires May 2005 10 INTERNET DRAFT EAP-Double-TLS November 2004 (TLS server_hello, TLS change_cipher_spec, TLS finished) (Fragment 1: L, M bits set) EAP-Response/ EAP-Type= EAP-Double-TLS -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (Fragment 2: M bits set) EAP-Response/ EAP-Type= EAP-Double-TLS -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (Fragment 3) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS change_cipher_spec, TLS finished)(Fragment 1: L, M bits set)-> <- EAP-Success During the phase 1 and in the case where the server authenticates to the client successfully, but the client fails to authenticate to the server, the conversation will be as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/Identity EAP-Response/Identity -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS Start) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS server_hello, TLS change_cipher_spec TLS finished) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS change_cipher_spec, TLS finished) -> <- EAP-Request EAP-Type= EAP-Double-TLS (TLS Alert message) EAP-Response/ EAP-Type= EAP-Double-TLS -> Badra & Urien Informational - Expires May 2005 11 INTERNET DRAFT EAP-Double-TLS November 2004 <- EAP-Failure (User Disconnected) During the phase 1 and in the case where server authentication is unsuccessful, the conversation will be as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/Identity EAP-Response/Identity -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS Start) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS client_hello) -> <- EAP-Request/ EAP-Type= EAP-Double-TLS (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type= EAP-Double-TLS (TLS Alert message) -> <- EAP-Failure (User Disconnected) 4 EAP-Double-TLS protocol within EAP Smartcards EAP-support in smartcards is described and detailed by an Internet draft [EAPSC]. It is an opened, ISO 7816 microcontroller supporting most authentication protocols. An EAP smartcard implements an EAP method (EAP-TLS, etc) and works in cooperation with a smartcard interface entity, which transparently sends and receives EAP messages to and from this component. Smartcard is one of the news technologies added to the world of information technology. In fact, they can make significant impact on current computer systems and network environments because of their inherent security and mobility. Further, they are an effective means of adding enhanced protection to wireless networks; namely 802.11 wireless LAN. Added to that, they are widely used in the Global System for Mobile Communication (GSM) [GSM] in the form of a SIM (Subscriber Identity Module) card for secure access to the mobile network, for storing basic network information and for accounting/billing procedures. Badra & Urien Informational - Expires May 2005 12 INTERNET DRAFT EAP-Double-TLS November 2004 Smartcards have a bear particular attraction, as they generally considered as the most secure computing platform. In fact, they offer good tamper resistance. This means that certain physical hardware and software protections are used, which makes it difficult to extract or modify private and secret information in the module. So it seems a good idea to store the (strong) master_secret keys on a smartcard. Further, smartcard deployment in a typical network such as WLAN 802.11 [802.11] offers the enhanced functionality of tighter authentication. 4.1 Fragmentation issues Data is exchanged between the terminal and the smartcard through a card acceptance device (CAD) in the form of messages exchanged from the terminal to the card and vice versa. Data transport is established by using Data Pocket called Application Protocol Data Unit (APDU). Each APDU consists of two fields: 5 bytes header and 0- 255 bytes of data. The ISO [ISOAPDU] standard defines these command/response packets that are used for reading, writing and exchanging data between the host and the smartcard. These packets transferred from the CAD to the module (command APDU) are followed by a response APDU from the module back to the CAD. The TLS Record Layer fragments information blocks into TLS records carrying data in chunks of 16384 bytes or less [TLS]. Furthermore, TLS message may carry multiple TLS records. Since the IEEE 802.3 MAC may not send frames greater than 1518 bytes in length and because fragmentation support is not provided by EAP, it is the responsibility of EAP methods to provide the fragmentation required. For that, EAP-Double-TLS extends the EAP-TLS segmentation method, which defines a segmentation process that splits TLS messages in smaller blocks, acknowledged by the recipient. In our implementation, the RADIUS server generates acknowledged requests and the supplicant answers by acknowledged responses. EAP-TLS defines the fragmentation mechanism for data exchanged between the server and the terminal. It will not define the data segmentation between the terminal and the smartcard because the latter is not readable to the EAP-TLS server. For that and in order to allow smartcards use, a double segmentation mechanism was introduces by our EAP-Double-TLS to forward TLS packets to the smartcard. We defined this mechanism as following. First, TLS server messages are divided in smaller segments (E1, E2), whose size is typically 1400 bytes or less (figure 2). Next, the segments are encapsulated in EAP-Double-TLS packets that are split in a collection of APDUs (A11 .. A1p .. An1 .. Anq) in the form of ISO7816 commands. Afterwards, the APDUs (each APDUs size is around 240 bytes) are forwarded to the EAP-Double-TLS smartcard. Note that for each APDU received by the smartcard, an APDU response, with 2 bytes of data, is generated to inform the supplicant of the APDUs status (if the APDU was arrived and correctly processed or no). Badra & Urien Informational - Expires May 2005 13 INTERNET DRAFT EAP-Double-TLS November 2004 EAP-Double-TLS Supplicant Authentication Smartcard Smartcard interface server +---------------------+ +-------------+ +--------------+ | | | | | | TLS EAP-Double-TLS EAP-Double-TLS TLS ----- --------- --------- ----- Send: TLS message M1 = E1 .. En EAP-Double-TLS: E1 <= 1400 octets <-- Frag E1 = A11 .. A1p <-- APDU : Frag A11 (<= 240 octets) APDU --> Ack A11 . . . . <-- APDU : Frag A1p (<= 240 octets) APDU --> Ack A1p Ack E1 --> . . . . EAP-Double-TLS: En <= 1400 octets <-- Frag En = An1 .. Alq <-- APDU : Frag An1 (<= 240 octets) APDU --> Ack Ap1 . . . . <-- APDU : Frag Anq (<= 240 octets) <---- Receive: TLS message M1 Send: TLS message M2= F1 .. Fk = A1 .. Ak EAP-Double-TLS: F1 (<= 240 octets) --> <-- EAP-TLS . Ack F1 . . . . Badra & Urien Informational - Expires May 2005 14 INTERNET DRAFT EAP-Double-TLS November 2004 reassembly M2 fragments and send the result using packets of 1400 octets or less --> . <-- EAP-TLS . Ack EAP-Double-TLS: Fi (<= 240 octets) --> <-- EAP-TLS . Ack Fi . EAP-Double-TLS: Fk . (<= 240 octets) --> . . <-- EAP-TLS . Ack Fk --> Receive: TLS message M2 Figure 2 - Smartcard double segmentation using EAP-Double-TLS Authentication Protocol However, for the smartcard part and in order to prevent multiple segmentation and re-assembly operations, the maximum EAP message length of a no fragmented packet SHALL be set to 240 bytes. For a fragmented EAP message, the maximum length value shall be 240 bytes. As defined in EAP-TLS, when the EAP-Double-TLS smartcard receives an EAP-Request packet with the M bit set, it MUST respond with an EAP- Response with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK. 5 Detailed description of the EAP-Double-TLS protocol This section shows the conversation between the peer and the authenticator using EAP-Double-TLS protocol. It takes the same notifications introduced in the section 4 of RFC2716 [EAPTLS]. 5.1 EAP-Double-TLS Packet Format A summary of the EAP-Double-TLS Request/Response packet format is shown below. The fields are transmitted from left to right. Badra & Urien Informational - Expires May 2005 15 INTERNET DRAFT EAP-Double-TLS November 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The description of the EAP/Response/identity is detailed according to the IETF RFC 2284. 5.2 EAP-Double-TLS Request Packet A summary of the EAP-Double-TLS Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=01 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flag | EAP-Double-TLS Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-Double-TLS Message Length | EAP-Double-TLS Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Double-TLS Response fields. Type TBD - EAP Double TLS Badra & Urien Informational - Expires May 2005 16 INTERNET DRAFT EAP-Double-TLS November 2004 Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |L M S R R R R R| +-+-+-+-+-+-+-+-+ L = Length included M = More fragments S = EAP-Double-TLS start R = Reserved The L bit (length included) is set to indicate the presence of the four octet Double-TLS Message Length field, and MUST be set for the first fragment of a fragmented EAP-Double-TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. The S Bit (EAP-Double-TLS start) is set in an EAP-Double- TLS Start message. This differentiates the EAP-Double-TLS Start message from a fragment acknowledgement. Double-TLS Message Length The Double-TLS Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the Double-TLS message or set of messages that is being fragmented. Double-TLS data The Double-TLS data consists of the encapsulated Double-TLS packet in TLS record format. 5.3 EAP-Double-TLS Response Packet A summary of the EAP-Double-TLS Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=01 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flag | EAP-Double-TLS Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-Double-TLS Message Length | EAP-Double-TLS Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 Badra & Urien Informational - Expires May 2005 17 INTERNET DRAFT EAP-Double-TLS November 2004 Identifier The Identifier field is one octet and MUST match the Identifier field from the corresponding request. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Double-TLS Response fields. Type TBD - EAP Double TLS Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |L M S R R R R R| +-+-+-+-+-+-+-+-+ L = Length included M = More fragments S = EAP-Double-TLS start R = Reserved The L bit (length included) is set to indicate the presence of the four octet Double-TLS Message Length field, and MUST be set for the first fragment of a fragmented EAP-Double-TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. The S Bit (EAP-Double-TLS start) is set in an EAP-Double- TLS Start message. This differentiates the EAP-Double-TLS Start message from a fragment acknowledgement. Double-TLS Message Length The Double-TLS Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the Double-TLS message or set of messages that is being fragmented. Double-TLS data The Double-TLS data consists of the encapsulated Double-TLS packet in TLS record format. Badra & Urien Informational - Expires May 2005 18 INTERNET DRAFT EAP-Double-TLS November 2004 6 Security Considerations The EAP-Double-TLS server MUST stock the session in a secure and protected manner in order to prevent attackers from retrieving the master_secret values and other session's parameters. 6.1 Security claims This section describes EAP-Double-TLS in terms of specific security terminology as required by [EAP]. 6.1.1 Authentication, confidentiality and integrity protection EAP-Double-TLS provides mutual authenticated, encrypted and integrity protected tunnel using TLS resumed Handshake [TLS]. All data (including Success/Failure notification) within the tunnel are then protected against man in the middle and eavesdropping attacks. 6.1.2 Protected cipher suite negotiation TLS Handshake protocol offers an integrated mechanism to protect cipher suite negotiation [TLS]. 6.1.3 User identity protection See sections 3.1 and 3.2. 6.1.4 Replay protection TLS Record protocol [TLS] natively protects against replay attacks using sequence numbers. 6.1.5 Key derivation (and updating) Based on [EAPTLS], EAP-Double-TLS derives Keying material after each successful Handshake happened in its both phases. Phase 1 allows the client and the server to generate a master_secret applying the TLS-PRF on the pre_shared_key, ClientHello.random and ServerHello.random. As stated, EAP-Double-TLS MAY use any inner authentication method that is capable to generate session keys. The inner method is used to refresh the master_secret and the session_id of the session used during the phase 1. Thus, the old master_secret (of the shared session) is used to derive and generate keying material. EAP-Double-TLS uses the TLS-PRF to generate and refresh the master_secret key as following: Badra & Urien Informational - Expires May 2005 19 INTERNET DRAFT EAP-Double-TLS November 2004 Let denote OMS the pre shared key used during phase 1, DMS the master_secret derived during the phase 1, NMS the new master_secret and FK the fresh key generated during the phase 2. DMS is derived as following: DMS = PRF(OMS, "master_secret", ClientHello.random + ServerHello.random)[0..48] This DMS is used to derive keying material used to encrypt and to calculate the MAC of each message. Keys derived from DMS are then delivered to the Access Point for additional keys computation. If the inner method is TLS, then the NMS (or the FK) is generated by applying the PRF on the pre_master_secret of the new TLS session and the new client and server random values exchanged during the TLS Handshake (phase 2). TLS generates also new session that will replace the old session. If the inner method is not TLS, the NMS is generated by applying the PRF on the key generated by the inner method (FK) and the client and server random values exchanged during the phase 1. in this case, both the client and the server refresh the old session's parameters by replacing the NMS with the OMS and the old session_id with the result of the following PRF: PRF(The first 8 bytes of the OMS, "session_id", ClientHello.random + ServerHello.random)[0..32] 6.1.6 Key strength EAP-Double-TLS reuses the TLS-PRF for keys generation (See [TLS]). 6.1.7 Dictionary attack protection EAP-Double-TLS resists against dictionary attacks by offering protection based on strong cryptographic algorithms that are supported by TLS [TLS]. 6.1.8 Fast reconnect While EAP-Double-TLS is based on TLS, fast reconnection option is implicitly included; executing TLS resumed Handshake (as described in phase 1). 6.1.9 Channel binding and man-in-middle-attacks protection EAP-Double-TLS does not explicitly include any channel binding. However, it mitigates man-in-the-middle vulnerabilities via the mutual authentication during phase 1. Badra & Urien Informational - Expires May 2005 20 INTERNET DRAFT EAP-Double-TLS November 2004 6.1.10 Session independence and forward secrecy EAP-Double-TLS independently generates keys per session. For example, executing TLS anonym as an inner method (during phase 2) provides Perfect Forward Secrecy (Deffie-Hellman or temporary RSA are both supported by TLS as key exchange methods). Acknowledgements The authors would like to thank Ahmed Serhrouchni and Ibrahim Hajjeh for their help and their input. This EAP method has been inspired by [EAPTLS] and [TLS]. Thus, it reused extracts of these documents. References [TLS] Dierks, T. et. al, "The TLS Protocol Version 1.0", RFC 2246, November 1998. [SKTLS] Gutmann, P., "Use of Shared Keys in the TLS Protocol", draft-ietf-tls-sharedkeys-02 (expired), October 2003. [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [EAPTLS] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [MD5] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [EAP] Aboba, B. et al., "PPP Extensible Authentication Protocol EAP)", RFC 3748, June 2004. [EAPTTLS] Funk, P. and Blake-Wilson, S., "EAP Tunneled TLS Authentication Protocol", draft-ietf-pppext-eap-ttls-05.txt (work in progress), July 2004 [PEAP] Palekar, et. al., "Protected EAP Protocol (PEAP) Version 2", draft-josefsson-pppext-eap-tls-eap-10 (work in progress), October 2004 [PPPDES] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. [PPP3DES] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. Badra & Urien Informational - Expires May 2005 21 INTERNET DRAFT EAP-Double-TLS November 2004 [EAPSC] Urien, P., et al., 2004. "EAP support in smartcards", draft-urien-eap-smartcard-04.txt, Internet draft (work in progress), August 2004. [GSM] GSM Technical Specification GSM 11.11. Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM ū ME) interface, Version 5.0.0, December 1995. [EAPSIM] Haverinen, H. and J. Salowey, "EAP SIM Authentication", draft-haverinen-pppext-eap-sim-12.txt, Internet draft (work in progress), October 2003. [802.11] IEEE Std. 802.11, IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1997. [ISOAPDU] ISO 7816-4 SmartCard Standard: Part 4: Inter industry Commands for Interchange, 1995. Author's Addresses Mohamad Badra ENST 46 rue Barrault 75013 Paris Phone: NA France Email: Mohamad.Badra@enst.fr Pascal Urien ENST 46 rue Barrault 75013 Paris Phone: NA France Email: Pascal.Urien@enst.fr Intellectual Property Statement 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 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 Badra & Urien Informational - Expires May 2005 22 INTERNET DRAFT EAP-Double-TLS November 2004 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 (2004). 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. Badra & Urien Informational - Expires May 2005 23