Internet Draft Document: draft-urien-eap-smartcard-00.txt P.Urien A.J. Farrugia G.Pujolle M.Groot Expires: April 2002 October 2002 EAP support in smartcards 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 obsolete 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 will describe the interface to the EAP protocol in smartcards, which could store multiple identities associated to Network Access Identifiers. Urien & All Informational - Expires April 2002 1 EAP support in smartcards October 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 Overview...........................................................3 Terms..............................................................3 Identification label...............................................3 Get-Next-Identity..................................................4 Set-Identity.......................................................4 EAP-Packets........................................................5 Get-PairwiseMasterKey (PMK)........................................5 ISO 7816-4 APDUs...................................................5 Get-Next-Identity APDU..........................................5 Set-Identity....................................................5 EAP-Packets.....................................................6 Get-PairwiseMasterKey...........................................6 Security Considerations............................................6 Annex 1 EAP/SIM detailed specification.............................7 Annex 2 EAP/MD5 detailed specification............................11 References........................................................13 Urien & All Informational - Expires April 2002 2 EAP support in smartcards October 2002 Overview 802.11a, 802.11b, 802.11g security requirements. Relation with 802.1x. Extensible Authentication Protocol benefits. Terms 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. AS Authentication Server EAP Extensible Authentication Protocol. GSM Global System for Mobile communications. IMSI International Mobile Subscriber Identifier, used in GSM to identify subscribers. NAI Network Access Identifier PMK Pairwise Master KEy SIM Subscriber Identity Mobile Identification label. 802.1X specification [5] requires an authentication between the authenticator or the authentication server (AS) and the supplicant. The authentication is embedded in the Extensible Authentication Protocol (EAP) RFC2284 [1] specification. The authentication consists of a challenge response between both parties without consideration of the involved crypto-suite. Before starting the mutual authentication, the AS needs the supplicant identity to establish the session. The AS or the authenticator sends an EAP Request Identity to the supplicant that returns its system identity. A user may have several types of identities likely associated to the network operators. Urien & All Informational - Expires April 2002 3 EAP support in smartcards October 2002 The identification label may be of types: 1) The network SSID as described in the 802.11 standard [4]. 2) The NAI [6], the network realms and a server name, for example unique value 1IMSI@realm for SIM based authentication [internet draft]; 3) A user's identification (UID) e.g. an ASCII string, for example a friendly name. According to the identity selection the supplicant software needs to set the appropriate identity and verifies if the smart card is able to mirror the authenticator. If the smart card is not able to process the authentication related to the identity then any setting process is rejected by the failure code. The subsequent sections give the description of the methods used by a supplicant for processing an 802.1X authentication using the smart card. Annex one provides a reference implementation example for a SIM based authentication. Annex one provides a reference implementation example for a MD5 based authentication. Get-Next-Identity. The smart card may contain one or more user's identities according to the user's network subscriptions. The supplicant software should prompt the user's identity and a subsequent selection allows the smart card to process the appropriate EAP authentication type. The method Get-Next-Identity allows the supplicant software to read all available user's identities. The Get-Next-Identity method may inform the supplicant software when all user's identities have been read. If the smart card contains a pseudonym management and the pseudonym is (are) available the Get-Next-Identity returns the appropriate pseudonym. If the pseudonym management is not supported, the smart card returns the permanent Identity according to the previous section. Set-Identity. Once the Identity selection is processed, the supplicant software needs to set the smart card EAP framework according to the selected user's identity. The Set-Identity sets or restarts the smart card EAP framework state machine for further processing using the EAP-Packets method. The supplicant software can set the EAP framework using the pseudonym if available in the smart card. If the pseudonym is not available the supplicant software uses the permanent identity to set the EAP framework according to the previous section. Urien & All Informational - Expires April 2002 4 EAP support in smartcards October 2002 EAP-Packets. The EAP process is described in the RFC 2284 specification [1] and involves several EAP requests and responses packets as described in [2]. - EAP request/response Identity; - EAP request/response start; - EAP request/response challenge; and - EAP success or failure. The smart card receives the RFC 2284 frames. It retrieves the appropriate EAP authentication type in the frame and the identifier. The smart card maintains the EAP state machine and returns an EAP NAK packet if the state sequence is broken. Any EAP request is silently ignored if the state machine was not started. Get-PairwiseMasterKey (PMK) At the end of a successful authentication the supplicant needs to update the appropriate crypto suite using the master session key. The Get-PairewiseMasterKey returns to the supplicant software the key to initialize either TKIP, WRAP or CCMP protocol. ISO 7816-4 APDUs This section of the document provides an implementation of the previous descriptions for an ISO 78176-4 compatible smart card. It should be noted that all values are in hex representation Get-Next-Identity APDU. This command returns an identification label The identity coding rules are not defined in the section of the document yet. Further version of the document will defined these rules. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 16 | 01 | 00 | 00 | xx | +--------+-----+-----+----+----+----+----+ The restriction and security related descriptions are not present in the document. For EAP SIM authentication the userid, is the IMSI and the realm depends upon the operator. Set-Identity. The command resets and initializes the state machine for processing the EAP Packets. The first step after this command is an EAP request identity packet. If a different EAP packet is sent to the smart card the smart card return an EAP NAK response. Urien & All Informational - Expires April 2002 5 EAP support in smartcards October 2002 +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 16 | 80 | 00 | xx | 00 | +--------+-----+-----+----+----+----+----+ EAP-Packets. The command is the only entry point of the EAP authentication managed by the state machine. The state machines have to be respected and the smart card will verify the EAP sequence. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | xx | xx | +--------+-----+-----+----+----+----+----+ Get-PairwiseMasterKey Once the state machine has received the EAP Success packet the SIM process is able to send the Master Key used by the 802.1X specification for the crypto-suite. The EAP SIM authentication draft version 5 [2] specifies the Master Key computing. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | A6 | 00 | 00 | 00 | 16 | +--------+-----+-----+----+----+----+----+ Security Considerations As a reference implementation the previous section provides the details of the EAP authentication using the GSM SIM. This section of the document highlights the new potential risks providers of application may face by re-using deployed networks for other purposes. From the document _can you clone a GSM smart card (SIM)?_ [7] fatal flaw does exist when have physical access to the smart card. The nature of the Internet network does no longer require getting physical access to the smart card. Worms, Trojan horses or viruses can move to the computing platforms and performs the jobs. It is important for a reference implementation to provide the relevant level of protection for the new applications but not to create other flaws. Urien & All Informational - Expires April 2002 6 EAP support in smartcards October 2002 Annex 1 EAP/SIM detailed specification. Note protocol implementations are out of the scope of this document but as a reference implementation this section gives details using the SIM as specified by [3]. Other protocol can be implemented but when using ISO 7816-4 APDU this section of the document gives the syntax and coding. The first EAP packet is the EAP Request Identity. This initial packet format complies with the RFC 2284. The smart card returns an EAP response identity according to the IMSI length. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 05 | 18 | +--------+-----+-----+----+----+----+----+ Detail of the EAP/Request/identity according to the IETF RFC 2284 [1] 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01 | +-+-+-+-+-+-+-+-+ Detail of the EAP/Response/identity according to the IETF RFC 2284 [1] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01 | | |-+-+-+-+-+-+-+-+ IMSI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that this version of the specification does not support the pseudonym management as describe in the EAP SIM Authentication [2]. The second EAP Packet is the EAP request SIM start as represented in the IETF draft document [2]. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 10 | 1B | +--------+-----+-----+----+----+----+----+ Urien & All Informational - Expires April 2002 7 EAP support in smartcards October 2002 Detail of the EAP/Request/SIM/Start according to [2] incoming SIM data Further information can be retrieved from the IETF draft document [2]]. Note. This version of the specification does not support the pseudonym management as described in the EAP SIM Authentication draft [2]. The AT_PERMANENT_IDENTITY_REQ and the AT_IDENTITY_REQ are both silently ignored for this version of the specification. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_PERM..._REQ | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_ID..._REQ | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detail of the EAP/Response/SIM/Start according to [2] outgoing SIM data. Further information can be retrieved from the IETF draft document [2]]. Note. This version of the specification does not support the pseudonym management as described in the EAP SIM authentication draft [2]. The AT_PERMANENT_IDENTITY_REQ, the AT_IDENTITY_REQ and their respective fields are not returned by the SIM yet. Further version of the specification will include this management according to [2]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_NONCE_MT | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NONCE_MT | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urien & All Informational - Expires April 2002 8 EAP support in smartcards October 2002 The third EAP Packet is the EAP request SIM Challenge as represented in the IETF draft document [2]. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 50 | 1B | +--------+-----+-----+----+----+----+----+ Detail of the EAP/Request/SIM/Challenge according to [2] incoming SIM data. The APDU coding Lc is proposed with 3 RAND numbers. Further information can be retrieved from the IETF draft document [2]]. Note. This version of the specification does not support the pseudonym management as described in the EAP SIM authentication draft [2]. The AT_IV and the AT_ENCR_DATA and their respective fields are not returned by the SIM yet and there are both silently ignored for this version of the specification. Further version of the specification will include this management according to [2]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 11 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | n*RAND | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC RAND | Length = 6 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detail of the EAP/Response/SIM/Challenge according to [2] outgoing SIM data. Further information can be retrieved from the IETF draft document [2]]. Note. According to EAP SIM authentication draft [2] this version of the specification does not support the pseudonym management. Urien & All Informational - Expires April 2002 9 EAP support in smartcards October 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 | 11 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC_SRES | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_SRES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urien & All Informational - Expires April 2002 10 EAP support in smartcards October 2002 Annex 2 EAP/MD5 detailed specification. The first EAP packet is the EAP Request Identity. This initial packet format complies with the RFC 2284. The smart card returns an EAP response identity according to the NAI length. +--------+-----+-----+----+----+----+--------------+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+--------------+ | | A0 | 80 | 00 | 00 | 05 | 5+NAI.Length | +--------+-----+-----+----+----+----+--------------+ Detail of the EAP/Request/identity according to the IETF RFC 2284 [1]. 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=1 | Identifier | Length= 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=01 | +-+-+-+-+-+-+-+-+ Detail of the EAP/Response/identity according to the IETF RFC 2284 [1] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response=2 | Identifier | Length= 5+NAI.Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ | Type=01 | | |-+-+-+-+-+-+-+-+ NAI.Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second EAP Packet is the EAP request MD5 challenge as represented in the IETF RFC 2284. +--------+-----+-----+----+----+------- ------------+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+--------------------+----+ | | A0 | 80 | 00 | 00 | 5+Challenge.Length | 15 | +--------+-----+-----+----+----+--------------------+----+ Detail of the EAP/Request/challenge according to the IETF RFC 2284 [1]. Urien & All Informational - Expires April 2002 11 EAP support in smartcards October 2002 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=01 | Identifier | Length 5+Challenge.Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=04 | | |-+-+-+-+-+-+-+-+ MD5-Challenge.Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detail of the EAP/Response/challenge according to the IETF RFC 2284 [1] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response=02 | Identifier | Length=16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=04 | | |-+-+-+-+-+-+-+-+ MD5-Digest.Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The third EAP Packet is the EAP success notification as represented in the IETF RFC 2284. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 04 | 00 | +--------+-----+-----+----+----+-- -+----+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Success=03 | Identifier | Length= 04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Further information can be retrieved from the IETF draft document [2]. Urien & All Informational - Expires April 2002 12 EAP support in smartcards October 2002 References [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. (NORMATIVE) [2] EAP SIM Authentication draft version 5 (INFORMATIVE) [3] GSM Technical Specification GSM 11.11. Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) [4] Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications [5] Standards for Local and Metropolitan Area Networks: Standard for Port based Network Access Control. [6] "The Network Access Identifier" rfc 2486 [7] "Can you Clone a GSM Smart Card (SIM)?" From Charles Brookson Chairman GSM Association Security Group Author's Addresses Pascal Urien Schlumberger Sema 36-38 rue de la Princesse Phone: +33 1 30 08 48 69 BP45 78341 Louveciennes France Email: purien@slb.com Guy Pujolle LIP6 _ University Paris 6 8 rue Capitaine Scott Phone: Paris 75015 France Email: Guy.Pujolle@lip6.fr Augustin J. Farrugia Gemplus 3 Lagoon drive suite 300 Phone Redwood city Email: Augustin.farrugia@gemplus.com 94065 CA, USA Max de Groot Gemplus Avenue du Pic de Bertagne Phone :+33 4 42 36 50 36 BP 100, 13881 Gemenos Email :max.de-groot@gemplus.comk France Urien & All Informational - Expires April 2002 13