Internet Draft P.Urien Document: draft-urien-eap-smartcard-04.txt A.J. Farrugia M.Groot G.Pujolle J.Abellan Expires: August 2004 EAP-Support in smartcard Status 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. 1 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 August 2004 1 Integrating EAP in smartcards February 2004 Table of Contents 1 Abstract.........................................................1 2 Overview.........................................................3 3 Terms............................................................4 4 Relationship with RFC 2284.......................................4 4.1 EAP multiplexing model......................................4 4.2 EAP smartcards..............................................5 5 Identification label.............................................6 6 UserID Coding Rules..............................................6 7 Mandatory and optional services..................................7 7.1 Add-Identity................................................7 7.2 Delete-Identity.............................................7 7.3 Get-Preferred-Identity......................................7 7.4 Get-Current-Identity........................................7 7.5 Get-Next-Identity...........................................7 7.6 Get-Profile-Data............................................8 7.7 Set-Identity................................................8 7.8 Process-EAP.................................................8 7.9 Get-Session-Key (SK)........................................9 7.10 Get-802.1X-State...........................................9 7.11 Reset-801.1X-State.........................................9 7.12 Method Functions...........................................9 7.13 Relationship with the 802.1X supplicant state machine......9 7.14 Authentication-Status.....................................10 7.15 Multiple EAP Identity selections..........................10 8 Relationships with the Authentication Agent.....................11 9 ISO 7816-4 APDUs................................................11 9.1 ISO 7816 Status Word.......................................11 9.2 PIN Management.............................................12 9.2.1 Verify PIN...........................................12 9.2.2 Change PIN...........................................12 9.2.3 Enable PIN...........................................13 9.2.4 Disable PIN..........................................13 9.2.5 Unblock PIN..........................................13 9.3 Multi-Applications smartcard considerations................13 9.4 Add-Identity...............................................14 9.5 Delete-Identity............................................14 9.6 Get-Preferred-Identity.....................................14 9.7 Get-Current-Identity.......................................15 9.8 Get-Next-Identity..........................................15 9.9 Get-Profile-Data...........................................15 9.10 Set-Identity..............................................16 9.11 Set-Multiple-Identity.....................................16 9.12 Process-EAP...............................................16 9.13 Method Functions..........................................18 9.14 Get-Session-Key...........................................19 9.15 Get-Current-Version.......................................19 9.16 Get-802.1X-State..........................................20 9.17 Reset-802.1X-State........................................20 9.18 Commands summary..........................................21 Urien & All Informational - Expires August 2004 2 Integrating EAP in smartcards February 2004 10 State Machine Sequence.........................................21 10.1 Supplicant software state machine sequence................21 10.2 Smartcard EAP framework state machine sequence............22 11 Security Considerations........................................22 11.1 General Considerations....................................22 11.2 PEAP Consideration........................................23 12 Intellectual Property Right Notice.............................23 13 Annex 1 (Informative) - EAP/SIM packet detail..................23 14 Annex 2 (Informative) - EAP/MD5 packet details.................27 15 Annex 3 (Informative) TLS support..............................29 15.1 Unix time issue...........................................29 15.2 Fragment maximum size.....................................29 15.3 EAP/TLS messages format...................................30 15.4 Example of EAP/TLS Authentication.........................31 16 Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile information...............................................31 16.1 ASN.1 Subscriber Profile Encoding.........................31 16.1.1 EapID...............................................32 16.1.2 EapType.............................................32 16.1.3 Version.............................................32 16.1.4 User Credential.....................................32 16.1.5 UserProfile.........................................32 16.1.6 UserProfile encoding example........................33 17 Annex 5 (Informative) APDUs exchange example...................33 18 References.....................................................34 18 Author's Addresses.............................................35 2 Overview All technologies derived from 802.11 specifications such as 802.11a, 802.11b, 802.11g need strong security protocols for data privacy, integrity and network access. The 802.1X [8] specification describes the risks and the protocols for the protection of the exchanged data during the network connection. 802.1X specification requires the Extensible Authentication Protocol (EAP) to be used as the framework for application dependent authentication processes with a mutual authentication between the supplicant and the authenticator. It is obvious that the role of the supplicant in this specification could partly be implemented in the smartcard as an authentication processing mean. The flexibility of EAP (RFC 2284) specification does not provide a Mandatory-to- implement solution. The structure of the EAP frames allows the applications to identify the EAP type of consequently to operate the appropriate authentication. This draft describes a standard interface to EAP implementation embedded in a smartcard. This device is generally considered as the most secure computing platform. Urien & All Informational - Expires August 2004 3 Integrating EAP in smartcards February 2004 3 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. Authentication Agent: A piece of software implemented in the supplicant that processes the authentication sequence. AS Authentication Server Authenticator: See the IEEE 802.1X specification for a definition of this concept. 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 PIN Personal Identification Number SK Session Key SIM Subscriber Identity Mobile Supplicant: an IEEE 802.1X concept, which in the context of IEEE 802.11 represents a STA (station) seeking to attach to an IEEE 802 LAN via an IEEE 802.1X Port. See the IEEE 802.1X specification for a complete definition. 4 Relationship with RFC 2284 4.1 EAP multiplexing model According to [14], EAP implementations conceptually consist of the three following components: Urien & All Informational - Expires August 2004 4 Integrating EAP in smartcards February 2004 [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including - PPP; - Wired IEEE 802 LANs [IEEE-802.1X]; - IEEE 802.11 wireless LANs [IEEE-802.11]; - UDP (L2TP [RFC2661] and ISAKMP [PIC]); - and TCP [PIC]. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from EAP methods. [c] EAP method. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP layer. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods. 4.2 EAP smartcards An EAP smartcard implements an EAP method and works in cooperation with a smartcard interface entity, that sends and receives EAP messages to/from this component. The simplest form of this interface is a software bridge that forwards EAP messages to smartcard. According to EAP methods complexity and smartcard computing capacities, protocols sub-sets, that donÆt deal with security features may be computed by the smartcard interface entity. +-+-+-+-+-+-+ | EAP method| | Smartcard | +-+-+-+-+-+-+ ! +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | Smartcard | | | | | | Interface | EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Layer | | EAP ! Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! Layer | | Lower ! Layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------>-------------+ Urien & All Informational - Expires August 2004 5 Integrating EAP in smartcards February 2004 5 Identification label 802.1X specification [5] requires an authentication between 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 own several identities associated to corporate networks or operatorsÆ networks. The identification label is a pointer to a system identity (the EAP- ID value returned in the EAP-Identity.response message) stored in smartcard; it may be of various types: 1. A network SSID as described in the 802.11 standard [4]. 2. A userÆs identification (userid) e.g. an ASCII string. A network access identifier, NAI [6] may be used as userid. 3. A pseudonym, e.g. a friendly name. According to the network environment, the supplicant software needs to set the appropriate identity and verifies if the smartcard is able to mirror the authenticator. If the smartcard is not able to process the authentication related to the identity then any setting process is rejected by the NAK code. The subsequent sections give the description of the methods used by a supplicant for processing an 802.1X authentication using the smartcard. Annex one provides a reference implementation example for a SIM based authentication. Annex two provides a reference implementation example for a MD5 based authentication. Annex three provides a reference implementation for a TLS based authentication. Annex four describes the userÆs profile according to the ASN.1 [9] syntax. Annex five illustrates an MD5 authentication scenario that works with an EAP smartcard. 6 UserID Coding Rules This section describes the structure and the architecture of the userid. A userid consists of 2 fields separated by the Internet symbol "@". The right hand side of the "@" symbol is the userid realms while the left hand side is an application dependent and unique identification number. EAP/SIM has defined the userid where the application Urien & All Informational - Expires August 2004 6 Integrating EAP in smartcards February 2004 identification is "1IMSI". Other userid such as email address can be used by the application. 7 Mandatory and optional services Mandatory services must be implemented in any smartcard that claims conformance with this draft. Optional services are not required by basic authentication operations. 7.1 Add-Identity Status: Optional. This command and the Delete-Identity are part of the userÆs identity management protocols. The smartcard is initially manufactured without any identification label. The personalization or the supplicant software adds in the smartcard userÆs identification label that can be retrieved by other smartcard command. 7.2 Delete-Identity Status: Optional This command and the add-Identity are part of the userÆs identity management protocols. The smartcard contains a list of one or several identification labels that can be retrieved by the supplication software. The command deletes one entry of the smartcard list. 7.3 Get-Preferred-Identity Status: Optional The smartcard contains at least one userÆs identity related to the userÆs network subscription. The supplicant software gets from the smartcard the initial and preferred identification label. If the user has more than one identity the supplicant software uses the Get-Next-Identity to read all the available other userÆs identities. 7.4 Get-Current-Identity Status: Mandatory The smartcard contains at least one userÆs identity related to the userÆs network subscription. The supplicant software gets from the smartcard its current identification label. 7.5 Get-Next-Identity Status: Mandatory The smartcard 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 smartcard to process the appropriate EAP authentication type. The method Get-Next-Identity allows the supplicant software to read all the available userÆs identities. The Get-Next-Identity method may inform the supplicant software when all userÆs identities have been read. Otherwise the supplicant Urien & All Informational - Expires August 2004 7 Integrating EAP in smartcards February 2004 software detects the identity list end when it gets again the first identity. 7.6 Get-Profile-Data Status: Optional The Authentication Agent or the authenticator may request the subscriber profile information. The Get-Profile-Data returns all related information available in the smartcard. Details of the subscriber profile information are given in annex 4. The implementation of the information may be ruled but ASN.1 BER coding specification [9] or by an XML dialect [10]. 7.7 Set-Identity Status: Mandatory Once the Identity selection is processed, the supplicant software needs to set the smartcard EAP framework according to the selected userÆs identity. The Set-Identity sets or restarts the smartcard EAP framework state machine for further processing using the EAP-Packets method. 7.8 Process-EAP Status: Mandatory The EAP process is described in the RFC 2284 specification [1] and involves several EAP requests and responses packets, 1) EAP request/response Identity; 2) A suite of EAP request/response related to a particular authentication scenario; and 3) EAP success or failure. The Set-Identity restarts the smartcard EAP framework state machine for further processing using the EAP-Packets method. An incoming EAP/Request/Identity restarts the smartcard EAP framework state machine for further processing using other EAP- Packets methods. The smartcard receives the RFC 2284 frames. It retrieves the appropriate EAP authentication type in the frame and the identifier. The smartcard maintains the EAP state machine and returns an EAP NAK packet if the state sequence is broken. In that case it restarts the AUTHENTICATING state. Any EAP request is silently ignored if the state machine was not started. The last step of the protocol retrieves the session Key from the smartcard. Urien & All Informational - Expires August 2004 8 Integrating EAP in smartcards February 2004 7.9 Get-Session-Key (SK) Status: Mandatory. At the end of a successful authentication the supplicant needs to update the appropriate crypto suite (if any) using the session key. The Get-Session-Key returns to the supplicant software the key to initialize radio security protocols like TKIP, or CCMP. In an 801.1X [5] context, SK should be interpreted as the unicast key. In an 802.11i or WPA context SK should be interpreted as the PMK (Pairwise Master Key). 7.10 Get-802.1X-State. Status: Mandatory. This command returns the current smartcard 802.1X state. 7.11 Reset-801.1X-State. Status: Mandatory. This command forces the EAP smartcard in the AUTHENTICATING state. See section -Relationship with the 802.1X supplicant state machine-. 7.12 Method Functions Status: Optional. EAP smartcards that are not able to completely process an EAP method MAY support some essential security procedures, like for example, -X509 Certificate storage -Random generator -Private key encryption -Private key decryption -Public key encryption -Public key decryption -Symmetric key encryption -Symmetric key decryption 7.13 Relationship with the 802.1X supplicant state machine The supplicant state machine, as described in 802.1x standard is split between the terminal and the smartcard. The smartcard only implements the AUTHENTICATING state. Upon reception of the Set- Identity command smartcard unconditionally transits in the AUTHENTICATING state. Upon reception of the EAP Identity-Request message, smartcard unconditionally moves in the ACQUIRED state, delivers an Identity response message and re-enters the AUTHENTICATING state. In agreement with the 802.1x state machine all EAP requests are processed in the AUTHENTICATING state. The final EAP notification message (either success or failure) indicates the Urien & All Informational - Expires August 2004 9 Integrating EAP in smartcards February 2004 end of the authentication process. If any error occurs during the authentication procedure (reception of NAK or failure messages ...) the smartcard restarts at the AUTHENTICATING state where it will wait for an identity request or the first EAP-Type request. If the EAP smartcard support security features like PIN code or biometric identification, all EAP messages will be silently discard before the occurrence of a successful bearer authentication. reset +-------------------+ +------>+----------------------+ +-->| ACQUIRED | | +-->| AUTHENTICATING |<-+ | +-------------------+ | | +----------------------+ | | | txRspId(reveiveId,| | | | txRspAuth(receivedId,| | | | previousId)| | | | previousId) | | | | previousId= | | | | previousId= | | | | receivedId | | | | reveivedId | | | +-------------------+ | | +--+---+----------+----+ | | | | | | | reqId | | | +----------------+ +--<---+ | +---->--+ | reqAuth | error +--------------------<------------------------+ 7.14 Authentication-Status At any time, the smartcard may return the authentication status. This status may reveal the following situations: 1) No authentication identity has been selected. 2) Authenticating 3) Authentication Success, AUTHENTICATING state restarted. 4) Authentication failure, AUTHENTICATING state restarted. 7.15 Multiple EAP Identity selections Multiple EAP authentications may be processed simultaneously in the same smartcard. If this capability is supported, the following rules apply: 1) Multiple EAP Identities may be selected at the same time. 2) The supplicant software shall indicate in the Set-Identity command short identifier to be associated with the selected EAP identity. Note: If another EAP identity was associated with the same short identity this EAP identity becomes necessarily unlinked and is no longer more possible to accessible to it unless a new set-identity command is processed (in this case the state machine is reset) or unless a different short identity has been also associated with it. The supplicant software shall include this short identifier within the EAP-Packets, Authentication-Status and Get-Session-Key commands Urien & All Informational - Expires August 2004 10 Integrating EAP in smartcards February 2004 to inform which of the selected EAP identities the command is targeted to. The smartcard and the supplicant software shall maintain a separate EAP state machine for each of the different selected EAP identities. Note: the EAP state machine is associated with each EAP identity: whether two or more different short identities are associated to the same EAP identity, the results of EAP-Packets, Authentication-Status and Get-Session-Key commands do not depend on the short identifier used to refer the EAP identity. In other words, there is only one state machine for selected EAP Identity dependently of the short identities associated with it. 8 Relationships with the Authentication Agent The authentication agent is a piece of software implemented in the supplicant that processes the authentication method. This component must be able to detect a smartcard. If this device is not present, or if it silently discards an EAP.request message, then authentication agent must reject all incoming request messages by the NAK code. 9 ISO 7816-4 APDUs This section of the document provides an implementation of the previous descriptions for an ISO 78176-4 compatible smartcard. The section does not preclude of the transport protocol used between the smartcard and the reader. Thus, this specification does not mandate- to-implement any transport protocol such as T=0 or T=1, which are not in the scope of this document. It should be noted that all values are in hex representation. The restriction and security related descriptions are not present in the document. Annexes of this document give implementation examples. Note: Class byte value defined in this section ('A0') shall be interpreted as an implementation example. Other values may be used respecting conventions defined in ISO 78176-4. 9.1 ISO 7816 Status Word According to ISO 7816, the status word SW1,SW2 is a two bytes word, giving information about current operation either success or failure. '90' '00' indicates an operation success '98' '04' indicates one of the following events, - Access Condition not fulfilled, e.g. a pin code presentation is required. - Unsuccessful user PIN verification, at least one attempt left. Urien & All Informational - Expires August 2004 11 Integrating EAP in smartcards February 2004 '98' '40' indicate one of the following events - Unsuccessful user PIN verification, no attempt left - Smartcard blocked '67' 'XX' - Incorrect parameter P3 '6B' 'XX' - Incorrect parameter P1 or P2 '6D' 'XX' - Unknown instruction code (INS) given in the command '6E' 'XX' - Wrong instruction class (CLA) given in the command '6F' 'XX' - Technical problem, not implemented '61 ''XX' - Operation result must be fetched by the ISO Get Response APDU (CLA = 'C0', P3= 'XX') '6C ''XX' - Operation must be performed again, with the LE parameter value sets to 'XX'. '70' '00' - Packet silently discarded. '70' '01' - Authentication failure 9.2 PIN Management Some services may require that the smartcardÆs bearer presents its PIN code. Smartcard returns the '98' '04' status word when itÆs necessary to check the PIN code, before accessing to a particular service (see previous section). A PIN code is typically a four digits decimal number, ASCII encoded, and ranging between '0000' and '9999'. 9.2.1 Verify PIN +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | Verify | A0 | 20 | 00 | 00 | 08 | 00 | +--------+-----+-----+----+----+----+----+ The ISO APDU Verify is used when a PIN code presentation is required Lc is the PIN code length, typically height ASCII encoded bytes. 9.2.2 Change PIN This APDU modifies the user PIN code. Urien & All Informational - Expires August 2004 12 Integrating EAP in smartcards February 2004 +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | Change | A0 | 24 | 00 | 00 | 10 | 00 | +--------+-----+-----+----+----+----+----+ The old PIN (8 bytes) and new PIN (8 bytes) are presented 9.2.3 Enable PIN This APDU enables the user PIN function. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | Enable | A0 | 26 | 00 | 00 | 08 | 00 | +--------+-----+-----+----+----+----+----+ The user PIN code (8 bytes) is presented. 9.2.4 Disable PIN This APDU disables the user PIN function. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | Disable| A0 | 28 | 00 | 00 | 08 | 00 | +--------+-----+-----+----+----+----+----+ The user PIN code is presented. 9.2.5 Unblock PIN This APDU unblocks a smartcard, blocked after three wrong PIN code presentations. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | Unblock| A0 | 2C | 00 | 00 | 10 | 00 | +--------+-----+-----+----+----+----+----+ The user PIN code (8 bytes) and an unblock code (8 bytes) are presented. 9.3 Multi-Applications smartcard considerations A smartcard may store several applications, each of them being identified by a set of bytes referred as the Application IDentifier (AID). Urien & All Informational - Expires August 2004 13 Integrating EAP in smartcards February 2004 The ISO APDU Select is used when itÆs necessary to select an application, able to process one or more EAP authentication scenarios. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | Select | 00 | A4 | 04 | 00 | XX | 00 | +--------+-----+-----+----+----+----+----+ Le is the AID length. According to ISO 7816-7 AID is made of two parts -RID, a mandatory 5 bytes field that identifies a company or a standardization body. -PIX, up to 11 bytes, which identifies an application. 9.4 Add-Identity This command adds an identification label as described in the section: Identification Label Coding Rules. The smartcard list is managed by the smartcard. The identification label is appended as the last element of the list. Identity coding guidelines are not yet specified. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 17 | 00 | 81 | xx | 00 | +--------+-----+-----+----+----+----+----+ 9.5 Delete-Identity This command deletes the identification label as described in the section: Identification Label Coding Rules. The command parameter gives the identification label to be deleted. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 17 | 00 | 82 | xx | 00 | +--------+-----+-----+----+----+----+----+ 9.6 Get-Preferred-Identity This command returns the userÆs preferred identification label as described in the section: Identification Label Coding Rules +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | Urien & All Informational - Expires August 2004 14 Integrating EAP in smartcards February 2004 +--------+-----+-----+----+----+----+----+ | | A0 | 17 | 00 | 02 | 00 | XX | +--------+-----+-----+----+----+----+----+ 9.7 Get-Current-Identity This command returns userÆs current identification label as described in the section: Identification Label Coding Rules. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 18 | 00 | AA | 00 | XX | +--------+-----+-----+----+----+----+----+ If "multiple EAP Identity selection" is not supported, P2 (AA value) shall be set to '00'. If "multiple EAP Identity selection" is supported, P2 (AA value) shall indicate the short identifier associated with the selected EAP identity to which the command is targeted. These short identifiers are coded as described in Set-Identity command. 9.8 Get-Next-Identity This command returns a user identification label as described in the section: Identification Label Coding Rules. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 17 | 00 | 01 | 00 | XX | +--------+-----+-----+----+----+----+----+ 9.9 Get-Profile-Data The command returns the related subscriber profile information according to the application requirements and format. Profile coding rules are defined in annex 4. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 1A | 00 | AA | 00 | YY | +--------+-----+-----+----+----+----+----+ If "multiple EAP Identity selection" is not supported, P2 (AA value) shall be set to '00'. If "multiple EAP Identity selection" is supported, P2 (AA value) shall indicate the short identifier associated with the selected EAP identity to which the command is targeted. These short identifiers are coded as described Urien & All Informational - Expires August 2004 15 Integrating EAP in smartcards February 2004 9.10 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 smartcard the smartcard returns an EAP NAK response. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 16 | 00 | 80 | XX | 00 | +--------+-----+-----+----+----+----+----+ 9.11 Set-Multiple-Identity +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 16 | 00 | 83 | XX | 00 | +--------+-----+-----+----+----+----+----+ 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 smartcard the smartcard returns an EAP NAK response. When "multiple EAP Identity selection" is supported, then the first status byte is '90' and the second one indicates the short identifier (coded in 1 byte) to be associated with the selected identity. 9.12 Process-EAP The command is the method for EAP packet management. The smartcard identifies the EAP packet type and processes the EAP authentication according to current state machine. The state machine sequences have to be respected and the smartcard enforces the EAP sequence processing. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | AA | XX | YY | +--------+-----+-----+----+----+----+----+ The EAP request or response packet lengths are represented by the unknown value XX and YY. The supplicant software should set these elements in accordance with the EAP packet types. Urien & All Informational - Expires August 2004 16 Integrating EAP in smartcards February 2004 If "multiple EAP Identity selection" is not supported, P2 (AA value) shall be set to '00'. If "multiple EAP Identity selection" is supported, P2 (AA value) shall indicate the short identifier associated with the selected EAP identity to which the command is targeted. These short identifiers are coded as described in Set-Identity command. Most EAP request packets will produce an EAP response packet from the smartcard. If no response is to be produced (e.g. packet silently discard because invalid sequence) the smartcard shall inform the client software with an alert status word (70 00). Success and failure packets do not require any response from the EAP client. A "successfully ending of command (90 00)" status word shall be send from the smartcard once a success EAP packet is processed. An alert status word (70 00) shall be send from the smartcard once a failure EAP packet is received. EAP Identity packets are independent of the authentication type; this section of the document provides the packet details. The rest of the EAP packet being authentication protocol dependent, they are detailed in the informative annex of this document. The description of the EAP/Request/Identity is detailed 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 = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 01 | +-+-+-+-+-+-+-+-+ The description of the EAP/Response/identity is detailed 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 01 | | +-+-+-+-+-+-+-+-+ | | User Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note : Command chaining and extended length Urien & All Informational - Expires August 2004 17 Integrating EAP in smartcards February 2004 1) When an incoming EAP packet exceeds 255 bytes, the transport mechanisms for Extended APDU described in ISO/IEC 7816-3 for T=0 and T=1 may be used For T=0 the APDU Command (APDU-C) is split into data strings of at most 255 bytes and transported in the Data Field of a series of consecutive APDU ENVELOPE For T=1 the APDU-C is split into data strings of at most 254 bytes and transported in the Information Field of chained I-blocks. In both cases, on reception of the TPDU the smartcard has to concatenate the successive data strings in order to obtain the original APDU. 2) When an outgoing EAP packet exceeds 256 bytes, the smartcard may use the mechanisms described in ISO/IEC 7816-4, i.e. extended length field (ISO/IEC 7816-4 2002) for T=0 and T=1. For T=0 the APDU response (APDU-R) is split into successive data strings of at most 256 bytes by the card. The Terminal can retrieve them by a series of consecutive GET RESPONSE APDU. For T=1 the APDU-R is split into data strings of at most 254 bytes by the card and transported in the Information Field of chained I- blocks. On reception, the Terminal performs the concatenation of the Information Field of the successive I-blocks to get the APDU-R. The supplicant software shall then reassemble the complete EAP packet before sending it to the authenticator. 9.13 Method Functions. EAP smartcards that are not able to process a specific full EAP method may support some essential security procedures. +------------+-----+-----+----+----+----+----+ | Command |Class| INS | P1 | P2 | Lc | Le | +------------+-----+-----+----+----+----+----+ | Method-FCT | A0 | 60 | zz | AA | xx | yy | +------------+-----+-----+----+----+----+----+ If "multiple EAP Identity selection" is not supported, P2 (AA value) shall be set to æ00Æ. If "multiple EAP Identity selection" is supported, P2 (AA value) shall indicate the short identifier associated with the selected EAP identity to which the command is targeted. These short identifiers are coded as described in Set-Identity Command. xx is the length of the input value. yy is the length of the returned value. P1 identifies a particular function, and is organized according to the following scheme: Urien & All Informational - Expires August 2004 18 Integrating EAP in smartcards February 2004 b7b6 00-Do.Final, 01-Initialize 10-More 11-Reserved b5b4 Function index b3b2b1 Function type 0 X509 Certificate reading 1 Random generator 2 Private key encrypt 3 Private key decrypt 4 Public key encrypt 5 Public key decrypt 6 Symmetric key encrypt 7 Symmetric key decrypt b0 reserved 9.14 Get-Session-Key Once the state machine has received the EAP Success packet the smartcard process is able to send the Session Key used by the 802.1X specification for the crypto-suite. As an illustration the EAP SIM authentication [2] specifies the Session Key usage according to the system cryptographic suite. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | A6 | 00 | AA | 00 | 20 | +--------+-----+-----+----+----+----+----+ If "multiple EAP Identity selection" is not supported, P2 (AA value) shall be set to æ00Æ. If "multiple EAP Identity selection" is supported, P2 (AA value) shall indicate the short identifier associated with the selected EAP identity to which the command is targeted. These short identifiers are coded as described in Set-Identity Command. 9.15 Get-Current-Version This command returns the EAP-Type protocol version and the WLAN-SCC version. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 18 | xx | yy | 00 | 02 | +--------+-----+-----+----+----+----+----+ P1=00, Reserved P1 is the current EAP-Type Urien & All Informational - Expires August 2004 19 Integrating EAP in smartcards February 2004 P2=0, gets the EAP-Type version P2=1, gets the WLAN-SCC version 9.16 Get-802.1X-State This command returns the current smartcard 802.1X state. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 19 | 00 | AA | 00 | 01 | +--------+-----+-----+----+----+----+----+ If "multiple EAP Identity selection" is not supported, P2 (AA value) shall be set to æ00Æ. If "multiple EAP Identity selection" is supported, P2 (AA value) shall indicate the short identifier associated with the selected EAP identity to which the command is targeted. These short identifiers are coded as described in Set-Identity Command. Returned values: 01 No Identity set, EAP messages silently discarded. 02 EAP/Request/Identity received, AUTHENTICATING state. 03 Authentication in progress, AUTHENTICATING state. 04 Success, AUTHENTICATING state, waiting for an EAP/Request 05 Failure, AUTHENTICATING state, waiting for an EAP/Request 06 Error, AUTHENTICATING state, waiting for an EAP/Request 9.17 Reset-802.1X-State This command forces the EAP smartcard to the 802.1X AUTHENTICATING state +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 19 | 10 | AA | 00 | 01 | +--------+-----+-----+----+----+----+----+ If "multiple EAP Identity selection" is not supported, P2 (AA value) shall be set to æ00Æ. If "multiple EAP Identity selection" is supported, P2 (AA value) shall indicate the short identifier associated with the selected EAP identity to which the command is targeted. These short identifiers are coded as described in Set-Identity Command. Returned values: 01 No Identity set, EAP messages silently discarded. 04 Success, AUTHENTICATING state, waiting for an EAP/Request Urien & All Informational - Expires August 2004 20 Integrating EAP in smartcards February 2004 9.18 Commands summary. +------------------------+-----+-----+----+----+----+----+ | Command |Class| INS | P1 | P2 | Lc | Le | +------------------------+-----+-----+----+----+----+----+ | Process-EAP | A0 | 80 | 00 | ii | xx | yy | +------------------------+-----+-----+----+----+----+----+ | Method-FCT | A0 | 60 | zz | ii | xx | yy | +------------------------+-----+-----+----+----+----+----+ | Get-802.1X-State | A0 | 19 | 00 | ii | 00 | 01 | +------------------------+-----+-----+----+----+----+----+ | Set-802.1X-State | A0 | 19 | 10 | ii | 00 | 01 | +------------------------+-----+-----+----+----+----+----+ | Get-Session-Key | A0 | A6 | 00 | ii | 00 | xx | +------------------------+-----+-----+----+----+----+----+ | Get-Profile-Data | A0 | 1A | 00 | ii | 00 | yy | +------------------------+-----+-----+----+----+----+----+ | Get-Current-Identity | A0 | 18 | 00 | ii | 00 | yy | +------------------------+-----+-----+----+----+----+----+ | Get-Next-Identity | A0 | 17 | 00 | 01 | 00 | yy | +------------------------+-----+-----+----+----+----+----+ | Get-Preferred-Identity | A0 | 17 | 00 | 02 | 00 | yy | +------------------------+-----+-----+----+----+----+----+ | Set-Identity | A0 | 16 | 00 | 80 | xx | 00 | +------------------------+-----+-----+----+----+----+----+ | Set-Multiple-Identity | A0 | 16 | 00 | 83 | xx | 00 | +------------------------+-----+-----+----+----+----+----+ | Add-Identity | A0 | 17 | 00 | 81 | xx | 00 | +------------------------+-----+-----+----+----+----+----+ | Delete-Identity | A0 | 17 | 00 | 82 | xx | 00 | +------------------------+-----+-----+----+----+----+----+ | Get-Current-Version | A0 | 18 | xx | yy | 00 | 02 | +------------------------+-----+-----+----+----+----+----+ | Verify-PIN | A0 | 20 | 00 | 00 | 08 | 00 | +------------------------+-----+-----+----+----+----+----+ | Change-PIN | A0 | 24 | 00 | 00 | 10 | 00 | +------------------------+-----+-----+----+----+----+----+ | Enable-PIN | A0 | 26 | 00 | 00 | 08 | 00 | +------------------------+-----+-----+----+----+----+----+ | Disable-PIN | A0 | 28 | 00 | 00 | 08 | 00 | +------------------------+-----+-----+----+----+----+----+ | Unblock-PIN | A0 | 2C | 00 | 00 | 10 | 00 | +------------------------+-----+-----+----+----+----+----+ | Select-AID | A0 | A4 | 04 | 00 | xx | 00 | +------------------------+-----+-----+----+----+----+----+ 10 State Machine Sequence 10.1 Supplicant software state machine sequence Urien & All Informational - Expires August 2004 21 Integrating EAP in smartcards February 2004 +-----------------------+ +-----------------------+ |A-Get userÆs identity |>>>|B-Set userÆs identity |>>> +-----------------------+ +-----------------------+ +---------------------------+ +---------------------------+ |C-send/receive EAP packets |>>>|D-Get-Session-Key | +---------------------------+ +---------------------------+ Transitions: A-B : All available identities received by Get-Next-Identity commands B-C : Set-Identity command successfully performed C-D : Successful ending of EAP-Packets command with no outgoing packet(Status word of the command equals æ9000'). This can be also detected by 'authenticated' status following the Authentication- Status command. D-C : An incoming EAP packet 10.2 Smartcard EAP framework state machine sequence +----------------------+ +----------------------+ | Z-Identity not set |>>>| Y-Authenticating |>>> +----------------------+ +----------------------+ +----------------------+ +----------------------+ | X-Authenticated | | W- Not authenticated | | /Authenticating | | /Authenticating | +----------------------+ +----------------------+ Transitions: Z-Y : An available identity successfully set Y-X : EAP success packet received Y-W : EAP failure packet received X-Y : EAP Request identity packet received W-Y : EAP Request identity packet received 11 Security Considerations 11.1 General 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 [7] fatal flaw does exist when have physical access to the smartcard. The nature of the Internet network does no longer require getting physical access to the smartcard. Worms, Trojan horses or viruses can move to the computing platforms and performs the jobs. It is Urien & All Informational - Expires August 2004 22 Integrating EAP in smartcards February 2004 important for a reference implementation to provide the relevant level of protection for the new applications but not to create other flaws. Other consideration have been introduced in [2] to protect the smartcard against crypto attack and recommends the authentication should take place in a PROTECTED ENVIRONMENT. 11.2 PEAP Consideration Protected Extensible Authentication Protocol (PEAP) [12] is a pre- processing protocol that allows the privacy of data when processing EAP [1] protocol. EAP protocol, as defined in [1], starts by an EAP packet request/Identity. The EAP packet response Identity returns the userÆs identification label with no privacy being not part of [1]. PEAP protocol allows both part of the EAP packet exchange creating a session key that can be for privacy over the subsequent execution of the EAP protocol. This implementation of EAP in the smartcard shall allow performing a PEAP tunnel for privacy. Once PEAP first phase has been successfully preformed, the EAP protocol (or other protocol) has defined shall be performed according the EAP smartcard requirements. 12 Intellectual Property Right Notice To be specify according to the author and participant. 13 Annex 1 (Informative) - EAP/SIM packet detail. The protocol implementation is 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 using ISO 7816-3 TPDU. This section of the document gives the APDU syntax and coding which makes the specification protocol free. The first EAP packet is the EAP Request Identity. This initial packet format complies with [1]. The smartcard returns an EAP response identity according to the IMSI length and the supported version according to [2]. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 05 | YY | +--------+-----+-----+----+----+----+----+ Urien & All Informational - Expires August 2004 23 Integrating EAP in smartcards February 2004 The description of the EAP/Request/identity is detailed according to the IETF RFC 2284 [1]. This EAP packet doesnÆt respect the EAP/SIM format since it is only part of [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 = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 01 | +-+-+-+-+-+-+-+-+ The description of the EAP/Response/identity is detailed 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 01 | | +-+-+-+-+-+-+-+-+ | | | | User Identity | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note the EAP/Response/Identity when returning the userÆs identity that includes the IMSI includes the real coded IMSI in the EAP packet and not the IMSI coded for GSM network. Further information can be retrieved in [3] for the IMSI coding in the SIM during the SIM setting. The user Identity field can contains the userÆs permanent pseudonym or re-authentication identity. 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 | XX | YY | +--------+-----+-----+----+----+----+----+ The description of the EAP/Request/SIM/Start is detailed according to [2] incoming SIM data where further information can be retrieved. 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 Urien & All Informational - Expires August 2004 24 Integrating EAP in smartcards February 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Subtype = 10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_PERM..._REQ | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_FULL..._RES | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_ANY_ID_REQ | Length = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_VERSION_L...| Length | Actual Version List Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported version 1 | Supported version 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported version 3 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The description of the EAP/Response/SIM/Start is detailed according to [2] outgoing SIM data where further information can be retrieved. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Subtype = 10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_NONCE_MT | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NONCE_MT | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_SELECTED | Length = 1 | Select Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_IDENTITY | Length | Actual Identity Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | User Identity (Optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The description of the EAP/Response/SIM/Start is detailed according to [2] outgoing SIM data where further information can be retrieved. The third EAP Packet is the EAP request SIM Challenge as represented in the IETF draft document [2]. Urien & All Informational - Expires August 2004 25 Integrating EAP in smartcards February 2004 +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | XX | 1C | +--------+-----+-----+----+----+----+----+ The description of the EAP/Request/SIM/Challenge is detailed according to [2] incoming SIM data where further information can be retrieved. 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 = 18 | Subtype = 11 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | n*RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_IV | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initialization Vector (Optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_ENCR_DATA | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Data (Optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The description of the EAP/Response/SIM/Challenge is detailed according to [2] outgoing SIM data where further information can be retrieved. Urien & All Informational - Expires August 2004 26 Integrating EAP in smartcards February 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Subtype = 11 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The last EAP Packet is the EAP success notification as represented in the IETF RFC 2284 [2]. +--------+-----+-----+----+----+----+----+ |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 | Identifier | Length = 04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 Annex 2 (Informative) - EAP/MD5 packet details The first EAP packet is the EAP Request Identity. This initial packet format complies with the RFC 2284. The smartcard returns an EAP response identity according to the NAI length. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 05 | YY | +--------+-----+-----+----+----+----+----+ The description of the EAP/Request/identity is detailed 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 = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 01 | +-+-+-+-+-+-+-+-+ Urien & All Informational - Expires August 2004 27 Integrating EAP in smartcards February 2004 The description of the EAP/Response/identity is detailed 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 01 | | |-+-+-+-+-+-+-+-+ Identity Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second EAP Packet is the EAP/request/MD5/challenge as represented in the IETF RFC 2284 [1]. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | XX | 16 | +--------+-----+-----+----+----+----+----+ The description of the EAP/Request/MD5/challenge is detailed 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 04 | | |-+-+-+-+-+-+-+-+ MD5-Challenge.Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The description of the EAP/Response/MD5/challenge is detailed 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 = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 04 | Type_Size=10 | | |-+-+-+-+-+-+-+-+---------------+ MD5 Digest Value | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urien & All Informational - Expires August 2004 28 Integrating EAP in smartcards February 2004 The third EAP Packet is the EAP success notification as represented in the IETF RFC 2284 [1]. +--------+-----+-----+----+----+----+----+ |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 | Identifier | Length = 04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Further information can be retrieved from the IETF draft document [2]. 15 Annex 3 (Informative) TLS support. 15.1 Unix time issue. As mentioned in [15] TLS RFC the client hello message includes a 32 byte random number, whose first 4 bytes are interpreted as the Unix time. As smartcard is not able to maintain a clock, this parameter MUST be added to the EAP-TLS Start message. +--------+-----+-----+----+----+----+----+ |Command |Class| INS | P1 | P2 | Lc | Le | +--------+-----+-----+----+----+----+----+ | | A0 | 80 | 00 | 00 | 0A | YY | +--------+-----+-----+----+----+----+----+ 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 = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 13 | Flag=20 | Unix Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unix Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15.2 Fragment maximum size. A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records, and a TLS certificate message may in principle be as long as 16MB. The group of EAP-TLS messages Urien & All Informational - Expires August 2004 29 Integrating EAP in smartcards February 2004 sent in a single round may thus be larger than the maximum RADIUS packet size of 4096 octets, or the maximum 802 LAN frame size. The chaining and extended length mechanisms identified in this document provide enough extension to manage incoming and outgoing EAP-TLS packets. Then, authenticator shall not necessary follow a specific fragment policy regarding whether EAP-TLS is provided by the smartcard or not. However, 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 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. 15.3 EAP/TLS messages format. 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 | Identifier | Length <= 240 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 13 | Flag | TLS Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLS Message Length | TLS DATA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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-TLS start, set in an EAP-TLS Start message. R = Reserved Urien & All Informational - Expires August 2004 30 Integrating EAP in smartcards February 2004 15.4 Example of EAP/TLS Authentication Smartcard Authentication Server <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start) EAP-Response/ EAP-Type=EAP-TLS TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, TLS certificate_request, TLS server_hello_done) (Fragment 1: L, M bits set) EAP-Response/ EAP-Type=EAP-TLS -> <- PPP EAP-Request/ EAP-Type=EAP-TLS (Fragment 2) EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Success 16 Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile information The subscriber profile is a collection of data associated to every identity. It can be used be the operating system of a wireless terminal in order to get information about user credentials. 16.1 ASN.1 Subscriber Profile Encoding Urien & All Informational - Expires August 2004 31 Integrating EAP in smartcards February 2004 16.1.1 EapID EapID ::= OCTET STRING The EAP-ID associated to the current identity. 16.1.2 EapType EapType ::= INTEGER The EAP type associated to the current identity. 16.1.3 Version Version ::= INTEGER The protocol version associated to an EAP type. 16.1.4 User Credential UserCredential ::= SEQUENCE OF CredentialObject CredentialObject ::= SEQUENCE { ObjectValue SubscriberInformation } SubscriberInformation ::= CHOICE { SSIDList [0] IMPLICIT SEQUENCE OF { SSIDName OCTET STRING }, SubscriberCertificate [1] IMPLICIT SEQUENCE OF { Certificate X509Certificate }, RootCertificate [2] IMPLICIT SEQUENCE OF { Certificate X509Certificate } X509Certificate an ASN.1 definition, as described in [13]. 16.1.5 UserProfile UserProfile ::= SEQUENCE { ThisEapID EapID, ThisEapType EapType, ThisVersion Version, ThisCredential UserCredential } Urien & All Informational - Expires August 2004 32 Integrating EAP in smartcards February 2004 16.1.6 UserProfile encoding example 30 82 xx yy 04 05 31 32 33 34 35 EapID = 1235 02 01 0D EapType = EAP-TLS 02 01 01 Version = 1 30 xx A0 0E 04 05 61 62 63 64 65 SSID = abcde 04 05 66 67 68 69 6A SSID = fghij A1 82 xx yy First X509Certificate Second X509Certificate A2 82 xx yy First Root X509Certificate Second Root X509Certificate 17 Annex 5 (Informative) APDUs exchange example This annex shows ISO 7816 (T=0) TPDUs exchanged between the smartcard and the authentication agent // Select EAP application (AID= 11 22 33 44 55 66 01) Select.request: 00 A4 04 00 07 11 22 33 44 55 66 01 Select.response: 90 00 // Get current identity Get-Current-Identity.request: A0 18 00 00 00 Get-Current-Identity.response 98 04 // !Pin code is requested // PIN code verification (0000) Verify.request: A0 20 00 00 08 30 30 30 30 FF FF FF FF Verify.response: 90 00 // Try again Get-Current-Identity.request: A0 18 00 00 00 Get-Current-Identity.response: 6C 04 Get-Current-Identity.request A0 18 00 00 04 Get-Current-Identity.response: 61 62 63 64 90 00 // Get-Next-Identity() Get-Next-Identity.request: A0 17 00 01 00 Get-Next-Identity.response: 6C 04 Get-Next-Identity.request: A0 17 00 01 04 Get-Next-Identity.response: 61 62 63 64 90 00 // Set-Identity() Set-Identity.request: A0 16 00 80 04 61 62 63 64 Set-Identity.response: 90 00 Urien & All Informational - Expires August 2004 33 Integrating EAP in smartcards February 2004 // Process EAP-Packets() EAP-Packet.request: A0 80 00 00 05 01 A5 00 05 01 EAP-Packet.response: 61 09 GetResponse.request: A0 C0 00 00 09 GetResponse.response: 02 A5 00 09 01 61 62 63 64 90 00 EAP-Packet.request A0 80 00 00 08 01 A6 00 08 04 02 12 34 EAP-Packet.response: 61 16 GetResponse.request: A0 C0 00 00 16 GetResponse.response: 02 A6 00 16 04 10 CF A5 2D CD 63 5F 5C 6D 55 B8 09 FD B7 BB EC 3C 90 00 18 References [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. (NORMATIVE) [2] EAP SIM Authentication, draft-haverinen-pppext-eap-sim-12.txt. [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 Smartcard (SIM)? " From Charles Brookson Chairman GSM Association Security Group [8] Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security [9] ASN.1 standard 2002 edition ISO/IEC 8825.1. http://asn1.elibel.tm.fr/en/standards/index.htm [10] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000 [11] B. Aboba, D. Simon, EAP TLS Authentication Protocol RFC 2716, October 1999. [12] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar, "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap- 05.txt, work-in-progress, September 2002. (INFORMATIVE) Urien & All Informational - Expires August 2004 34 Integrating EAP in smartcards February 2004 [13] PKCS #6: Extended-Certificate Syntax Standard, An RSA Laboratories Technical Note, Version 1.5, Revised November 1, 1993. [14] RFC 2284 bis, draft-ietf-eap-rfc2284bis-08.txt [15] T.Dierks, C.Allen, RFC 2246, "The TLS Protocol Version 1.0", January 1999. 18 Author's Addresses Pascal Urien ENST 46 rue Barrault 75013 Paris Phone: NA France Email: Pascal.Urien@enst.fr Augustin J. Farrugia Impasse des CAMEGIERS Phone: NA Ceyreste, 13600 France Email: afarrugia@csi.com Max de Groot Gemplus Avenue du Pic de Bertagne BP 100, 13881 Gemenos Phone: NA France Email: max.de-groot@gemplus.com Guy Pujolle LIP6 - University Paris 6 8 rue Capitaine Scott Phone: NA Paris 75015 France Email: Guy.Pujolle@lip6.fr Jorge Abellan Axalto. 50, Av Jean Jaures Phone: +33 1 46 00 59 33 Montrouge 92542 France Email: Jorge.abellan@slb.com Urien & All Informational - Expires August 2004 35