[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

  Internet Draft                                               P.Urien
  Document: draft-urien-eap-smartcard-01.txt             A.J. Farrugia
                                                               M.Groot
                                                             G.Pujolle
  Expires:                                                 August 2003

                         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.

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 2003                1

                   Integrating EAP in smartcards          March 2003

Table of Contents

  Status.............................................................1
  Abstract...........................................................1
  Table of Contents..................................................2
  Overview...........................................................2
  Terms..............................................................3
  Identification label...............................................4
  Identification Label Coding Rules..................................4
  Add-Identity.......................................................5
  Delete-Identity....................................................5
  Get-Preferred-Identity.............................................5
  Get-Next-Identity..................................................5
  Get-Subscriber-Profile.............................................6
  Set-Identity.......................................................6
  EAP-Packets........................................................6
  Get-Pairwise-Master-Key (PMK)......................................6
  ISO 7816-4 APDUs...................................................7
     Add-Identity....................................................7
     Delete-Identity.................................................7
     Get-Preferred-Identity..........................................8
     Get-Next-Identity...............................................8
     Get-Subscriber-Profile..........................................8
     Set-Identity....................................................8
     EAP-Packets.....................................................8
     Get-Pairwise-Master-Key.........................................9
  State Machine Sequence............................................10
  Security Considerations...........................................10
     General Considerations.........................................10
     PEAP Consideration.............................................10
  Intellectual Property Right Notice................................11
  Annex 1 (Informative) - EAP/SIM packet detail.....................11
     Annex 2 (Informative) - EAP/MD5 packet details.................15
  Annex 3 (Informative) TLS support.................................17
     Fragment maximum size..........................................17
     EAP/TLS messages format........................................17
     Example of EAP/TLS Authentication..............................17
  Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile
  information.......................................................18
  References........................................................18
  Author's Addresses................................................19


Overview

  All technologies derived from 802.11 specifications such as 802.11a,
  802.11b, 802.11g need a strong security protocols for data privacy,
  integrity and network access. Where the 802.1X [8] specification
  describes the risks and the protocols for the protection of the
  exchanged data during the network connection. The very same


  Urien & All   Informational - Expires August 2003                2

                   Integrating EAP in smartcards          March 2003

  specification remains compatible with other standard for the
  authentication and the network access.
  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 has partly been implemented in the
  smart card has 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.

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

  PMK
  Pairwise Master 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

  Urien & All   Informational - Expires August 2003                3

                   Integrating EAP in smartcards          March 2003

Identification label

  802.1X specification [5] requires an authentication between the
  authenticator or the authentication server (AS) and the supplicant.
  The authentication is embedded in the Extensible Authentication
  Protocol (EAP) RFC2284 [1] specification. The authentication
  consists of a challenge response between both parties without
  consideration of the involved crypto-suite. Before starting the
  mutual authentication, the AS needs the supplicant identity to
  establish the session. The AS or the authenticator sends an EAP
  Request Identity to the supplicant that returns its system identity.
  A user may own several identities likely associated to the network
  operators.

  The identification label is a pointer to a system identity 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 smart card is
  able to mirror the authenticator.

  If the smart card is not able to process the authentication related
  to the identity then any setting process is rejected by the NAK
  code.

  The subsequent sections give the description of the methods used by
  a supplicant for processing an 802.1X authentication using the smart
  card.

  Annex one provides a reference implementation example for a SIM
  based authentication. Annex two provides a reference implementation
  example for a MD5 based authentication. Annex three provides a
  reference implementation for a TLS based authentication.

Identification Label Coding Rules

  The Get-Next-Identity section didnÆt define the coding rules of the
  identification label. 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.


  Urien & All   Informational - Expires August 2003                4

                   Integrating EAP in smartcards          March 2003

Add-Identity

  This command and the Delete-Identity are part of the userÆs identity
  management protocols. The smart card is initially manufactured
  without any identification label. The personalization or the
  supplicant software adds in the smart card userÆs identification
  label that can be retrieved by other smart card command.

  If the smart card manages pseudonyms the command does not allows
  setting the user pseudonyms. The smart card command only adds
  permanent identification label in the list.

Delete-Identity

  This command and the add-Identity are part of the userÆs identity
  management protocols. The smart card contains a list of one or
  several identification labels that can be retrieved by the
  supplication software. The command deletes one entry of the smart
  card list.

Get-Preferred-Identity

  The smart card contains at least one userÆs identity related to the
  userÆs network subscription. The supplicant software gets from the
  smart card the initial and preferred identification label. If the
  user has more than one identities the supplicant software uses the
  Get-Next-Identity to read all the available other userÆs identities.
  If the smart card manages pseudonyms and a pseudonym is available as
  preferred identity, the Get-Preferred-Identity shall return the
  pseudonym.

Get-Next-Identity

  The smart card may contain one or more userÆs identities according
  to the userÆs network subscriptions. The supplicant software should
  prompt the userÆs identity and a subsequent selection allows the
  smart card to process the appropriate EAP authentication type. The
  method Get-Next-Identity allows the supplicant software to read all
  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.

  If the smart card contains a pseudonym management and the pseudonym
  is (are) available the Get-Next-Identity returns the appropriate
  pseudonym. If the pseudonym management is not supported, the smart
  card returns the permanent Identity according to the previous
  section.


  Urien & All   Informational - Expires August 2003                5

                   Integrating EAP in smartcards          March 2003

Get-Subscriber-Profile

  The Authentication Agent or the authenticator may request the
  subscriber profile information. The Get-Subscriber-Profile returns
  all related information available in the smart card. This
  specification does not provide the detail of the subscriber profile
  information. The implementation of the information may be ruled but
  ASN.1 BER coding specification [9] or by an XML dialect [10].

Set-Identity

  Once the Identity selection is processed, the supplicant software
  needs to set the smart card EAP framework according to the selected
  userÆs identity. The Set-Identity sets or restarts the smart card
  EAP framework state machine for further processing using the EAP-
  Packets method.

  The supplicant software can set the EAP framework using the
  pseudonym if available in the smart card. If the pseudonym is not
  available the supplicant software uses the permanent identity to set
  the EAP framework according to the previous section.

EAP-Packets

  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 smart card EAP framework state machine
  for further processing using the EAP-Packets method.

  The smart card receives the RFC 2284 frames. It retrieves the
  appropriate EAP authentication type in the frame and the identifier.
  The smart card maintains the EAP state machine and returns an EAP
  NAK packet if the state sequence is broken. Any EAP request is
  silently ignored if the state machine was not started.

  The last step of the protocol retrieving the Pairwise Master Key
  from the smart card can be accomplished only if the last EAP packet
  received from the authentication is an EAP success packet.

Get-Pairwise-Master-Key (PMK)

  At the end of a successful authentication the supplicant needs to
  update the appropriate crypto suite using the master session key.
  The Get-Pairwise-Master-Key returns to the supplicant software the
  key to initialize radio security protocols like TKIP, WRAP or CCMP.

  Urien & All   Informational - Expires August 2003                6

                   Integrating EAP in smartcards          March 2003

  For obvious security reasons the Get-Pairwise-Master-Key is
  available only if the smart card has received an EAP success packet.

ISO 7816-4 APDUs

  This section of the document provides an implementation of the
  previous descriptions for an ISO 78176-4 compatible smart card. The
  section does not preclude of the transport protocol used between the
  smart card 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.

Add-Identity

  This command adds an identification label as described in the
  section: Identification Label Coding Rules. The smart card list is
  managed by the smart card. The identification label is appended as
  the last element of the list if the parameter Po is 0x00. If this
  parameter has any value, it represents the identification label
  position.

  +--------+-----+-----+----+----+----+----+
  |Command |Class| INS | P1 | P2 | Lc | Le |
  +--------+-----+-----+----+----+----+----+
  |        | A0  |  16 | 81 | Po | 00 | XX |
  +--------+-----+-----+----+----+----+----+

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 and the smart card
  leave the space empty.

  +--------+-----+-----+----+----+----+----+
  |Command |Class| INS | P1 | P2 | Lc | Le |
  +--------+-----+-----+----+----+----+----+
  |        | A0  |  16 | 82 | Po | 00 | 00 |
  +--------+-----+-----+----+----+----+----+









  Urien & All   Informational - Expires August 2003                7

                   Integrating EAP in smartcards          March 2003

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  |  16 | 02 | 00 | 00 | XX |
  +--------+-----+-----+----+----+----+----+

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  |  16 | 01 | 00 | 00 | XX |
  +--------+-----+-----+----+----+----+----+

Get-Subscriber-Profile

  The command returns the related subscriber profile information
  according to the application requirements and format.

  +--------+-----+-----+----+----+----+----+
  |Command |Class| INS | P1 | P2 | Lc | Le |
  +--------+-----+-----+----+----+----+----+
  |        | A0  |  16 | 08 | 00 | 00 | YY |
  +--------+-----+-----+----+----+----+----+

Set-Identity

  The command resets and initializes the state machine for processing
  the EAP Packets. The first step after this command is an EAP request
  identity packet. If a different EAP packet is sent to the smart card
  the smart card return an EAP NAK response.

  +--------+-----+-----+----+----+----+----+
  |Command |Class| INS | P1 | P2 | Lc | Le |
  +--------+-----+-----+----+----+----+----+
  |        | A0  |  16 | 80 | 00 | XX | 00 |
  +--------+-----+-----+----+----+----+----+

EAP-Packets

  The command is the method for EAP packet management. The smart card
  identifies the EAP packet type and processes the EAP authentication
  according to current state machine. The state machine sequences have

  Urien & All   Informational - Expires August 2003                8

                   Integrating EAP in smartcards          March 2003

  to be respected and the smart card enforces the EAP sequence
  processing.

  +--------+-----+-----+----+----+----+----+
  |Command |Class| INS | P1 | P2 | Lc | Le |
  +--------+-----+-----+----+----+----+----+
  |        | A0  | 80  | 00 | 00 | 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.

  EAP Identity packets are independent of the authentication type and
  can be the same for any type of authentications. 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                          |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Get-Pairwise-Master-Key

  Once the state machine has received the EAP Success packet the
  smartcard process is able to send the Master Key used by the 802.1X
  specification for the crypto-suite.


  Urien & All   Informational - Expires August 2003                9

                   Integrating EAP in smartcards          March 2003

  As an illustration the EAP SIM authentication [2] specifies the
  Pairwise Master Key usage according to the system cryptographic
  suite.

  +--------+-----+-----+----+----+----+----+
  |Command |Class| INS | P1 | P2 | Lc | Le |
  +--------+-----+-----+----+----+----+----+
  |        | A0  | A6  | 00 | 00 | 00 | 20 |
  +--------+-----+-----+----+----+----+----+

State Machine Sequence

  +----------------------+   +----------------------+
  | Get userÆs identity  |>>>| Set userÆs identity  |>>>
  +----------------------+   +----------------------+

  +----------------------+   +----------------------+
  | EAP request/response |>>>| EAP request/response |>>>
  |    Get identity      |   |                      |
  +----------------------+   +----------------------+

  +----------------------+   +----------------------+
  | EAP request/response |>>>|   EAP Notification   |
  |                      |   |       Success        |
  +----------------------+   +----------------------+

Security Considerations

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 smart card.

  The nature of the Internet network does no longer require getting
  physical access to the smart card. Worms, Trojan horses or viruses
  can move to the computing platforms and performs the jobs. It is
  important for a reference implementation to provide the relevant
  level of protection for the new applications but not to create other
  flaws.

  Other consideration have been introduced in [2] to protect the smart
  card against crypto attack and recommends the authentication should
  take place in a PROTECTED ENVIRONMENT.

PEAP Consideration



  Urien & All   Informational - Expires August 2003               10

                   Integrating EAP in smartcards          March 2003

  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 smart card 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 smart card requirements.

Intellectual Property Right Notice

  To be specify according to the author and participant.

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 smart card 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].

   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 2003               11

                   Integrating EAP in smartcards          March 2003

  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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |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           |

  Urien & All   Informational - Expires August 2003               12

                   Integrating EAP in smartcards          March 2003

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | 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 |
  +--------+-----+-----+----+----+----+----+

  The description of the EAP/Request/SIM/Challenge is detailed
  according to [2] incoming SIM data where further information can be
  retrieved.








  Urien & All   Informational - Expires August 2003               13

                   Integrating EAP in smartcards          March 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             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                           MAC                                 |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Urien & All   Informational - Expires August 2003               14

                   Integrating EAP in smartcards          March 2003


  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          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 smart card 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].

   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                    |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Urien & All   Informational - Expires August 2003               15

                   Integrating EAP in smartcards          March 2003


  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 |
  +--------+-----+-----+----+----+-- -+----+

   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          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  Urien & All   Informational - Expires August 2003               16

                   Integrating EAP in smartcards          March 2003

  Further information can be retrieved from the IETF draft document
  [2].

Annex 3 (Informative) TLS support

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.

  Due to smartcard constraints, the maximum EAP message length of a no
  fragmented packet is set to 240 bytes. For a fragmented EAP message,
  the maximum length value is 240 bytes.

  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.

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 8
  +-+-+-+-+-+-+-+-+
  |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

Example of EAP/TLS Authentication

     Smartcard           Authentication Server
                             <- EAP-Request/
                                Identity

  Urien & All   Informational - Expires August 2003               17

                   Integrating EAP in smartcards          March 2003

  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)
  EAP-Response/
  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

Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile
information

  To be defined according to the EAP type.

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.


  Urien & All   Informational - Expires August 2003               18

                   Integrating EAP in smartcards          March 2003

  [6] "The Network Access Identifier" rfc 2486

  [7] "Can you Clone a GSM Smart Card (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)

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: +33 442 365 036
  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









  Urien & All   Informational - Expires August 2003               19


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/