One document matched: draft-urien-eap-ssc-00.txt
Internet Draft P.Urien
Document: draft-urien-eap-ssc-00.txt M. Dandjinou
Expires: December 2003
EAP-SSC Secured Smartcard Channel
1 Status
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2 Abstract
This document describes a means of setting up an EAP secured channel
between a smartcard and an Authentication Server AS (e. g. RADIUS
server), as well according to an asymmetric key exchange model as a
symmetric key exchange model. This channel permits to convey in secure
all other types of payload between a smartcard and the AS, for example
the commands which can setup or update the Directory Information Base
(DIB) associated to the LDAP (Lightweight Directory Access Protocol)
in the smartcard.
Urien & All Informational - Expires December 2003 1
EAP-SSC Secured Smartcard Channel June 2003
Table of Contents
1 Status.............................................................1
2 Abstract...........................................................1
4 EAP-SSC Protocol Data Unit.........................................3
4.1 EAP packet format (Informative).................................3
4.2 EAP-SSC packet format...........................................4
4.2.1 Type field...................................................4
4.2.2 Sub-Type field...............................................5
4.2.3 Flags field..................................................6
4.2.4 Message Length field.........................................7
4.2.5 Payload field................................................7
4.2.6 Digest field.................................................8
5 Setting up the Secured Smartcard Channel...........................8
5.1 SessionĘs Key (SK) calculation..................................9
5.1.1 Overview.....................................................9
5.1.2 SessionĘs key exchange - Symmetric case......................9
5.1.3 SessionĘs key calculation - Asymmetric case.................11
5.2 SessionĘs key validation.......................................14
6 Secure Channel Messages exchanges.................................16
7 Segmentation issue................................................16
8 LDAP messages.....................................................17
9 Examples of traces................................................17
9.1 Traces in a symmetrical key exchange context...................17
9.2 Traces in an asymmetrical key exchange context.................19
10 Intellectual Property Right Notice...............................23
11 References.......................................................23
12 Author's Addresses...............................................24
Urien & All Informational - Expires December 2003 2
EAP-SSC Secured Smartcard Channel June 2003
3 Overview
Security is the key problem to solve in all the new technologies that
derived from 802.11 specifications if in the existent networks (PAN,
LAN and MAN) we want to increase quickly their utilization. 802.1X [1]
specifications which add changes to improve 802.11 technologies,
requires the framework of Extensible Authentication Protocol (EAP) RFC
2284bis [2] for application dependent authentication processes with a
mutual authentication between the Supplicant and the Authenticator.
When the Supplicant is partially in a smartcard as it is described in
[3][4], a particular protocol is needed to establish an EAP secured
channel between this part of the Supplicant in the smartcard and the
Authentication Server via the Authenticator. The purpose of this draft
is first to present this new protocol EAP-SSC (Extensible
Authentication Protocol - Secured Smartcard Channel) with its
mechanisms and procedures. Secondly we describe a manner for encoding
the Protocol Data Unit (PDUs) which are used for setting up this
channel. Finally we show how management commands for LDAP [5] [6] [7]
oriented data-base stored on the smartcard are securely embedded in
these PDUs.
4 EAP-SSC Protocol Data Unit
EAP-SSC is an authentication protocol for smartcards based on EAP.
Before showing the format of its PDUs, let us remind the EAP packet
format.
4.1 EAP packet format (Informative)
We present in the figure 1 a summarized EAP packet format according to
the specification of EAP in IETF RFC 2284bis. The fields are
transmitted from left to right.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 : EAP packet format.
The Code field is one byte and identifies the type of EAP packet that
can be assigned with 1 for request packet, 2 for response packet, 3
for successful authentication acknowledgement, and 4 for failure
notification.
Urien & All Informational - Expires December 2003 3
EAP-SSC Secured Smartcard Channel June 2003
The Identifier field is one byte length and allows matching of
responses with requests.
The Length field is two bytes length and corresponds to the length of
the EAP packet including the Code, Identifier, Length and Data fields.
The Data field is zero or more bytes length and its format depends on
the Code field. It is that part which will keep all the
particularities of EAP-SSC.
4.2 EAP-SSC packet format
EAP-SSC packet is encapsulated in the general EAP packet, in its non
zero Data field and is structured like presented in the figure 2
hereafter:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Flags | Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . . Payload . . . .
. .
. .
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Digest +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 : EAP-SSC packet format.
4.2.1 Type field
The Type field is one byte length. As described in RFC 2284bis, all
EAP implementations MUST support Types values 1-4 corresponding to :
1 Identity;
2 Notification;
3 Nak (only for Response messages);
4 MD5-Challenge;
255 Vendor-specific.
Additional EAP types have been defined later :
5 One-Time Password (OTP) (RFC 2289);
6 Generic Token Card (GTC);
13 EAP/TLS (RFC 2716) [8];
18 EAP/SIM (see [9]).
Urien & All Informational - Expires December 2003 4
EAP-SSC Secured Smartcard Channel June 2003
A new value of Type field is requested to IANA for distinguishing EAP
on smartcards from others. In this document the value for EAP-Type
corresponding to EAP-SSC will be denoted EAP-SSC-Type.
The Identity Type is used to query the identity of the Supplicant.
Generally, the Authenticator will issue this as the initial Request.
It is the same type that will be used by the Supplicant to respond
with its identity.
The Notification Type is optionally used to convey a displayable
message from the Authenticator to the Supplicant. The Supplicant
SHOULD display this message to the user or log it if it cannot be
displayed. It is intended to provide an acknowledged notification of
some imperative nature. The Notification Request MAY be used to
indicate an invalid authentication attempt prior to transmitting a new
Identity Request (optionally, the failure MAY be indicated within the
message of the new Identity Request itself).
The Nak Type is valid only in Response messages. It is sent in reply
to a Request where the desired authentication Type is unacceptable.
Authentication Types are numbered 4 and above. This Response contains
the authentication Type desired by the Supplicant.
The MD5-Challenge Type is analogous to the PPP CHAP protocol [10]
(with MD5 as the specified algorithm). The Request contains a
"challenge" message to the Supplicant. A Response MUST be sent in
reply to the Request. The Response MAY be either of Type 4 (MD5-
Challenge) or Type 3 (Nak). The Nak reply indicates the Supplicant's
desired authentication mechanism Type. All EAP implementations MUST
support the MD5-Challenge mechanism.
The One-Time Password system is defined in "A One-Time Password
System" [11]. The Request contains a displayable message containing an
OTP challenge. A Response MUST be sent in reply to the Request. The
Response MUST be of Type 5 (OTP) or Type 3 (Nak). The Nak reply
indicates the Supplicant's desired authentication mechanism Type.
The Generic Token Card Type is defined for use with various Token Card
implementations which require user input. The Request contains an
ASCII text message and the Reply contains the Token Card information
necessary for authentication. Typically, this would be information
read by a user from the Token card device and entered as ASCII text.
The EAP/TLS type is described in [8].
The EAP/SIM type is described in [9].
4.2.2 Sub-Type field
The Sub-Type field allows conveying several families of messages. At
the moment this draft is presented, the following values are used for
the Sub-Type field:
Urien & All Informational - Expires December 2003 5
EAP-SSC Secured Smartcard Channel June 2003
* Sub-type = 1 means that the context of encryption corresponds to the
symmetrical model, i.e. one supposes that the Smartcard and the
Authentication Server share a secrecy commonly called secret key s.
* Sub-type = 2 indicates that the context of encryption employed is
that corresponding to the asymmetrical model or public key encryption,
i.e. the Smartcard and the Authentication Server have each one a
couple of keys (public key, private key) where only the owner of the
private key is supposed to know it, while the public key is provided
to any correspondent for deciphering the coded message that one sends
to him.
In follow-on documents, additional values MAY be defined. Symmetric
and asymmetric key exchange authentication will be described later in
this document.
4.2.3 Flags field
This Flags field is one byte in length and its format depends on the
Sub-Type field. For the Sub-Type values 1-2, the Flags field has the
format shown in the figure 3 hereafter :
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|L M S E D C X R|
+-+-+-+-+-+-+-+-+
Figure 3 : Flags field format for Sub-Type values 1-2.
The bits of the Flags field are interpreted as below:
L = Length included;
M = More fragments;
S = EAP-SSC Start;
E = EAP-SSC End;
D = EAP-SSC Digest;
C = EAP-SSC Ciphered payload;
X = EAP-SSC Sequence of X509 Certificate(s);
R = Reserved.
Bits L, M and S look like that described in EAP-TLS (RFC 2716).
The L bit (Length included) is set to indicate the presence of the
three octets EAP-SSC Message Length field, and MUST be set for the
first fragment of a fragmented EAP-SSC message or set of messages.
The M bit (More fragments) is set on all but last fragment of a
fragmented EAP-SSC message. It means that the contents of this EAP-SSC
packet is not the last part of the message.
When an EAP-SSC Supplicant receives an EAP-Request packet with the M
bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-SSC-
Type and no data. This serves as a fragment Acknowledgement. The
Urien & All Informational - Expires December 2003 6
EAP-SSC Secured Smartcard Channel June 2003
Authentication Server MUST wait until it receives the EAP-Response
before sending another fragment. In order to prevent errors in
processing of fragments, the Authentication Server MUST increment the
Identifier field for each fragment contained within an EAP-Request,
and the Supplicant MUST include this Identifier value in the fragment
Acknowledgement contained within the EAP-Response. Retransmitted
fragments will contain the same Identifier value.
Similarly, when the Authentication Server receives an EAP-Response
with the M bit set, it MUST respond with an EAP-Request with EAP-
Type=EAP-SSC-Type and no data. This serves as a fragment
Acknowledgement. The EAP Supplicant MUST wait until it receives the
EAP-Request before sending another fragment. In order to prevent
errors in the processing of fragments, the Authentication Server MUST
increment the Identifier value for each fragment Acknowledgement
contained within an EAP-Request, and the Supplicant MUST include this
same Identifier value in the subsequent fragment contained within an
EAP-Response.
The S bit (EAP-SSC Start) is set only within the EAP-SSC/Start message
sent from the Authentication Server to the Supplicant. This
differentiates the EAP-SSC/Start message from the others.
The E bit (EAP-SSC End) is set in an EAP-SSC/End message sent from the
Authentication Server to the Supplicant. This differentiates the EAP-
SSC/End message from other messages.
The D bit (EAP-SSC Digest) is set if an EAP-SSC message is ended with
a message digest.
The C bit (EAP-SSC Ciphered payload) is set in an EAP-SSC message to
mean the payload is enciphered.
The X bit (EAP-SSC Sequence of X509 Certificate(s)) is set if in an
EAP-SSC message the payload contains a sequence of X.509
Certificate(s).
The R bit means Reserved.
4.2.4 Message Length field
The EAP-SSC Message Length field is three octets, and is present only
if the L bit is set. This field value provides the total length of
the EAP-SSC message or set of messages that is being fragmented.
4.2.5 Payload field
The Payload field is expected to receive the body of the message,
depending on the Sub-Type and the Flags fields
Urien & All Informational - Expires December 2003 7
EAP-SSC Secured Smartcard Channel June 2003
4.2.6 Digest field
The Digest field is present in the EAP-SSC packet only if the D bit is
set in the Flags field. The Digest field has 160-bits or 20-bytes
length and terminates the EAP-SSC packet. It corresponds to the result
of the computation of the message digest, using Secure Hash Algorithm
(SHA-1) applied generally to the concatenation of the Code,
Identifier, Length, Type, Sub-Type, Flags, Message Length, Payload
fields of the message and the Session key (Sk). Each time the digest
is computed, fields that are used in input should be clearly
specified.
5 Setting up the Secured Smartcard Channel
It is assumed to be in an environment where to access to the services
offered by the network, a Supplicant must access to an Authenticator
(Access Point) which will use an Authentication Server (RADIUS Server)
to check its capacities. Between the Supplicant and the Authenticator
it is assumed to use EAPOL (EAP over LAN) and between the
Authenticator and the Authentication Server it is assumed to use EAPOR
(EAP over RADIUS). According to the EAP authentication exchange, the
Authenticator sends generally a Request for identity to authenticate
the Supplicant. In response to this packet, the Supplicant sends a
Response packet containing this identity which is forwarded to the
Authentication Server. Since this moment and only in the case this
response is valid, the Authentication Server will attempt to set up a
secured channel with the Supplicant through the Authenticator.
In the table 1 are listed operators and functions used to calculate
values used to fill some EAP-SSC packet fields.
+-------------------+------------------------------------------+
| Operator/function | Meaning |
+-------------------+------------------------------------------+
| a XOR b | bit-wise logical "exclusive OR" between |
| | two values a and b |
+-------------------+------------------------------------------+
| a | b | Concatenation of the right value b to |
| | the left value a |
+-------------------+------------------------------------------+
| a MOD b | Remainder of the integer division of a |
| | by b |
+-------------------+------------------------------------------+
| x*y | x times y |
+-------------------+------------------------------------------+
| x**n | Equivalent to x*x*x...*x , n times |
+-------------------+------------------------------------------+
| D(msg) | Computation of the digest of the message +
| | msg using SHA-1 algorithm |
+-------------------+------------------------------------------+
Table 1 : Operators and functions used for some EAP-SSC fields
description.
Urien & All Informational - Expires December 2003 8
EAP-SSC Secured Smartcard Channel June 2003
For setting up this Secured Smartcard Channel two steps can be
distinguished: firstly the calculation of the sessionĘs key, and
secondly the validation of this computed sessionĘs key. Each one of
these phases corresponds with an exchange between the Supplicant and
the Authentication Server.
5.1 SessionĘs Key (SK) calculation
5.1.1 Overview
As already indicated higher, this phase follows the receipt by the
Authentication Server of the forwarded EAP-Response/Identity packet
from the Authenticator. In this packet is supposed encapsulated a
packet of EAP-SSC type. It is according to the value of its Sub-Type
field that will depend the components to be used to calculate the
sessionĘs key SK.
According to each one of these two key exchange contexts, the mode of
calculation of the sessionĘs key is detailed in this document.
5.1.2 SessionĘs key exchange - Symmetric case
When the Authentication Server receives the valid EAP-
Response/Identity packet from the Authenticator, it generates a random
number r1 of 160 bits (20 bytes) length. This r1 number is then
packed in clear text in an EAPOR-Request/EAP-SSC/Start packet which is
sent to the Supplicant according to the format presented in the figure
4 hereafter:
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=0x01 |Identifier=0x01| Length=0x1B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-SSC-Type | Sub-Type=0x01 | Flags=0x20 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. .
. r1 (20 bytes) .
+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 : EAP-SSC first packet format sent by the Authentication
Server in a symmetric key exchange model.
When the Authenticator receives the EAPOR-Request/EAP-SSC/Start
packet, it MUST modify and transmit it according the packets format
supported by the communication between him and the Supplicant; as a
Urien & All Informational - Expires December 2003 9
EAP-SSC Secured Smartcard Channel June 2003
result, it is an EAPOL-Request/EAP-SSC/Start packet which is
transmitted to the Supplicant.
With the reception of this packet, the Supplicant recovers the value
of r1 sent by the Authentication Server. Similarly to the
Authentication Server, the Supplicant generates a random number r2 of
160 bits length which is then used to compute the value of Z as
follows:
Z = r2 XOR D(r1 | s),
with the value s corresponding to the secret shared by the
Authentication Server and the Supplicant, value which is for the
Supplicant supposed to be kept inside the Smartcard.
Since this moment, the Supplicant is able to compute, using the
triplet (r1, r2, s), the sessionĘs key SK as follows:
SK = D(r1 | r2 | s).
Note 1 : Conditions and means which are employed to share or
distribute in safety the secrecy s between the Authentication Server
and the Smartcard are outside of the scope of this draft. It is also
supposed to have enough space and processing capabilities to compute
SK in the smartcard.
Then, the value of Z is packed by the Supplicant in an EAPOL-
Response/EAP-SSC packet which is addressed to the Authentication
Server via the Authenticator as it is shown in the figure 5 below:
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=0x02 |Identifier=0x01| Length=0x1B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-SSC-Type | Sub-Type=0x01 | Flags=0x00 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. .
. Z = r2 XOR D(r1 | s)(20 bytes) .
+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 : EAP-SSC first response packet format sent by the Supplicant
to the Authentication Server in a symmetric key exchange model.
Authenticator that receives the EAPOL-Response/EAP-SSC packet
transforms it into an EAPOR-Response/EAP-SSC packet and forwards it to
the Authentication Server.
At the arrival of the EAPOR-Response/EAP-SSC packet to the
Authentication Server, this one recovers the value of Z. Because of
Urien & All Informational - Expires December 2003 10
EAP-SSC Secured Smartcard Channel June 2003
knowing r1 and s, the Authentication Server is able to calculate the
message digest D(r1 | s) and thus to find back the r2 number. The
possession of the triplet (r1, r2, S) allows the Authentication Server
to calculate on its own side the sessionĘs key as the Supplicant has
done: it is the end of the EAP-SSC sessionĘs key calculation phase in
the symmetrical key exchange model.
To illustrate the exchange during this sessionĘs key calculation
phase, the figure 6 below is presented. In thick lines appear all
exchanges carried in EAPOL packets, and in broken lines EAPOR packets
that use RADIUS.
Supplicant Authenticator Authentication Server
<========================= - - - - - - EAPOR-Request/
EAP-SSC/Start with r1.
Modification from EAPOR
format to EAPOL format.
EAPOL-Response/EAP-SSC
with (r2 XOR D(r1 | s))
========================== - - - - - - - - - - >
Modification from EAPOL
format to EAPOR format.
SK = D(r1 | r2 |s) SK = D(r1 | r2 | s)
is Computed. is Computed.
Figure 6 : Example of the sessionĘs key calculation in the context of
encryption using secret key.
5.1.3 SessionĘs key calculation - Asymmetric case
In the context of enciphering using public key, instead of using
secret keys, one will make use of certificates rather, electronic
documents that carry the public keys and additional data for
encryption and deciphering.
When the Authentication Server possesses the certificate of the
Supplicant, and vice versa the Supplicant has the certificate of the
Authentication Server, they can bypass the exchange of the
certificates, and in this case C1 and C2 that mean exchanged
certificates in this document are empty.
In own way of illustration, we give the following figure 7 in which,
similarly to the precedent figure, thick lines are used for all
exchanges carried in EAPOL packets, and broken lines for EAPOR
packets.
Urien & All Informational - Expires December 2003 11
EAP-SSC Secured Smartcard Channel June 2003
Supplicant Authenticator Authentication Server
<======================== - - - - - - EAPOR-Request/EAP-SSC
/Start with C1 and r1
Modification from EAPOR
format to EAPOL format.
EAPOL-Response/EAP-SSC
with C2, r2**K1public, ====== - - - - - - - - - - - >
and D0**K2private.
Modification from EAPOL
format to EAPOR format.
SK = D(r1 | r2) SK = D(r1 | r2)
is computed. is Computed.
Figure 7 : Example of the sessionĘs key calculation in the context of
encryption using public key.
At the beginning of this phase, the Authentication Server generates a
random number r1 which length depends only on him. This r1 number and
the optional sequence of certificates named C1 belonging to the
Authentication Server are coded in ASN.1 [12] format and packed in
clear text in an EAPOR-Request/EAP-SSC/Start packet which is sent to
the Supplicant. This packet format is illustrated in the figure 8
hereafter:
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=0x01 |Identifier=0x01| Length = yy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-SSC-Type | Sub-Type=0x02 | Flags = zz | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Optional sequence of certificates C1 .
. Integer r1 .
+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 : EAP-SSC first request packet format sent by the
Authentication Server in an asymmetric key exchange model.
In a situation where there is no need to exchange certificates between
the Authentication Server and the Supplicant (for example the
Supplicant has inside the smartcard the certificate of the
Authentication Server and the Authentication Server stores the
certificate of the Supplicant), the payload of this packet will
contain exclusively the random number r1. Its length will determine
the length yy of the packet, the length of the message, and values of
bits L (Length included) and M (More fragment) in Flags field value zz
in which the bit S (start) will be set.
Urien & All Informational - Expires December 2003 12
EAP-SSC Secured Smartcard Channel June 2003
In other cases, a sequence of certificates and the random number r1
are sent to the Supplicant by the Authentication Server and these data
will determine the length yy of the packet, the length of the message,
and values of bits L (Length included) and M (More fragment) in Flags
field value zz in which the S (start) and X (X.509 certificate(s)
included) bits will be set.
When the Authenticator receives the EAPOR-Request/EAP-SSC/Start
packet, it MUST modify and transmit it according the packets format
supported by the communication between him and the Supplicant; as a
result, it is an EAPOL-Request/EAP-SSC/Start packet which is
transmitted to the Supplicant.
When this packet reaches to the Supplicant, the random number r1 and
the optional chain of certificates C1 are extracted. So, the
Supplicant is able to recover the public key named K1public of the
sender of the message and the corresponding modulo base named Modulo1.
Similarly to the Authentication Server, the Supplicant will generate a
random number r2 which length is variable and will compute two values
U and V as follows:
U = (r2 ** K1public) MOD Modulo1
V = (D0 ** K2private) MOD Modulo2
with:
D0 = D(Code | Identifier | Length | EAP-Type | Sub-Type | Flags |
Optional Certificates | value U in ASN.1 format).
In fact, D0 corresponds to the digest of the concatenation of all
fields preceding it in the packet. The values U and V correspond to
the encryption respectively of the random number r2 with the public
key of the Authentication Server, and the message digest D0 with the
private key of the Supplicant.
Since this moment, the Supplicant is able to compute, using the couple
(r1, r2) , the sessionĘs key SK as SK = D(r1 | r2).
Then, the SupplicantĘs optional sequence of certificates C2 and the
computed values U and V are coded in ASN.1 format and packed by the
Supplicant in an EAPOL-Response/EAP-SSC packet which is addressed to
the Authentication Server via the Authenticator. In the further figure
9 is represented the format of the first response packet sent from the
Supplicant to the Authentication Server via the Authenticator.
Urien & All Informational - Expires December 2003 13
EAP-SSC Secured Smartcard Channel June 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code=0x02 |Identifier=0x01| Length = yĘyĘ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-SSC-Type | Sub-Type=0x02 | Flags = zĘzĘ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Optional sequence of certificates .
. U = r2**K1public MOD Modulo1 (integer) .
+ V = D0**K2private MOD Modulo2 (integer) +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 : EAP-SSC first packet format sent by the Authenticator in an
asymmetric key exchange model.
The usage of a sequence of certificates and the values of Modulo1 and
Modulo2 will determine the packet Length yĘyĘ and the values of
L, M and X bits in the Flags field value zĘzĘ.
Authenticator that receives the EAPOL-Response/EAP-SSC packet
transforms it into an EAPOR-Response/EAP-SSC packet and forwards it to
the Authentication Server.
When this EAPOR-Response/EAP-SSC packet will reach to the
Authentication Server, this one will extract the optional chain of
certificates C2 from which it will be able to discover the public key
K2public and the modulo base named Modulo2 of this sender. Using these
two values, the Authentication Server will also be able to recover the
value of D0 and check it with that it can compute locally from the
received packet. If this comparison of digests is successful, the
Authentication Server will continue with the extraction of the random
value r2 from U by using its private key K1private and its modulo base
Modulo1. Otherwise, the Authentication Server will silently discard
this packet.
With the couple (r1, r2) the Authentication Server is also capable to
compute the sessionĘs key SK = D(r1 | r2), ending this phase.
5.2 SessionĘs key validation
Succeeding directly to the phase of the sessionĘs key calculation both
on the side of the Authentication Server and the side of the
Supplicant, the validation phase takes place. Its purpose is meanly
to verify that the two peers actually have computed a same value of
the sessionĘs key SK, and so, will confirm/infirm the presence of a
secured channel between the Supplicant and the Authentication Server.
There is no difference between the way this phase is proceeded in a
Urien & All Informational - Expires December 2003 14
EAP-SSC Secured Smartcard Channel June 2003
symmetrical key exchange context and an asymmetrical key exchange
context.
Initiated by the Authentication Server, an EAPOR-Request/EAP-SSC
packet is sent via the Authenticator to the Supplicant. The
characteristic of this packet is to contain a message named M1 which
may be empty but always signed with the sessionĘs key SK calculated by
the Authentication Server; in other words, the transmitted message to
the Supplicant by the Authentication Server will be ended by a message
digest D1 computed as D1 = D(M1 | SK).
With the reception of the EAPOR-Request/EAP-SSC packet by the
Authenticator, this one transforms it in a packet with EAPOL format;
it is thus an EAPOL-Request/EAP-SSC packet which is finally
transmitted to the Supplicant.
When the Supplicant receives this packet, it extracts the message
digest D1 sent by the Authentication Server. It verifies that this
received D1 data corresponds well to the message digest that it
computes locally by using its sessionĘs key SK. When this comparison
does not succeed, it silently discards this packet. Otherwise, the
Authentication Server has been correctly authenticated and the
Supplicant will continue by computing a new message digest D2
according to the formula D2 = D(M2 | D1 | SK) where M2 corresponds to
a message sent in response of M1; M2 may be a null length message. M2
with D2 will be packed in an EAPOL-Response/EAP-SSC packet and
conveyed to the Authentication Server via the Authenticator.
The Authenticator that receives the EAPOL-Response/EAP-SSC packet,
like in the sessionĘs key calculation phase, transforms it into an
EAPOR-Response/EAP-SSC packet and forwards it.
Supplicant Authenticator Authentication Server
an SK is available an SK is available
EAPOR-Request/EAP-SSC
<===================== - - - with M1 and D1 = D(M1 | SK)
Modification from EAPOR
format to EAPOL format
EAPOL-Response/EAP-SSC
with M2 and ============== - - - - - - - - - - - >
D2=D(M2 | D1 | SK)
Modification from EAPOL
format to EAPOR format
SK and D2 are available. SK and D2 are available.
For any i > = 3 Di can be For any i > = 3 Di can be
computed as D(Mi | Di-1 | SK). computed as D(Mi | Di-1 | SK).
Figure 10 : Exchanges during the sessionĘs key validation.
Urien & All Informational - Expires December 2003 15
EAP-SSC Secured Smartcard Channel June 2003
In the figure 10 is shown an example of exchange during the sessionĘs
key validation phase.
Finally, the EAPOR-Response/EAP-SSC packet is received by the
Authentication Server which extracts the message digest named
D2(receipt) from it. As knowing SK and D1 the Authentication Server
locally will calculate its own message digest named D2(local) and will
compare it with D2(receipt). If there are equal, then one can affirm
that the Supplicant share indeed the same sessionĘs key with him:
sessionĘs key SK has been validated between the Supplicant and the
Authentication Server.
6 Secure Channel Messages exchanges
Since the completion of the sessionĘs key calculation, all messages
sent from the Authentication Server to the Supplicant and vice versa
are signed with a digital digest value Di deduced from the sessionĘs
key SK, the message Mi to send and the digest Di-1 of the latter step
as presented hereafter:
D1 = D(M1,SK);
For any step i>1, Di = D(Mi | Di-1 | SK),
with SK computed from (r1, r2, s) in secret key encryption context,
and only from (r1, r2) otherwise.
At least three messages M1, M2 and M3 are exchanged :
* M1 a request message from the Authentication Server or a null length
message;
* M2 a response message from the Supplicant or a null length message;
* M3 a particular message for terminating the exchanges on the secured
channel. The EAP-SSC packet containing this last message will have in
its Flags field the E (End) bit set. As this message is also signed,
all rogue packets with E bit set will have no effect on the
Supplicant.
Between message M2 and message M3, the Authentication Server and the
Supplicant can continue to exchange messages, by taking care to sign
each Mi message with the required message digest Di.
7 Segmentation issue
Considering the public key exchange context, it will be frequent to
have in the payload of EAP-SSC packet a sequence of certificates,
either sent to the Authentication Server or to the Supplicant.
However, a certificate size may be near a kilo-byte and the size of
EAP-SSC packet limited to 240 bytes. So the issue of the segmentation
will be to manage long EAP-SSC message.
The presence of the Message length field and the M (More segment) bit
of Flags field can help to do it.
Urien & All Informational - Expires December 2003 16
EAP-SSC Secured Smartcard Channel June 2003
8 LDAP messages
If it is assumed a smartcard can contain inside many directories, the
capability to establish a secure communication with an Authentication
Server can be used to embed commands for LDAP oriented data-base
management (creation, reading, writing, deletion, etc.)
A choice of a particular value of Sub-Type field can mean the payload
contains LDAP commands. This Sub-Type value can be completed by
special format of the Flags field where a particular bit may mean that
commands are in ASN.1 format and so on.
9 Examples of traces
This section of the document provides two examples of results of a
simulation of the running of two sessions, the first session
associated to a symmetrical key exchange context, and the second to a
public key exchange context. All computed values used to produce the
five packets which are exchanged in each case are presented with
hereafter assumptions:
EAP-SSC-Type equal 255 (hexadecimal FF);
Starting Identifier equals 165 (hexadecimal A5).
9.1 Traces in a symmetrical key exchange context
//* value of the shared secret s
83D972D101F40973DEC8E32068B1DE581641EA76
//******************** 1st packet of the exchange ***************
//*************** sent by the Authentication Server (AS) ********
01 A5 00 1B FF 01 20 ; header
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with S (Start) bit set
| | | | +---- Sub-Type field set for symmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 27
| +------- Identifier field
+------- Code Field set for EAP-Request packet
BDD99CB2FDABDC5995521D3F4D7241BBA6A96E5D ; value of r1 (20 bytes)
//* value of r2 (20 bytes) generated by the Supplicant
E72D5787D1C037E1DE3CFE63DCF5DF8DF2523693
//* value of D(r1 | s)
A575616DE4EB41230E39B28A94BB86039E27F8C9
Urien & All Informational - Expires December 2003 17
EAP-SSC Secured Smartcard Channel June 2003
//********************** 2nd packet of the exchange *************
//******************* sent by the Supplicant to the AS
02 A5 00 1B FF 01 00 ; header
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field
| | | | +---- Sub-Type field set for symmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field
| +------- Identifier field equals to that of the request packet
+------- Code Field set for EAP-Response packet
425836EA352B76C2D0054CE9484E598E6C75CE5A ; Z = r2 XOR D(r1 | s)
//* value of the computed SessionĘs Key SK
AB5AFE7AC13CEE477BEACE3A5178AD9D7BD7D374
//********************** 3rd packet of the exchange *************
//******************* sent by the AS to the Supplicant **********
01 A6 00 1B FF 01 08 ; header
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with D (Digest) bit set
| | | | +---- Sub-Type field set for symmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field
| +------- Identifier field has been incremented to 166
+------- Code Field set for EAP-Request packet
22F182938CBA24E4E49D2B5E9EA3B53321DE84FD ; D1 = D("hello" | SK)
//********************** 4th packet of the exchange *************
//******************** sent by the Supplicant to the AS *********
02 A6 00 1B FF 01 08 ; header
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with D (Digest) bit set
| | | | +---- Sub-Type field set for symmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field
| +------- Identifier field equals to that of the request packet
+------- Code Field set for EAP-Response packet
AB10AB506D923CE0BC60221ACF503D6338C1EDA2 ; D2=D("world" | D1 | SK)
Urien & All Informational - Expires December 2003 18
EAP-SSC Secured Smartcard Channel June 2003
//********************** 5th packet of the exchange *************
//******************** sent by the AS (EAP-Success/End) *********
03 A7 00 1B FF 01 18 ; header
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with D (Digest) and E (End)
| | | | | bits set
| | | | +---- Sub-Type field set for symmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field
| +------- Identifier field has been incremented to 167
+------- Code Field set for EAP-Success packet
E69D06BA33DF2799B436D65A348F33840B332810 ; D3=D("stop" | D2 | SK)
9.2 Traces in an asymmetrical key exchange context
//** First Pair-wise-key used by the Authentication Server
//* value of Modulo1 - Integer 129 bytes
02 81 81
00EE9D84FB3D70CD3CF145BDB8D1D7580BDB917149D44EE09C6E8409853E7D68
5A7C61F840B687EC0F841FEDBCEA6FBBD872783C43CA04AEA56956BD607AAB38
739E629C6FAE2D34B69FFD3D722BE41719CFA5122B50D7821A4FF69DB5E6839D
5938D8D8FD830488342AA5A266A45CD8C1AE32E59B66EE1FFA65DEBD6235824B
21
//* Value of K1public - Integer = 3
02 01 03
//* Value of K1private - Integer 129 bytes
02 81 81
009F13ADFCD3A088D34B83D3D08BE4E55D3D0BA0DBE2DF406849AD5BAE29A8F0
3C52EBFAD5CF05480A581549289C4A7D3AF6FAD2D7DC031F18F0E47E4051C77A
F6754030B429325864665ECE80839E26AAE039CE642E8253A7E4074BC934D109
8FC5FA3F6D9985251A3123BAB9AEA498F81FE5EE4407195757FED591D09F5D10
CB
//** Second Pair-wise-key used by the Supplicant.
//* Value of Modulo2 Integer 65 bytes
02 41
00B7C2DF803986F6F4DFBA2E104FC5DE0F8DC50ABE713DB9AA2B78387996DCC6
437FFA8B24CD657FAEEE02082EA01553E2DC0A68A5FD5891AAEF78C2489CAB50
C1
//* Value of K2public - Integer = 3
02 01 03
//* Value of K2private - Integer 64 bytes
02 40
7A81EA557BAF4F4DEA7C1EB58A83E95FB3D8B1D44B7E7BC6C7A57AFBB9E8842B
DD5FA9723EC5BF7A9CB387AF255583620B98FE5F0020EE72E24BB429D4BBCACB
Urien & All Informational - Expires December 2003 19
EAP-SSC Secured Smartcard Channel June 2003
//********************** 1st packet of the exchange ************
//*************** sent by the Authentication Server (AS) *******
01 A5 00 2D FF 02 20 ; header
^ ^ ---- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with S (Start) bit set
| | | | +---- Sub-Type field set for asymmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 45
| +------- Identifier field
+------- Code Field set for EAP-Request packet
02 84 00 00 00 20 ; ASN.1 header of the integer r1
//* Value of r1 on 32 octets (256 bits)
005A9B7B1ABDF0A329B3AB16E5F8933154E33C2C4ADD82F4DD2753257FF62ADC
//* value of r2 on 128 octets (1024 bits)
006696D8F9847CAC6FD072E68E7339B8A96BCD4E7D5E2C2B69CF802F79F584EA
AEB85C19D59986E285CCBF86EE4AEB5B0061909165A0B6E3CDA8AA21704C363B
7475F198E22320CDF3B86F40B46EC879482718C5DF242A72A081E674C763469B
B55E6B5946FF5BF7DB82E22194EC4F4C177C067A980A4B945DED75B0C8B23F19
//* value of U on 128 bytes (1024 bits) equals to the encryption
//* of r2 with the public key K1public of the AS
7E36D476944C29467915734360D647D6A8923043B727548495A265B7A38CACBE
0CEF55DF16911AA8A63BFB55D5262D14A1D4FC82B0DF011AD61FD243916C4682
A73E647E1269785EECEE414BCFE43660E107D120E30CED09151D884D15B0BA94
17F038955AF4B68621AF0EC3E38DBCCB0827961813B26123FE001DB0E0316211
//* value of D0 on 20 bytes computed as the digest of the
//* concatenation of fields from Code field to integer value U
//* coded in the packet
9E7EFE6B9C60428CC61C8798C8F4FE4835BA0861
//* value of V on 64 bytes (512 bits) equals to the encryption
//* of D0 with the private key K2private of the Supplicant
3A95A34B98F5E009FAE2ECE3F836DFEBB73EEC8B89F733C02F74EBB236AB6151
5D003228F355877C94AFDAAADEC5C47F236F09FE1D8E651FAFE757F064292B73
//********************** 2nd packet of the exchange ************
//******************* sent by the Supplicant to the AS
02 A5 00 D3 FF 02 00 ; header
^ ^ ---- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field
| | | | +---- Sub-Type field set for asymmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 211
| +------- Identifier field
+------- Code Field set for EAP-Response packet
Urien & All Informational - Expires December 2003 20
EAP-SSC Secured Smartcard Channel June 2003
02 84 00 00 00 80 ; ASN.1 header of the integer U value
; coded on the 128 bytes below
7E36D476944C29467915734360D647D6A8923043B727548495A265B7A38CACBE
0CEF55DF16911AA8A63BFB55D5262D14A1D4FC82B0DF011AD61FD243916C4682
A73E647E1269785EECEE414BCFE43660E107D120E30CED09151D884D15B0BA94
17F038955AF4B68621AF0EC3E38DBCCB0827961813B26123FE001DB0E0316211
02 84 00 00 00 40; ASN.1 header of the integer V value
; coded on the 64 bytes below
3A95A34B98F5E009FAE2ECE3F836DFEBB73EEC8B89F733C02F74EBB236AB6151
5D003228F355877C94AFDAAADEC5C47F236F09FE1D8E651FAFE757F064292B73
//* value of the SessionĘs Key SK
3B4C5E8CD72D723A6CC971612DFFED0EB1E8B514
//* value of D1=D("hello" | SK)
772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77
//********************** 3rd packet of the exchange ************
//******************* sent by the AS to the Supplicant *********
01 A6 00 1B FF 02 08
^ ^ ---- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with D (Digest) bit set
| | | | +---- Sub-Type field set for asymmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 27
| +------- Identifier field has been incremented to 166
+------- Code Field set for EAP-Request packet
772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77
//* value of D2=D("world" | D1 | SK)
CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122
//********************** 4th packet of the exchange ************
//******************** sent by the Supplicant to the AS ********
02 A6 00 1B FF 02 08
^ ^ ---- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with D (Digest) bit set
| | | | +---- Sub-Type field set for asymmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 27
| +------- Identifier field is the same as for request packet
+------- Code Field set for EAP-Response packet
CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122
Urien & All Informational - Expires December 2003 21
EAP-SSC Secured Smartcard Channel June 2003
//* value of D3=D("stop" | D2 | SK)
D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C
//********************** 5th packet of the exchange ************
//******************** sent by the AS (EAP-Success/End) ********
03 A7 00 1B FF 02 18
^ ^ ---- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with E (End) and D (Digest)
| | | | | bit set
| | | | +---- Sub-Type field set for asymmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 27
| +------- Identifier field has been incremented
+------- Code Field set for EAP-Success packet
D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C
Urien & All Informational - Expires December 2003 22
EAP-SSC Secured Smartcard Channel June 2003
10 Intellectual Property Right Notice
To be specify according to the author and participant.
11 References
[1] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar,
"Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-
05.txt, work-in-progress, September 2002. (INFORMATIVE)
[2] L. Blunk, J. Vollbrecht, Bernard Aboba, "Extensible
Authentication Protocol (EAP)", RFC 2284bis, February 2002.
[3] P. Urien, M. Loutrel,K. Lu, "Introducing Smartcards for Wireless
LAN Security", 10th International Conference on Telecommunication
Systems, Monterey, California, October 3-6 2002.
[4] P. Urien, M. Loutrel, "The EAP Smartcard, a tamper resistant
device dedicated to 802.11 wireless networks", ASWN 2003, July 2003.
[5] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[6] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3) : Attribute Syntax Definitions", RFC 2252,
December 1997.
[7] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3) : UTF-8 String Representation of Distinguished Names",
RFC 2253, December 1997.
[8] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", RFC
2716, October 1999.
[9] H. Haverinen, J. Salowey, "EAP SIM Authentication"
http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-
10.txt, work-in-progress, February 2003.
[10] W. Simpson, "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[11] N. Haller, C. Metz, P. Nesser, M. Straw, "One-Time Password
System", RFC 2289, February 1998.
[12] ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, "ASN.1 encoding
rules - Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002.
Urien & All Informational - Expires December 2003 23
EAP-SSC Secured Smartcard Channel June 2003
12 Author's Addresses
Pascal Urien
ENST
46 rue Barrault
75013 Paris Phone: NA
France Email: Pascal.Urien@enst.fr
Mesmin T. Dandjinou
ENST
46 rue Barrault
75013 Paris Phone: NA
France Email: mesmin.dandjinou@voila.fr
Urien & All Informational - Expires December 2003 24
| PAFTECH AB 2003-2026 | 2026-04-23 09:03:54 |