Subject: [eap] draft IETF - EAP support in smartcard version 00

From: [email-masked] (pascal urien)
Date: Fri, 25 Oct 2002 13:10:37 +0300

--Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw)"

--Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw)
Content-type: text/plain; charset=iso-8859-1; format=flowed
Content-transfer-encoding: quoted-printable

  Dear Sirs

    Please find enclose for comment and review an internet draft named
      "eap support in smartcard"

    that has been posted to ietf server.

    http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.txt

    and that we will like to present during the next IETF meeting in=
 Atlanta.

This draft has been issued by the two major manufacturers of smartcards=20
(Gemplus and
  Schlumberger, around 80% of world market).

  It is also consider as a reference document by the javacard forum WiFi=20
Task force
  (www.javacardforum.org) which comprises more than 20 companies.

Best Regards.

Pascal Urien.
Schlumberger Smartcard Reseach Center.

>>Date: Tue, 22 Oct 2002 04:48:11 -0700 (PDT)
>>From: Bernard Aboba <[email-masked]>
>>Subject: Re: EAP for smartcard
>>To: Pascal Urien <[email-masked]>
>>Cc: [email-masked], [email-masked],=
 [email-masked],
>>  bertrand du Castel <[email-masked]>
>>X-MIMETrack: Itemize by SMTP Server on SLV-SMTP/CP8(Release 5.0.7 |March=
=20
>>21, 2001) at 10/22/2002
>>  14:47:51,
>>         Serialize by POP3 Server on SLV-SMTP/CP8(Release 5.0.7 |March=20
>> 21, 2001) at
>>  10/22/2002 14:51:48,
>>         Serialize complete at 10/22/2002 14:51:48
>>
>>I'd recommend posting a not to [email-masked] requesting review of your
>>draft.
>
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
>Pascal Urien
>SchlumbergerSema
>Smartcard Research Center
>36-38 rue de la Princesse
>BP45 78431 Louveciennes Cedex.
>T=E9l :  33 1 30 08 48 69
>Fax : 33 1 30 08 45 24
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

--Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<html>
&nbsp;Dear Sirs<br><br>
&nbsp;&nbsp; Please find enclose for comment and review an internet draft
named<br>
&nbsp;&nbsp;&nbsp;&nbsp; &quot;eap support in smartcard&quot;<br>
&nbsp;<br>
&nbsp;&nbsp; that has been posted to ietf server.<br><br>
&nbsp;&nbsp;
<a=
 href=3D"http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.tx=
t" eudora=3D"autourl"><font=
 color=3D"#0000FF"><i><u>http://www.ietf.org/internet-drafts/draft-urien-eap=
-smartcard-00.txt</a><br><br>
</u></i></font>&nbsp;&nbsp; and that we will like to present during the
next IETF meeting in Atlanta.<br><br>
This draft has been issued by the two major manufacturers of smartcards
(Gemplus and<br>
&nbsp;Schlumberger, around 80% of world market).<br><br>
&nbsp;It is also consider as a reference document by the javacard forum
WiFi Task force <br>
&nbsp;(<a href=3D"http://www.javacardforum.org/" eudora=3D"autourl">www.java=
cardforum.org</a>)
which comprises more than 20 companies.<br><br>
Best Regards.<br><br>
Pascal Urien.<br>
Schlumberger Smartcard Reseach Center.<br><br>
<br><br>
<blockquote type=3Dcite class=3Dcite cite><blockquote type=3Dcite class=3Dci=
te cite>Date:
Tue, 22 Oct 2002 04:48:11 -0700 (PDT)<br>
From: Bernard Aboba &lt;[email-masked]&gt;<br>
Subject: Re: EAP for smartcard<br>
To: Pascal Urien &lt;[email-masked]&gt;<br>
Cc: [email-masked], [email-masked],
[email-masked],<br>
&nbsp;bertrand du Castel &lt;[email-masked]&gt;<br>
X-MIMETrack: Itemize by SMTP Server on SLV-SMTP/CP8(Release 5.0.7 |March
21, 2001) at 10/22/2002<br>
&nbsp;14:47:51,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Serialize
by POP3 Server on SLV-SMTP/CP8(Release 5.0.7 |March 21, 2001) at<br>
&nbsp;10/22/2002 14:51:48,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Serialize
complete at 10/22/2002 14:51:48<br><br>
I'd recommend posting a not to [email-masked] requesting review of
your<br>
draft.</blockquote><br>
<font=
 color=3D"#FF0000">-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-=
*-*-*-*-*-*-<br>
</font><font color=3D"#0000FF"><b>Pascal Urien<br>
</font><font color=3D"#000080">Schlumberger</font><font=
 color=3D"#FF0000">S</font><font color=3D"#000080">ema<br>
</b></font><font color=3D"#0000FF"><i>Smartcard Research Center<br>
36-38 rue de la Princesse<br>
BP45 78431 Louveciennes Cedex.<br>
T=E9l :&nbsp; 33 1 30 08 48 69<br>
Fax : 33 1 30 08 45 24<br>
</i></font><font color=3D"#FF0000">-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-=
*-*-*-*-*-*-*-*-*-*-*-*-*-*-</font></blockquote></html>

--Boundary_(ID_1ZWRDw8dRWpvfj+kPrP4Iw)--

--Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w)
Content-type: text/plain; name=draft-urien-eap-smartcard-00.txt;
 x-mac-type=42494E41; x-mac-creator=74747874
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=draft-urien-eap-smartcard-00.txt

   Internet Draft
   Document: draft-urien-EAP-smartcard-00.txt                    P.Urien
                                                           A.J. Farrugia
                                                               G.Pujolle
                                                                 M.Groot
   Expires: April 2002                                      October 2002

                         EAP support in smartcards

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsolete by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   This document will describe the interface to the EAP protocol in
   smartcards, which could store multiple identities associated to
   Network Access Identifiers.

   Urien & All      Informational - Expires April 2002                 1

                        EAP support in smartcards           October 2002

Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Table of Contents..................................................2
   Overview...........................................................3
   Terms..............................................................3
   Identification label...............................................3
   Get-Next-Identity..................................................4
   Set-Identity.......................................................4
   EAP-Packets........................................................5
   Get-PairwiseMasterKey (PMK)........................................5
   ISO 7816-4 APDUs...................................................5
      Get-Next-Identity APDU..........................................5
      Set-Identity....................................................5
      EAP-Packets.....................................................6
      Get-PairwiseMasterKey...........................................6
   Security Considerations............................................6
   Annex 1 EAP/SIM detailed specification.............................7
   Annex 2 EAP/MD5 detailed specification............................11
   References........................................................13

   Urien & All    Informational - Expires April 2002                 2

                        EAP support in smartcards           October 2002

Overview

   802.11a, 802.11b, 802.11g security requirements.

   Relation with 802.1x.

   Extensible Authentication Protocol benefits.

Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.

   AS
   Authentication Server

   EAP
   Extensible Authentication Protocol.

   GSM
   Global System for Mobile communications.

   IMSI
   International Mobile Subscriber Identifier, used in GSM to
   identify subscribers.

   NAI
   Network Access Identifier

   PMK
   Pairwise Master KEy

   SIM
   Subscriber Identity Mobile

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

   Urien & All    Informational - Expires April 2002                 3

                        EAP support in smartcards           October 2002

   The identification label may be of types:

   1) The network SSID as described in the 802.11 standard [4].
   2) The NAI [6], the network realms and a server name, for example
      unique value 1IMSI@realm for SIM based authentication [internet
      draft];
   3) A user's identification (UID) e.g. an ASCII string, for example a
      friendly name.

   According to the identity selection the supplicant software needs to
   set the appropriate identity and verifies if the smart card is able
   to mirror the authenticator.

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

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

   Annex one provides a reference implementation example for a SIM based
   authentication.

   Annex one provides a reference implementation example for a MD5 based
   authentication.

Get-Next-Identity.
   The smart card may contain one or more user's identities according to
   the user's network subscriptions. The supplicant software should
   prompt the user's identity and a subsequent selection allows the
   smart card to process the appropriate EAP authentication type. The
   method Get-Next-Identity allows the supplicant software to read all
   available user's identities. The Get-Next-Identity method may inform
   the supplicant software when all user's identities have been read.

   If the smart card contains a pseudonym management and the pseudonym
   is (are) available the Get-Next-Identity returns the appropriate
   pseudonym. If the pseudonym management is not supported, the smart
   card returns the permanent Identity according to the previous
   section.
Set-Identity.
   Once the Identity selection is processed, the supplicant software
   needs to set the smart card EAP framework according to the selected
   user's identity. The Set-Identity sets or restarts the smart card EAP
   framework state machine for further processing using the EAP-Packets
   method.
   The supplicant software can set the EAP framework using the pseudonym
   if available in the smart card. If the pseudonym is not available the
   supplicant software uses the permanent identity to set the EAP
   framework according to the previous section.

   Urien & All    Informational - Expires April 2002                 4

                        EAP support in smartcards           October 2002

EAP-Packets.
   The EAP process is described in the RFC 2284 specification [1] and
   involves several EAP requests and responses packets as described in
   [2].
     - EAP request/response Identity;
     - EAP request/response start;
     - EAP request/response challenge; and
     - EAP success or failure.
   The smart card receives the RFC 2284 frames. It retrieves the
   appropriate EAP authentication type in the frame and the identifier.
   The smart card maintains the EAP state machine and returns an EAP NAK
   packet if the state sequence is broken. Any EAP request is silently
   ignored if the state machine was not started.

Get-PairwiseMasterKey (PMK)
   At the end of a successful authentication the supplicant needs to
   update the appropriate crypto suite using the master session key. The
   Get-PairewiseMasterKey returns to the supplicant software the key to
   initialize either TKIP, WRAP or CCMP protocol.

ISO 7816-4 APDUs
   This section of the document provides an implementation of the
   previous descriptions for an ISO 78176-4 compatible smart card. It
   should be noted that all values are in hex representation

Get-Next-Identity APDU.
   This command returns an identification label The identity coding
   rules are not defined in the section of the document yet. Further
   version of the document will defined these rules.

   +--------+-----+-----+----+----+----+----+
   |Command |Class| INS | P1 | P2 | Lc | Le |
   +--------+-----+-----+----+----+----+----+
   |        | A0  |  16 | 01 | 00 | 00 | xx |
   +--------+-----+-----+----+----+----+----+

   The restriction and security related descriptions are not present in
   the document.

   For EAP SIM authentication the userid, is the IMSI and the realm
   depends upon the operator.

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

   Urien & All    Informational - Expires April 2002                 5

                        EAP support in smartcards           October 2002

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

EAP-Packets.
   The command is the only entry point of the EAP authentication managed
   by the state machine. The state machines have to be respected and the
   smart card will verify the EAP sequence.

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

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

   The EAP SIM authentication draft version 5 [2] specifies the Master
   Key computing.

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

Security Considerations
   As a reference implementation the previous section provides the
   details of the EAP authentication using the GSM SIM. This section of
   the document highlights the new potential risks providers of
   application may face by re-using deployed networks for other
   purposes. From the document _can you clone a GSM smart card (SIM)?_
   [7] fatal flaw does exist when have physical access to the smart
   card.
   The nature of the Internet network does no longer require getting
   physical access to the smart card. Worms, Trojan horses or viruses
   can move to the computing platforms and performs the jobs. It is
   important for a reference implementation to provide the relevant
   level of protection for the new applications but not to create other
   flaws.

   Urien & All    Informational - Expires April 2002                 6

                        EAP support in smartcards           October 2002

Annex 1 EAP/SIM detailed specification.

   Note protocol implementations are out of the scope of this document
   but as a reference implementation this section gives details using
   the SIM as specified by [3]. Other protocol can be implemented but
   when using ISO 7816-4 APDU this section of the document gives the
   syntax and coding.

   The first EAP packet is the EAP Request Identity. This initial packet
   format complies with the RFC 2284. The smart card returns an EAP
   response identity according to the IMSI length.
   +--------+-----+-----+----+----+----+----+
   |Command |Class| INS | P1 | P2 | Lc | Le |
   +--------+-----+-----+----+----+----+----+
   |        | A0  | 80  | 00 | 00 | 05 | 18 |
   +--------+-----+-----+----+----+----+----+

   Detail of the EAP/Request/identity according to the IETF RFC 2284 [1]
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Request   |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      01       |
   +-+-+-+-+-+-+-+-+

   Detail of the EAP/Response/identity according to the IETF RFC 2284
   [1]
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Response  |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      01       |                Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      01       |                                               |
   |-+-+-+-+-+-+-+-+               IMSI                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Note that this version of the specification does not support the
   pseudonym management as describe in the EAP SIM Authentication [2].

   The second EAP Packet is the EAP request SIM start as represented in
   the IETF draft document [2].

   +--------+-----+-----+----+----+----+----+
   |Command |Class| INS | P1 | P2 | Lc | Le |
   +--------+-----+-----+----+----+----+----+
   |        | A0  | 80  | 00 | 00 | 10 | 1B |
   +--------+-----+-----+----+----+----+----+

   Urien & All    Informational - Expires April 2002                 7

                        EAP support in smartcards           October 2002

   Detail of the EAP/Request/SIM/Start according to [2] incoming SIM
   data

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

   Note. This version of the specification does not support the
   pseudonym management as described in the EAP SIM Authentication draft
   [2]. The AT_PERMANENT_IDENTITY_REQ and the AT_IDENTITY_REQ are both
   silently ignored for this version of the specification.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Request    |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     18        |       10      |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_PERM..._REQ | Length = 1    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_ID..._REQ   | Length = 1    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Detail of the EAP/Response/SIM/Start according to [2] outgoing SIM
   data.

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

   Note. This version of the specification does not support the
   pseudonym management as described in the EAP SIM authentication draft
   [2]. The AT_PERMANENT_IDENTITY_REQ, the AT_IDENTITY_REQ and their
   respective fields are not returned by the SIM yet. Further version of
   the specification will include this management according to [2].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Response   |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      18       |       10      |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_NONCE_MT    | Length = 5    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           NONCE_MT                            |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Urien & All    Informational - Expires April 2002                 8

                        EAP support in smartcards           October 2002

   The third EAP Packet is the EAP request SIM Challenge as represented
   in the IETF draft document [2].

   +--------+-----+-----+----+----+----+----+
   |Command |Class| INS | P1 | P2 | Lc | Le |
   +--------+-----+-----+----+----+----+----+
   |        | A0  | 80  | 00 | 00 | 50 | 1B |
   +--------+-----+-----+----+----+----+----+

   Detail of the EAP/Request/SIM/Challenge according to [2] incoming SIM
   data. The APDU coding Lc is proposed with 3 RAND numbers.

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

   Note. This version of the specification does not support the
   pseudonym management as described in the EAP SIM authentication draft
   [2]. The AT_IV and the AT_ENCR_DATA and their respective fields are
   not returned by the SIM yet and there are both silently ignored for
   this version of the specification. Further version of the
   specification will include this management according to [2].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Request   |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      18       |       11      |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_RAND       | Length        |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
                               n*RAND                              |
                                                                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_MAC RAND   | Length = 6    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          MAC RAND                             |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Detail of the EAP/Response/SIM/Challenge according to [2] outgoing
   SIM data.

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

   Note. According to EAP SIM authentication draft [2] this version of
   the specification does not support the pseudonym management.

   Urien & All    Informational - Expires April 2002                 9

                        EAP support in smartcards           October 2002

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Response   |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      18       |       11      |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AT_MAC_SRES  | Length = 5    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                           MAC_SRES                            |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Urien & All    Informational - Expires April 2002                10

                        EAP support in smartcards           October 2002

Annex 2 EAP/MD5 detailed specification.

   The first EAP packet is the EAP Request Identity. This initial packet
   format complies with the RFC 2284. The smart card returns an EAP
   response identity according to the NAI length.

   +--------+-----+-----+----+----+----+--------------+
   |Command |Class| INS | P1 | P2 | Lc |       Le     |
   +--------+-----+-----+----+----+----+--------------+
   |        | A0  | 80  | 00 | 00 | 05 | 5+NAI.Length |
   +--------+-----+-----+----+----+----+--------------+

   Detail of the EAP/Request/identity according to the IETF RFC 2284
   [1].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Request=1   |  Identifier   |            Length= 5          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=01     |
   +-+-+-+-+-+-+-+-+

   Detail of the EAP/Response/identity according to the IETF RFC 2284
   [1]

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Response=2  |  Identifier   |      Length= 5+NAI.Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
   |   Type=01     |                                               |
   |-+-+-+-+-+-+-+-+               NAI.Value                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The second EAP Packet is the EAP request MD5 challenge as represented
   in the IETF RFC 2284.

   +--------+-----+-----+----+----+------- ------------+----+
   |Command |Class| INS | P1 | P2 |         Lc         | Le |
   +--------+-----+-----+----+----+--------------------+----+
   |        | A0  | 80  | 00 | 00 | 5+Challenge.Length | 15 |
   +--------+-----+-----+----+----+--------------------+----+

   Detail of the EAP/Request/challenge according to the IETF RFC 2284
   [1].

   Urien & All    Informational - Expires April 2002                11

                        EAP support in smartcards           October 2002

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Request=01   |  Identifier   |   Length 5+Challenge.Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type=04    |                                               |
   |-+-+-+-+-+-+-+-+           MD5-Challenge.Value                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Detail of the EAP/Response/challenge according to the IETF RFC 2284
   [1]

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Response=02 |  Identifier   |        Length=16              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=04     |                                               |
   |-+-+-+-+-+-+-+-+               MD5-Digest.Value                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The third EAP Packet is the EAP success notification as represented
   in the IETF RFC 2284.

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Success=03   |  Identifier   |          Length= 04           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Urien & All    Informational - Expires April 2002                12

                        EAP support in smartcards           October 2002

References

   [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol
   (EAP)", RFC 2284, March 1998. (NORMATIVE)

   [2] EAP SIM Authentication draft version 5 (INFORMATIVE)

   [3] GSM Technical Specification GSM 11.11. Digital cellular
   telecommunications system (Phase 2+); Specification of the Subscriber
   Identity Module - Mobile Equipment (SIM - ME)

   [4] Part 11: Wireless LAN Medium Access Control (MAC) and Physical
   Layer (PHY) Specifications

   [5] Standards for Local and Metropolitan Area Networks: Standard for
   Port based Network Access Control.

   [6] "The Network Access Identifier" rfc 2486

   [7] "Can you Clone a GSM Smart Card (SIM)?" From Charles Brookson
   Chairman GSM Association Security Group

   Author's Addresses

   Pascal Urien
   Schlumberger Sema
   36-38 rue de la Princesse      Phone:  +33 1 30 08 48 69
   BP45 78341 Louveciennes France Email:  [email-masked]

   Guy Pujolle
   LIP6 _ University Paris 6
   8 rue Capitaine Scott          Phone:
   Paris 75015 France             Email:  [email-masked]

   Augustin J. Farrugia
   Gemplus
   3 Lagoon drive suite 300       Phone
   Redwood city                   Email: [email-masked]
   94065 CA, USA

   Max de Groot
   Gemplus
   Avenue du Pic de Bertagne      Phone :+33 4 42 36 50 36
   BP 100, 13881 Gemenos          Email :[email-masked]
   France

   Urien & All    Informational - Expires April 2002                13


--Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

--Boundary_(ID_b9yjOB29umnY0JH/Ru3h8w)--