Subject: [eap] EAP support in smartcard version 01

From: [email-masked] (Pascal Urien)
Date: Sat, 01 Mar 2003 23:31:29 +0100

--=====================_2580330==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Every body,

   New version of the internet draft

  draft-urien-EAP-smartcard-01.txt - EAP support in smartcard

has been dowloaded to the IETF web site.

I hope to meet you again during the next IETF meetinf in SF

Regards

Pascal Urien 
--=====================_2580330==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-urien-EAP-smartcard-01.txt"

  Internet Draft                                               P.Urien=20
  Document: draft-urien-EAP-smartcard-01.txt             A.J. Farrugia=20
                                                               M.Groot=20
                                                             G.Pujolle=20
  Expires:                                                 August 2003=20
  =20
                         EAP-Support in smartcard=20
  =20
  =20
Status=20
  =20
  This document is an Internet-Draft and is in full conformance with=20
  all provisions of Section 10 of RFC 2026.=20
  Internet-Drafts are working documents of the Internet Engineering=20
  Task Force (IETF), its areas, and its working groups.  Note that=20
  other groups may also distribute working documents as Internet-
  Drafts.=20
  Internet-Drafts are draft documents valid for a maximum of six=20
  months and may be updated, replaced, or obsolete by other documents=20
  at any time.  It is inappropriate to use Internet-Drafts as=20
  reference material or to cite them other than as "work in progress."=20
  The list of current Internet-Drafts can be accessed at=20
  http://www.ietf.org/ietf/1id-abstracts.txt =20
  The list of Internet-Draft Shadow Directories can be accessed at=20
  http://www.ietf.org/shadow.html. =20
  =20
Abstract=20
  =20
  This document will describe the interface to the EAP protocol in=20
  smartcards, which could store multiple identities associated to=20
  Network Access Identifiers.=20
  =20
  =20

  Urien & All   Informational - Expires August 2003                1 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
Table of Contents=20
  =20
  Status.............................................................1=20
  Abstract...........................................................1=20
  Table of Contents..................................................2=20
  Overview...........................................................2=20
  Terms..............................................................3=20
  Identification label...............................................4=20
  Identification Label Coding Rules..................................4=20
  Add-Identity.......................................................5=20
  Delete-Identity....................................................5=20
  Get-Preferred-Identity.............................................5=20
  Get-Next-Identity..................................................5=20
  Get-Subscriber-Profile.............................................6=20
  Set-Identity.......................................................6=20
  EAP-Packets........................................................6=20
  Get-Pairwise-Master-Key (PMK)......................................6=20
  ISO 7816-4 APDUs...................................................7=20
     Add-Identity....................................................7=20
     Delete-Identity.................................................7=20
     Get-Preferred-Identity..........................................8=20
     Get-Next-Identity...............................................8=20
     Get-Subscriber-Profile..........................................8=20
     Set-Identity....................................................8=20
     EAP-Packets.....................................................8=20
     Get-Pairwise-Master-Key.........................................9=20
  State Machine Sequence............................................10=20
  Security Considerations...........................................10=20
     General Considerations.........................................10=20
     PEAP Consideration.............................................10=20
  Intellectual Property Right Notice................................11=20
  Annex 1 (Informative) - EAP/SIM packet detail.....................11=20
     Annex 2 (Informative) - EAP/MD5 packet details.................15=20
  Annex 3 (Informative) TLS support.................................17=20
     Fragment maximum size..........................................17=20
     EAP/TLS messages format........................................17=20
     Example of EAP/TLS Authentication..............................17=20
  Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile=20
  information.......................................................18=20
  References........................................................18=20
  Author's Addresses................................................19=20
  =20
  =20
Overview=20
  =20
  All technologies derived from 802.11 specifications such as 802.11a,=20
  802.11b, 802.11g need a strong security protocols for data privacy,=20
  integrity and network access. Where the 802.1X [8] specification=20
  describes the risks and the protocols for the protection of the=20
  exchanged data during the network connection. The very same=20

  Urien & All   Informational - Expires August 2003                2 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  specification remains compatible with other standard for the=20
  authentication and the network access.=20
  802.1X specification requires the Extensible Authentication Protocol=20
  (EAP) to be used as the framework for application dependent=20
  authentication processes with a mutual authentication between the=20
  supplicant and the authenticator. It is obvious that the role of the=20
  supplicant in this specification has partly been implemented in the=20
  smart card has an authentication processing mean. The flexibility of=20
  EAP (RFC 2284) specification does not provide a Mandatory-to-
  implement solution. The structure of the EAP frames allows the=20
  applications to identify the EAP type of consequently to operate the=20
  appropriate authentication.=20

Terms=20
  =20
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20
  document are to be interpreted as described in RFC-2119.=20
  =20
  Authentication Agent: A piece of software implemented in the=20
  supplicant that processes the authentication sequence.=20
  =20
  AS=20
  Authentication Server=20
  =20
  Authenticator: See the IEEE 802.1X specification for a definition of=20
  this concept.=20
  =20
  EAP=20
  Extensible Authentication Protocol.=20
  =20
  GSM=20
  Global System for Mobile communications.=20
  =20
  IMSI=20
  International Mobile Subscriber Identifier, used in GSM to     =20
  identify subscribers.=20
  =20
  NAI=20
  Network Access Identifier=20
  =20
  PMK=20
  Pairwise Master Key=20
  =20
  SIM=20
  Subscriber Identity Mobile=20
  =20
  Supplicant: an IEEE 802.1X concept, which in the context of IEEE=20
  802.11 represents a STA (station) seeking to attach to an IEEE 802=20
  LAN via an IEEE 802.1X Port. See the IEEE 802.1X specification for a=20
  complete definition=20

  Urien & All   Informational - Expires August 2003                3 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
Identification label=20
  =20
  802.1X specification [5] requires an authentication between the=20
  authenticator or the authentication server (AS) and the supplicant.=20
  The authentication is embedded in the Extensible Authentication=20
  Protocol (EAP) RFC2284 [1] specification. The authentication=20
  consists of a challenge response between both parties without=20
  consideration of the involved crypto-suite. Before starting the=20
  mutual authentication, the AS needs the supplicant identity to=20
  establish the session. The AS or the authenticator sends an EAP=20
  Request Identity to the supplicant that returns its system identity.=20
  A user may own several identities likely associated to the network=20
  operators.=20
  =20
  The identification label is a pointer to a system identity stored in=20
  smartcard; it may be of various types:=20
  =20
  1. A network SSID as described in the 802.11 standard [4].=20
  2. A user=92s identification (userid) e.g. an ASCII string. A network=20
  access identifier, NAI [6] may be used as userid.=20
  3. A pseudonym, e.g. a friendly name. =20
  According to the network environment, the supplicant software needs=20
  to set the appropriate identity and verifies if the smart card is=20
  able to mirror the authenticator.=20
  =20
  If the smart card is not able to process the authentication related=20
  to the identity then any setting process is rejected by the NAK=20
  code.=20
  =20
  The subsequent sections give the description of the methods used by=20
  a supplicant for processing an 802.1X authentication using the smart=20
  card.=20
  =20
  Annex one provides a reference implementation example for a SIM=20
  based authentication. Annex two provides a reference implementation=20
  example for a MD5 based authentication. Annex three provides a=20
  reference implementation for a TLS based authentication.=20
  =20
Identification Label Coding Rules=20
  =20
  The Get-Next-Identity section didn=92t define the coding rules of the=20
  identification label. This section describes the structure and the=20
  architecture of the userid. =20
  =20
  A userid consists of 2 fields separated by the Internet symbol "@".=20
  The right hand side of the "@" symbol is the userid realms while the=20
  left hand side is an application dependent and unique identification=20
  number. EAP/SIM has defined the userid where the application=20
  identification is "1IMSI". Other userid such as email address can be=20
  used by the application.=20
  =20

  Urien & All   Informational - Expires August 2003                4 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
Add-Identity=20
  =20
  This command and the Delete-Identity are part of the user=92s identity=20
  management protocols. The smart card is initially manufactured=20
  without any identification label. The personalization or the=20
  supplicant software adds in the smart card user=92s identification=20
  label that can be retrieved by other smart card command.=20
  =20
  If the smart card manages pseudonyms the command does not allows=20
  setting the user pseudonyms. The smart card command only adds=20
  permanent identification label in the list.=20
  =20
Delete-Identity=20
  =20
  This command and the add-Identity are part of the user=92s identity=20
  management protocols. The smart card contains a list of one or=20
  several identification labels that can be retrieved by the=20
  supplication software. The command deletes one entry of the smart=20
  card list.=20
  =20
Get-Preferred-Identity=20
  =20
  The smart card contains at least one user=92s identity related to the=20
  user=92s network subscription. The supplicant software gets from the=20
  smart card the initial and preferred identification label. If the=20
  user has more than one identities the supplicant software uses the=20
  Get-Next-Identity to read all the available other user=92s identities.=20
  If the smart card manages pseudonyms and a pseudonym is available as=20
  preferred identity, the Get-Preferred-Identity shall return the=20
  pseudonym.=20
  =20
Get-Next-Identity=20
  =20
  The smart card may contain one or more user=92s identities according=20
  to the user=92s network subscriptions. The supplicant software should=20
  prompt the user=92s identity and a subsequent selection allows the=20
  smart card to process the appropriate EAP authentication type. The=20
  method Get-Next-Identity allows the supplicant software to read all=20
  the available user=92s identities.=20
  =20
  The Get-Next-Identity method may inform the supplicant software when=20
  all user=92s identities have been read. Otherwise the supplicant=20
  software detects the identity list end when it gets again the first=20
  identity.=20
  =20
  If the smart card contains a pseudonym management and the pseudonym=20
  is (are) available the Get-Next-Identity returns the appropriate=20
  pseudonym. If the pseudonym management is not supported, the smart=20
  card returns the permanent Identity according to the previous=20
  section.=20
  =20

  Urien & All   Informational - Expires August 2003                5 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
Get-Subscriber-Profile=20
  =20
  The Authentication Agent or the authenticator may request the=20
  subscriber profile information. The Get-Subscriber-Profile returns=20
  all related information available in the smart card. This=20
  specification does not provide the detail of the subscriber profile=20
  information. The implementation of the information may be ruled but=20
  ASN.1 BER coding specification [9] or by an XML dialect [10].=20

Set-Identity=20
  =20
  Once the Identity selection is processed, the supplicant software=20
  needs to set the smart card EAP framework according to the selected=20
  user=92s identity. The Set-Identity sets or restarts the smart card=20
  EAP framework state machine for further processing using the EAP-
  Packets method.=20
  =20
  The supplicant software can set the EAP framework using the=20
  pseudonym if available in the smart card. If the pseudonym is not=20
  available the supplicant software uses the permanent identity to set=20
  the EAP framework according to the previous section.=20

EAP-Packets=20
  =20
  The EAP process is described in the RFC 2284 specification [1] and=20
  involves several EAP requests and responses packets,=20
  =20
  1. EAP request/response Identity;=20
  2. A suite of EAP request/response related to a particular=20
  authentication scenario; and=20
  3. EAP success or failure.=20
  =20
  The Set-Identity restarts the smart card EAP framework state machine=20
  for further processing using the EAP-Packets method.=20
  =20
  The smart card receives the RFC 2284 frames. It retrieves the=20
  appropriate EAP authentication type in the frame and the identifier.=20
  The smart card maintains the EAP state machine and returns an EAP=20
  NAK packet if the state sequence is broken. Any EAP request is=20
  silently ignored if the state machine was not started.=20
  =20
  The last step of the protocol retrieving the Pairwise Master Key=20
  from the smart card can be accomplished only if the last EAP packet=20
  received from the authentication is an EAP success packet.=20
  =20
Get-Pairwise-Master-Key (PMK)=20
  =20
  At the end of a successful authentication the supplicant needs to=20
  update the appropriate crypto suite using the master session key.=20
  The Get-Pairwise-Master-Key returns to the supplicant software the=20
  key to initialize radio security protocols like TKIP, WRAP or CCMP.=20

  Urien & All   Informational - Expires August 2003                6 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  For obvious security reasons the Get-Pairwise-Master-Key is=20
  available only if the smart card has received an EAP success packet.=20
  =20
ISO 7816-4 APDUs=20
  =20
  This section of the document provides an implementation of the=20
  previous descriptions for an ISO 78176-4 compatible smart card. The=20
  section does not preclude of the transport protocol used between the=20
  smart card and the reader. Thus, this specification does not=20
  mandate-to-implement any transport protocol such as T=3D0 or T=3D1,=20
  which are not in the scope of this document. It should be noted that=20
  all values are in hex representation.=20
  =20
  The restriction and security related descriptions are not present in=20
  the document. Annexes of this document give implementation examples.=20

Add-Identity=20
  =20
  This command adds an identification label as described in the=20
  section: Identification Label Coding Rules. The smart card list is=20
  managed by the smart card. The identification label is appended as=20
  the last element of the list if the parameter Po is 0x00. If this=20
  parameter has any value, it represents the identification label=20
  position.=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  |  16 | 81 | Po | 00 | XX |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
Delete-Identity=20
  =20
  This command deletes the identification label as described in the=20
  section: Identification Label Coding Rules. The command parameter=20
  gives the identification label to be deleted and the smart card=20
  leave the space empty.=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  |  16 | 82 | Po | 00 | 00 |=20
  +--------+-----+-----+----+----+----+----+=20
  =20

  Urien & All   Informational - Expires August 2003                7 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
Get-Preferred-Identity=20
  =20
  This command returns the user=92s preferred identification label as=20
  described in the section: Identification Label Coding Rules=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  |  16 | 02 | 00 | 00 | XX |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
Get-Next-Identity=20
  =20
  This command returns a user identification label as described in the=20
  section: Identification Label Coding Rules.=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  |  16 | 01 | 00 | 00 | XX |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
Get-Subscriber-Profile=20
  =20
  The command returns the related subscriber profile information=20
  according to the application requirements and format.=20
   =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  |  16 | 08 | 00 | 00 | YY |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
Set-Identity=20
  =20
  The command resets and initializes the state machine for processing=20
  the EAP Packets. The first step after this command is an EAP request=20
  identity packet. If a different EAP packet is sent to the smart card=20
  the smart card return an EAP NAK response.=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  |  16 | 80 | 00 | XX | 00 |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
EAP-Packets=20
  =20
  The command is the method for EAP packet management. The smart card=20
  identifies the EAP packet type and processes the EAP authentication=20
  according to current state machine. The state machine sequences have=20

  Urien & All   Informational - Expires August 2003                8 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  to be respected and the smart card enforces the EAP sequence=20
  processing.=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | XX | YY |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
  The EAP request or response packet lengths are represented by the=20
  unknown value XX and YY. The supplicant software should set these=20
  elements in accordance with the EAP packet types.=20
  =20
  EAP Identity packets are independent of the authentication type and=20
  can be the same for any type of authentications. This section of the=20
  document provides the packet details. The rest of the EAP packet=20
  being authentication protocol dependent, they are detailed in the=20
  informative annex of this document.=20
  =20
  The description of the EAP/Request/identity is detailed according to=20
  the IETF RFC 2284 [1].=20
  =20
   0                   1                   2                   3 =20
   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=206 7 8 9 0 1 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Request    |  Identifier   |          Length =3D 5            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 01   |=20
  +-+-+-+-+-+-+-+-+=20
  =20
  The description of the EAP/Response/identity is detailed according=20
  to the IETF RFC 2284 [1].=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Response   |  Identifier   |            Length             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 01   |                                               |=20
  +-+-+-+-+-+-+-+-+                                               |=20
  |                                                               |=20
  |                        User Identity                          |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

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

  Urien & All   Informational - Expires August 2003                9 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  As an illustration the EAP SIM authentication [2] specifies the=20
  Pairwise Master Key usage according to the system cryptographic=20
  suite.=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | A6  | 00 | 00 | 00 | 20 |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
State Machine Sequence=20
  =20
  +----------------------+   +----------------------+=20
  | Get user=92s identity  |>>>| Set user=92s identity  |>>>=20
  +----------------------+   +----------------------+=20
  =20
  +----------------------+   +----------------------+=20
  | EAP request/response |>>>| EAP request/response |>>>=20
  |    Get identity      |   |                      |=20
  +----------------------+   +----------------------+=20
  =20
  +----------------------+   +----------------------+=20
  | EAP request/response |>>>|   EAP Notification   |=20
  |                      |   |       Success        |=20
  +----------------------+   +----------------------+=20
  =20
Security Considerations=20

General Considerations=20
  =20
  As a reference implementation the previous section provides the=20
  details of the EAP authentication using the GSM SIM. This section of=20
  the document highlights the new potential risks providers of=20
  application may face by re-using deployed networks for other=20
  purposes. From the document [7] fatal flaw does exist when have=20
  physical access to the smart card.=20
  =20
  The nature of the Internet network does no longer require getting=20
  physical access to the smart card. Worms, Trojan horses or viruses=20
  can move to the computing platforms and performs the jobs. It is=20
  important for a reference implementation to provide the relevant=20
  level of protection for the new applications but not to create other=20
  flaws.=20
  =20
  Other consideration have been introduced in [2] to protect the smart=20
  card against crypto attack and recommends the authentication should=20
  take place in a PROTECTED ENVIRONMENT.=20
  =20
PEAP Consideration=20
  =20

  Urien & All   Informational - Expires August 2003               10 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  Protected Extensible Authentication Protocol (PEAP) [12] is a pre-
  processing protocol that allows the privacy of data when processing=20
  EAP [1] protocol. EAP protocol, as defined in [1], starts by an EAP=20
  packet request/Identity. The EAP packet response Identity returns=20
  the user=92s identification label with no privacy being not part of=20
  [1].=20
  =20
  PEAP protocol allows both part of the EAP packet exchange creating a=20
  session key that can be for privacy over the subsequent execution of=20
  the EAP protocol.=20
   =20
  This implementation of EAP in the smart card shall allow performing=20
  a PEAP tunnel for privacy. Once PEAP first phase has been=20
  successfully preformed, the EAP protocol has defined shall be=20
  performed according the EAP smart card requirements.=20
  =20
Intellectual Property Right Notice=20
  =20
  To be specify according to the author and participant.=20
  =20
Annex 1 (Informative) - EAP/SIM packet detail.=20
  =20
  The protocol implementation is out of the scope of this document but=20
  as a reference implementation this section gives details using the=20
  SIM as specified by [3]. Other protocol can be implemented using ISO=20
  7816-3 TPDU. This section of the document gives the APDU syntax and=20
  coding which makes the specification protocol free.=20
  =20
  The first EAP packet is the EAP Request Identity. This initial=20
  packet format complies with [1]. The smart card returns an EAP=20
  response identity according to the IMSI length and the supported=20
  version according to [2].=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | 05 | YY |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
  The description of the EAP/Request/identity is detailed according to=20
  the IETF RFC 2284 [1]. This EAP packet doesn=92t respect the EAP/SIM=20
  format since it is only part of [1].=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Request    |  Identifier   |          Length =3D 5            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 01   |=20
  +-+-+-+-+-+-+-+-+=20
  =20

  Urien & All   Informational - Expires August 2003               11 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  The description of the EAP/Response/identity is detailed according=20
  to the IETF RFC 2284 [1].=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Response   |  Identifier   |            Length             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 01   |                                               |=20
  +-+-+-+-+-+-+-+-+                                               |=20
  |                                                               |=20
  |                         User Identity                         |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
  Note the EAP/Response/Identity when returning the user=92s identity=20
  that includes the IMSI includes the real coded IMSI in the EAP=20
  packet and not the IMSI coded for GSM network. Further information=20
  can be retrieved in [3] for the IMSI coding in the SIM during the=20
  SIM setting.=20
  =20
  The user Identity field can contains the user=92s permanent pseudonym=20
  or re-authentication identity.=20
  The second EAP Packet is the EAP request SIM start as represented in=20
  the IETF draft document [2].=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | XX | YY |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
  The description of the EAP/Request/SIM/Start is detailed according=20
  to [2] incoming SIM data where further information can be retrieved.=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Request    |  Identifier   |            Length             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 18   | Subtype =3D 10  |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |AT_PERM..._REQ | Length =3D 1    |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |AT_FULL..._RES | Length =3D 1    |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |AT_ANY_ID_REQ  | Length =3D 1    |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |AT_VERSION_L...| Length        | Actual Version List Length    |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  | Supported version 1           | Supported version 2           |=20

  Urien & All   Informational - Expires August 2003               12 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  | Supported version 3           | Padding                       |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
  The description of the EAP/Response/SIM/Start is detailed according=20
  to [2] outgoing SIM data where further information can be retrieved.=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Response   |  Identifier   |            Length             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 18   | Subtype =3D 10  |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |AT_NONCE_MT    | Length =3D 5    |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |                                                               |=20
  |                           NONCE_MT                            |=20
  |                                                               |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |  AT_SELECTED  | Length =3D 1    |   Select Version              |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |  AT_IDENTITY  |    Length     | Actual Identity Length        |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |                                                               |=20
  |                User Identity (Optional)                       |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
  The description of the EAP/Response/SIM/Start is detailed according=20
  to [2] outgoing SIM data where further information can be retrieved.=20
  The third EAP Packet is the EAP request SIM Challenge as represented=20
  in the IETF draft document [2].=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | XX | 1C |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
  The description of the EAP/Request/SIM/Challenge is detailed=20
  according to [2] incoming SIM data where further information can be=20
  retrieved. =20
  =20
  =20

  Urien & All   Informational - Expires August 2003               13 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |     Request   |  Identifier   |            Length             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 18   | Subtype =3D 11  |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  | AT_RAND       | Length        |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |                                                               |=20
  |                           n*RAND                              |=20
  |                                                               |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  | AT_MAC        | Length =3D 5    |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |                                                               |=20
  |                              MAC                              |=20
  |                                                               |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  | AT_IV         | Length =3D 5    |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |                                                               |=20
  |               Initialization Vector (Optional)                |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  | AT_ENCR_DATA  | Length        |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |                                                               |=20
  |                Encrypted Data (Optional)                      |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
  The description of the EAP/Response/SIM/Challenge is detailed=20
  according to [2] outgoing SIM data where further information can be=20
  retrieved.=20
  =20
   0                   1                   2                   3 =20
   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=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Response   |  Identifier   |            Length             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 18   | Subtype =3D 11  |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |  AT_MAC       | Length =3D 5    |           Reserved            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |                                                               |=20
  |                           MAC                                 |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

  Urien & All   Informational - Expires August 2003               14 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  =20
  The last EAP Packet is the EAP success notification as represented=20
  in the IETF RFC 2284 [2].=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | 04 | 00 |=20
  +--------+-----+-----+----+----+-- -+----+=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Success    |  Identifier   |          Length =3D 04          |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
Annex 2 (Informative) - EAP/MD5 packet details=20
  =20
  The first EAP packet is the EAP Request Identity. This initial=20
  packet format complies with the RFC 2284. The smart card returns an=20
  EAP response identity according to the NAI length.=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | 05 | YY |=20
  +--------+-----+-----+----+----+----+----+=20
  =20
  The description of the EAP/Request/identity is detailed according to=20
  the IETF RFC 2284 [1].=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Request     |  Identifier   |            Length =3D 5         |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |  Type =3D 01    |=20
  +-+-+-+-+-+-+-+-+=20
  =20
  The description of the EAP/Response/identity is detailed according=20
  to the IETF RFC 2284 [1].=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Response    |  Identifier   |            Length             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 01   |                                               |=20
  |-+-+-+-+-+-+-+-+             Identity Value                    |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

  Urien & All   Informational - Expires August 2003               15 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  =20
  The second EAP Packet is the EAP/request/MD5/challenge as=20
  represented in the IETF RFC 2284 [1].=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | XX | 16 |=20
  +--------+-----+-----+----+----+----+----+=20
  The description of the EAP/Request/MD5/challenge is detailed=20
  according to the IETF RFC 2284 [1].=20
   =20
   0                   1                   2                   3   =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Request    |  Identifier   |           Length              |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 04   |                                               |=20
  |-+-+-+-+-+-+-+-+           MD5-Challenge.Value                 |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
  The description of the EAP/Response/MD5/challenge is detailed=20
  according to the IETF RFC 2284 [1].=20
  =20
   0                   1                   2                   3   =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Response   |  Identifier   |        Length =3D 16            |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 04   |  Type_Size=3D10 |                               |=20
  |-+-+-+-+-+-+-+-+---------------+     MD5 Digest Value          |         =
     =20
  |                                                               |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
  The third EAP Packet is the EAP success notification as represented=20
  in the IETF RFC 2284 [1].=20
  =20
  +--------+-----+-----+----+----+----+----+=20
  |Command |Class| INS | P1 | P2 | Lc | Le |=20
  +--------+-----+-----+----+----+----+----+=20
  |        | A0  | 80  | 00 | 00 | 04 | 00 |=20
  +--------+-----+-----+----+----+-- -+----+=20
   =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |    Success    |  Identifier   |          Length =3D 04          |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20

  Urien & All   Informational - Expires August 2003               16 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  Further information can be retrieved from the IETF draft document=20
  [2].=20
  =20
Annex 3 (Informative) TLS support=20
  =20
Fragment maximum size.=20
  =20
  A single TLS record may be up to 16384 octets in length, but a TLS  =20
  message may span multiple TLS records, and a TLS certificate message=20
  may in principle be as long as 16MB. The group of EAP-TLS messages=20
  sent in a single round may thus be larger than the maximum RADIUS=20
  packet size of 4096 octets, or the maximum 802 LAN frame size. =20
  =20
  Due to smartcard constraints, the maximum EAP message length of a no=20
  fragmented packet is set to 240 bytes. For a fragmented EAP message,=20
  the maximum length value is 240 bytes.=20
  =20
  When the smartcard receives an EAP-Request packet with the M bit=20
  set, it MUST respond with an EAP-Response with EAP-Type=3DEAP-TLS and=20
  no data.  This serves as a fragment ACK.=20
  =20
EAP/TLS messages format.=20
  =20
   0                   1                   2                   3 =20
   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 =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |     Code      |  Identifier   |      Length  <=3D 240           |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |   Type =3D 13   |     Flag      |        TLS Message Length     |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |       TLS Message Length      |          TLS DATA             |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |=20
  |                                                               |=20
  |                                                               |=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  =20
  Flags=20
  0 1 2 3 4 5 6 7 8=20
  +-+-+-+-+-+-+-+-+=20
  |L M S R R R R R|=20
  +-+-+-+-+-+-+-+-+=20
  L =3D Length included.=20
  M =3D More fragments=20
  S =3D EAP-TLS start, set in an EAP-TLS Start message.=20
  R =3D Reserved=20
  =20
Example of EAP/TLS Authentication=20
  =20
     Smartcard           Authentication Server=20
                             <- EAP-Request/=20
                                Identity=20

  Urien & All   Informational - Expires August 2003               17 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  EAP-Response/=20
  Identity (MyID) ->=20
                             <- EAP-Request/=20
                             EAP-Type=3DEAP-TLS=20
                             (TLS Start)=20
  EAP-Response/=20
  EAP-Type=3DEAP-TLS=20
  TLS client_hello)->=20
                             <- EAP-Request/=20
                             EAP-Type=3DEAP-TLS=20
                             (TLS server_hello,=20
                              TLS certificate,=20
                              TLS certificate_request,=20
                              TLS server_hello_done)=20
  EAP-Response/=20
  EAP-Type=3DEAP-TLS=20
  (TLS certificate,=20
   TLS client_key_exchange,=20
   TLS certificate_verify,=20
   TLS change_cipher_spec,=20
   TLS finished) ->=20
                             <- EAP-Request/=20
                             EAP-Type=3DEAP-TLS=20
                             (TLS change_cipher_spec,=20
                              TLS finished)=20
     EAP-Response/=20
     EAP-Type=3DEAP-TLS ->=20
                             <- EAP-Success=20
  =20
Annex 4 (Normative) ASN.1 BER Tag coding for the subscriber profile=20
information=20
  =20
  To be defined according to the EAP type.=20
  =20
References=20
  =20
  [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol=20
  (EAP)", RFC 2284, March 1998. (NORMATIVE)=20
  =20
  [2] EAP SIM Authentication draft version 8 (NORMATIVE)=20
  =20
  [3] GSM Technical Specification GSM 11.11. Digital cellular=20
  telecommunications system (Phase 2+); Specification of the=20
  Subscriber Identity Module - Mobile Equipment (SIM - ME)=20
  =20
  [4] Part 11: Wireless LAN Medium Access Control (MAC) and Physical=20
  Layer (PHY) Specifications=20
  =20
  [5] Standards for Local and Metropolitan Area Networks: Standard for=20
  Port based Network Access Control.=20
  =20

  Urien & All   Informational - Expires August 2003               18 =0C
  =20
                   Integrating EAP in smartcards          March 2003=20
  =20
  [6] "The Network Access Identifier" rfc 2486=20
  =20
  [7] "Can you Clone a GSM Smart Card (SIM)? " From Charles Brookson=20
  Chairman GSM Association Security Group=20
  =20
  [8] Part 11: Wireless Medium Access Control (MAC) and physical layer=20
  (PHY) specifications: Specification for Enhanced Security=20
  =20
  [9] ASN.1 standard 2002 edition ISO/IEC 8825.1.=20
  http://asn1.elibel.tm.fr/en/standards/index.htm=20
  =20
  [10] Extensible Markup Language (XML) 1.0 (Second Edition), W3C=20
  Recommendation 6 October 2000=20
  =20
  [11] B. Aboba, D. Simon, EAP TLS Authentication Protocol RFC 2716,=20
  October 1999.=20
  =20
  [12] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar,=20
  "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-
  05.txt, work-in-progress, September 2002. (INFORMATIVE)=20
  =20
Author's Addresses=20
  =20
  Pascal Urien=20
  ENST=20
  46 rue Barrault=20
  75013 Paris               Phone: NA=20
  France                    Email: [email-masked]=20
  =20
  Augustin J. Farrugia=20
  Impasse des CAMEGIERS     Phone: NA=20
  Ceyreste, 13600 France    Email: [email-masked]=20
  =20
  Max de Groot=20
  Gemplus=20
  Avenue du Pic de Bertagne=20
  BP 100, 13881 Gemenos     Phone: +33 442 365 036=20
  France                    Email: [email-masked]=20
  =20
  Guy Pujolle=20
  LIP6 - University Paris 6=20
  8 rue Capitaine Scott     Phone: NA=20
  Paris 75015 France        Email: [email-masked]=20

  Urien & All   Informational - Expires August 2003               19=20

--=====================_2580330==_--

---

From: [email-masked] (Sebastian Hans)
Date: Mon, 03 Mar 2003 18:12:29 +0100

I would suggest to use instead of the CLA byte A0, the CLA byte AX and 
use the possibilities of logical channels supported by cards comming 
into the market.

Regards

Sebastian Hans

Pascal Urien wrote:
> ------------------------------------------------------------------------
> 
> 
> 
> 
>   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 
>   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 
>   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 
>   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 
>    
>   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, 
>   05.txt, work-in-progress, September 2002. (INFORMATIVE) 
>    
> Author's Addresses 
>    
>   Pascal Urien 
>   ENST 
>   46 rue Barrault 
>   75013 Paris               Phone: NA 
>   France                    Email: [email-masked] 
>    
>   Augustin J. Farrugia 
>   Impasse des CAMEGIERS     Phone: NA 
>   Ceyreste, 13600 France    Email: [email-masked] 
>    
>   Max de Groot 
>   Gemplus 
>   Avenue du Pic de Bertagne 
>   BP 100, 13881 Gemenos     Phone: +33 442 365 036 
>   France                    Email: [email-masked] 
>    
>   Guy Pujolle 
>   LIP6 - University Paris 6 
>   8 rue Capitaine Scott     Phone: NA 
>   Paris 75015 France        Email: [email-masked] 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   Urien & All   Informational - Expires August 2003               19 

-- 
_____________________________________________________________________
Sebastian J. Hans
Java Card Marketing

email: [email-masked]           Sun Microsystems
Tel: +49-(0)30-74 70 96 701             Sebastian J. Hans
Fax: +49-(0)30-74 70 96 99              Komturstrasse 18a
mobile: +49-(0)174-300 75 34            12099 Berlin
                                         Germany
_____________________________________________________________________