Internet Draft                                               P.Urien
   Document: draft-urien-eap-smartcard-03.txt             A.J. Farrugia
                                                                M.Groot
                                                              G.Pujolle
                                                              J.Abellan
   Expires:                                                  March 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 March 2004              1
 
                      Integrating EAP in smartcards         October 2003
 
 Table of Contents
 
    1 Abstract.........................................................1
    2 Overview.........................................................3
    3 Terms............................................................3
    4 Identification label.............................................4
    5 UserID Coding Rules..............................................5
    6 Mandatory and optional services..................................5
       6.1 Add-Identity................................................5
       6.2 Delete-Identity.............................................5
       6.3 Get-Preferred-Identity......................................6
       6.4 Get-Current-Identity........................................6
       6.5 Get-Next-Identity...........................................6
       6.6 Get-Profile-Data............................................6
       6.7 Set-Identity................................................6
       6.8 Process-EAP.................................................7
       6.9 Get-Session-Key (SK)........................................7
       6.10 Relationship with the 802.1X supplicant state machine......7
       6.11 Authentication-Status......................................8
       6.12 Multiple EAP Identity selections...........................8
    7 Relationships with the Authentication Agent......................9
    8 ISO 7816-4 APDUs.................................................9
       8.1 ISO 7816 Status Word.......................................10
       8.2 PIN Management.............................................10
           8.2.1 Verify PIN...........................................10
           8.2.2 Change PIN...........................................11
           8.2.3 Enable PIN...........................................11
           8.2.4 Disable PIN..........................................11
           8.2.5 Unblock PIN..........................................11
       8.3 Multi-Applications smartcard considerations................12
       8.4 Add-Identity...............................................12
       8.5 Delete-Identity............................................12
       8.6 Get-Preferred-Identity.....................................13
       8.7 Get-Current-Identity.......................................13
       8.8 Get-Next-Identity..........................................13
       8.9 Get-Profile-Data...........................................13
       8.10 Set-Identity..............................................14
       8.11 Set-Multiple-Identity.....................................14
       8.12 Process-EAP...............................................14
       8.13 Get-Session-Key...........................................16
       8.14 Get-Current-Version.......................................17
       8.15 Get-802.1X-State..........................................17
       8.16 Commands summary..........................................18
    9 State Machine Sequence..........................................18
       9.1 Supplicant software state machine sequence.................18
       9.2 Smartcard EAP framework state machine sequence.............19
    10 Security Considerations........................................19
       10.1 General Considerations....................................19
       10.2 PEAP Consideration........................................20
    11 Intellectual Property Right Notice.............................20
    12 Annex 1 (Informative) - EAP/SIM packet detail..................20
 
    Urien & All        Informational - Expires March 2004             2
 
                      Integrating EAP in smartcards         October 2003
 
    13 Annex 2 (Informative) - EAP/MD5 packet details.................24
    14 Annex 3 (Informative) TLS support..............................26
       14.1 Fragment maximum size.....................................26
       14.2 EAP/TLS messages format...................................26
       14.3 Example of EAP/TLS Authentication.........................27
    15 Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber
    profile information...............................................28
       15.1 ASN.1 Subscriber Profile Encoding.........................28
           15.1.1 EapID...............................................28
           15.1.2 EapType.............................................28
           15.1.3 Version.............................................28
           15.1.4 User Credential.....................................28
           15.1.5 UserProfile.........................................29
           15.1.6 UserProfile encoding example........................29
    16 Annex 5 (Informative) APDUs exchange example...................29
    17 References.....................................................30
    18 Author's Addresses.............................................31
 
 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.
 
 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
 
 
    Urien & All        Informational - Expires March 2004             3
 
                      Integrating EAP in smartcards         October 2003
 
    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 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.
 
    Urien & All        Informational - Expires March 2004             4
 
                      Integrating EAP in smartcards         October 2003
 
    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.
 
 5 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
    identification is "1IMSI". Other userid such as email address can be
    used by the application.
 
 6 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.
 
 6.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.
 
 6.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.
 
    Urien & All        Informational - Expires March 2004             5
 
                      Integrating EAP in smartcards         October 2003
 
 
 6.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.
 
 6.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.
 
 6.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
    software detects the identity list end when it gets again the first
    identity.
 
 6.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].
 
 6.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.
 
    The supplicant software can set the EAP framework using the
    pseudonym if available in the smartcard. 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 March 2004             6
 
                      Integrating EAP in smartcards         October 2003
 
 6.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 retrieving the session Key from the
    smartcard can be accomplished only if the last EAP packet received
    from the authentication is an EAP success packet.
 
 6.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.
 
    For obvious security reasons this service is available only if the
    smartcard has received an EAP success packet.
 
    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).
 
 6.10 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
 
    Urien & All        Informational - Expires March 2004             7
 
                      Integrating EAP in smartcards         October 2003
 
    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
    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
     +--------------------<------------------------+
 
 6.11 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.
 
 6.12 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.
 
 
    Urien & All        Informational - Expires March 2004             8
 
                      Integrating EAP in smartcards         October 2003
 
    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
    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.
 
 7 Relationships with the Authentication Agent
 
    The authentication agent is a piece of software implemented in the
    supplicant that processes the authentication sequence. 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.
 
 8 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.
 
 
 
 
 
    Urien & All        Informational - Expires March 2004             9
 
                      Integrating EAP in smartcards         October 2003
 
 8.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.
    '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
 8.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'.
 
   8.2.1 Verify PIN
    +--------+-----+-----+----+----+----+----+
    |Command |Class| INS | P1 | P2 | Lc | Le |
    +--------+-----+-----+----+----+----+----+
    | Verify | A0  |  20 | 00 | 00 | 10 | 00 |
    +--------+-----+-----+----+----+----+----+
 
 
    Urien & All        Informational - Expires March 2004             10
 
                      Integrating EAP in smartcards         October 2003
 
    The ISO APDU Verify is used when a PIN code presentation is required
 
    Le is the PIN code length, typically height ASCII encoded bytes.
 
   8.2.2 Change PIN
 
    This APDU modifies the user PIN code.
 
    +--------+-----+-----+----+----+----+----+
    |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
 
   8.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.
 
   8.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.
 
   8.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.
 
    Urien & All        Informational - Expires March 2004             11
 
                      Integrating EAP in smartcards         October 2003
 
 
 8.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).
    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.
 
 8.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 |
    +--------+-----+-----+----+----+----+----+
 
 8.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 |
    +--------+-----+-----+----+----+----+----+
 
 
 
 
    Urien & All        Informational - Expires March 2004             12
 
                      Integrating EAP in smartcards         October 2003
 
 8.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 |
    +--------+-----+-----+----+----+----+----+
    |        | A0  |  17 | 00 | 02 | 00 | XX |
    +--------+-----+-----+----+----+----+----+
 
 8.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.
 
 8.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 |
    +--------+-----+-----+----+----+----+----+
 
 8.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 |
    +--------+-----+-----+----+----+----+----+
 
    Urien & All        Informational - Expires March 2004             13
 
                      Integrating EAP in smartcards         October 2003
 
 
    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
 
 8.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 |
    +--------+-----+-----+----+----+----+----+
 
 8.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.
 8.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 |
    +--------+-----+-----+----+----+----+----+
 
    Urien & All        Informational - Expires March 2004             14
 
                      Integrating EAP in smartcards         October 2003
 
    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.
 
    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                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    Urien & All        Informational - Expires March 2004             15
 
                      Integrating EAP in smartcards         October 2003
 
 
    Note : Command chaining and extended length
 
    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.
 
 8.13 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.
 
 
    Urien & All        Informational - Expires March 2004             16
 
                      Integrating EAP in smartcards         October 2003
 
 
 8.14 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
    P2=0, gets the EAP-Type version
    P2=1, gets the WLAN-SCC version
 
 8.15 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
 
 
 
 
 
 
 
 
 
 
    Urien & All        Informational - Expires March 2004             17
 
                      Integrating EAP in smartcards         October 2003
 
 8.16 Commands summary.
 
     +------------------------+-----+-----+----+----+----+----+
     |         Command        |Class| INS | P1 | P2 | Lc | Le |
     +------------------------+-----+-----+----+----+----+----+
     |       Process-EAP      | A0  |  80 | 00 | ii | xx | yy |
     +------------------------+-----+-----+----+----+----+----+
     |    Get-802.1X-State    | A0  |  19 | 00 | 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 |
     +------------------------+-----+-----+----+----+----+----+
 
 9 State Machine Sequence
 
 9.1 Supplicant software state machine sequence
    +-----------------------+   +-----------------------+
    |A-Get userÆs identity  |>>>|B-Set userÆs identity  |>>>
    +-----------------------+   +-----------------------+
    +---------------------------+   +---------------------------+
    |C-send/receive EAP packets |>>>|D-Get-Session-Key          |
    +---------------------------+   +---------------------------+
 
    Urien & All        Informational - Expires March 2004             18
 
                      Integrating EAP in smartcards         October 2003
 
 
    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
 
 9.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
 
 10 Security Considerations
 
 10.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
    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 March 2004             19
 
                      Integrating EAP in smartcards         October 2003
 
    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.
 
 10.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 has defined shall be performed according
    the EAP smartcard requirements.
 
 11 Intellectual Property Right Notice
 
    To be specify according to the author and participant.
 
 12 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 |
    +--------+-----+-----+----+----+----+----+
 
    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].
 
 
 
 
 
    Urien & All        Informational - Expires March 2004             20
 
                      Integrating EAP in smartcards         October 2003
 
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Request    |  Identifier   |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 18   | Subtype = 10  |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |AT_PERM..._REQ | Length = 1    |           Reserved            |
 
    Urien & All        Informational - Expires March 2004             21
 
                      Integrating EAP in smartcards         October 2003
 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |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].
 
    +--------+-----+-----+----+----+----+----+
    |Command |Class| INS | P1 | P2 | Lc | Le |
    +--------+-----+-----+----+----+----+----+
    |        | A0  | 80  | 00 | 00 | XX | 1C |
    +--------+-----+-----+----+----+----+----+
 
 
 
 
    Urien & All        Informational - Expires March 2004             22
 
                      Integrating EAP in smartcards         October 2003
 
    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.
 
     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            |
 
    Urien & All        Informational - Expires March 2004             23
 
                      Integrating EAP in smartcards         October 2003
 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           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          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 13 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    |
    +-+-+-+-+-+-+-+-+
 
    The description of the EAP/Response/identity is detailed according
    to the IETF RFC 2284 [1].
 
 
 
 
 
 
    Urien & All        Informational - Expires March 2004             24
 
                      Integrating EAP in smartcards         October 2003
 
     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          |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    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 |
    +--------+-----+-----+----+----+-- -+----+
 
    Urien & All        Informational - Expires March 2004             25
 
                      Integrating EAP in smartcards         October 2003
 
 
     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].
 
 14 Annex 3 (Informative) TLS support
 
 14.1 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
    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.
 
 14.2 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             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 
    Urien & All        Informational - Expires March 2004             26
 
                      Integrating EAP in smartcards         October 2003
 
    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
 
 14.3 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
 
 
 
    Urien & All        Informational - Expires March 2004             27
 
                      Integrating EAP in smartcards         October 2003
 
 15 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.
 
 15.1 ASN.1 Subscriber Profile Encoding
 
   15.1.1 EapID
 
    EapID ::= OCTET STRING
 
    The EAP-ID associated to the current identity.
 
   15.1.2 EapType
 
    EapType ::= INTEGER
 
    The EAP type associated to the current identity.
 
   15.1.3 Version
 
    Version ::= INTEGER
 
    The protocol version associated to an EAP type.
 
   15.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].
 
 
 
    Urien & All        Informational - Expires March 2004             28
 
                      Integrating EAP in smartcards         October 2003
 
 
   15.1.5 UserProfile
 
    UserProfile ::= SEQUENCE {
    ThisEapID   EapID,
    ThisEapType EapType,
    ThisVersion Version,
    ThisCredential UserCredential
    }
 
   15.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
 
 16 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
 
 
    Urien & All        Informational - Expires March 2004             29
 
                      Integrating EAP in smartcards         October 2003
 
 
    // 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
 
    // 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
 
 17 References
 
    [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol
    (EAP)", RFC 2284, March 1998. (NORMATIVE)
 
    [2] EAP SIM Authentication draft version 8 (NORMATIVE)
 
    [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
 
 
 
    Urien & All        Informational - Expires March 2004             30
 
                      Integrating EAP in smartcards         October 2003
 
    [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)
 
    [13] PKCS #6: Extended-Certificate Syntax Standard, An RSA
    Laboratories Technical Note, Version 1.5, Revised November 1, 1993.
 
 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 March 2004             31