One document matched: draft-urien-eap-ssc-01.txt
Differences from draft-urien-eap-ssc-00.txt
Internet Draft P.Urien
Document: draft-urien-eap-ssc-01.txt M. Dandjinou
Expires: June 2004
EAP-SSC Secured Smartcard Channel
Status
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1 Abstract
This document describes a means of setting up an EAP secured channel
between a Smart Card SC 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 the SC 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
Smart Card.
Urien & All Informational - Expires June 2004 1
EAP-SSC Secured Smart Card Channel December 2003
Table of Contents
1 Abstract............................................................1
2 Overview............................................................3
3 EAP-SSC Protocol Data Unit..........................................3
3.1 EAP packet format (Informative)..................................3
3.2 EAP-SSC packet format............................................4
3.2.1 Type field....................................................4
3.2.2 Sub-Type field................................................5
3.2.3 Flags field...................................................5
3.2.4 Message Length field..........................................7
3.2.5 Payload field.................................................7
3.2.6 Digest field..................................................7
4 Setting up the Secured Smart Card Channel...........................7
4.1 SessionĘs Key (SK) calculation...................................8
4.1.1 Overview......................................................8
4.1.2 SessionĘs key calculation, Symmetric case.....................8
4.1.3 SessionĘs key calculation, Asymmetric case...................10
4.2 SessionĘs key validation........................................12
5 Secure Channel Messages exchanges..................................15
6 Segmentation issue.................................................16
7 LDAP messages......................................................16
8 Messages encryption................................................16
9 Examples of traces with plain text payload.........................18
9.1 Traces in a symmetrical key exchange context....................18
9.2 Traces in an asymmetrical key exchange context..................20
10 Intellectual Property Right Notice................................23
11 References........................................................23
12 Author's Addresses................................................23
Urien & All Informational - Expires June 2004 2
EAP-SSC Secured Smart Card Channel December 2003
2 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,
require 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 Smart Card 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 Smart Card and the
Authentication Server via the Authenticator. The purpose of this paper
is first to present this new protocol EAP-SSC (Extensible
Authentication Protocol, Secured Smart Card 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 Smart Card are securely embedded in
these PDUs.
3 EAP-SSC Protocol Data Unit
EAP-SSC is an authentication protocol for Smart Cards based on EAP.
Before showing the format of its PDUs, let us remind the EAP packet
format.
3.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.
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.
Urien & All Informational - Expires June 2004 3
EAP-SSC Secured Smart Card Channel December 2003
3.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.
3.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]).
A new value of Type field is requested to IANA for distinguishing EAP
on Smart Cards 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).
Urien & All Informational - Expires June 2004 4
EAP-SSC Secured Smart Card Channel December 2003
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].
3.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:
* Sub-type = 1 means that the context of encryption corresponds to the
symmetrical model, i.e. one supposes that the Smart Card 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 Smart Card 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.
3.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;
Urien & All Informational - Expires June 2004 5
EAP-SSC Secured Smart Card Channel December 2003
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 X.509 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
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 data encryption algorithm used is
by default the Triple Data Encryption Algorithm (TDEA as described in
ANSI X9.52) using CBC mode with keying option 2 for bundle (K1, K2, K3)
where K1 and K2 are independent keys and K3=K1.
The X bit (EAP-SSC Sequence of X.509 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" and will be kept at 0 until future usages
have been specified.
Urien & All Informational - Expires June 2004 6
EAP-SSC Secured Smart Card Channel December 2003
3.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.
3.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
3.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 many values. Each
time the digest is computed, all values that are used in input should
be clearly specified.
4 Setting up the Secured Smart Card 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 by default SHA-1 algorithm |
+-------------------+------------------------------------------+
Table 1 : Operators and functions used for some EAP-SSC fields
description.
Urien & All Informational - Expires June 2004 7
EAP-SSC Secured Smart Card Channel December 2003
For setting up this Secured Smart Card 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.
4.1 SessionĘs Key (SK) calculation
4.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.
4.1.2 SessionĘs key calculation, Symmetric case
When the Authentication Server receives the valid EAP-Response/Identity
packet from the Authenticator, it generates a random positive number r1
of 160 bits (20 bytes) length (the high order bit of r1 is set to 0).
This r1 number is then packed in plaintext, low order byte first, 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, low order byte first) .
+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 to 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.
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 positive number r2 of 160
bits length (the high order bit of r2 is set to 0) which is then used
to compute the value of Z as follows:
Z = r2 XOR D(r1 | s),
Urien & All Informational - Expires June 2004 8
EAP-SSC Secured Smart Card Channel December 2003
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 Smart Card.
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).
Then, the value of Z is packed, low order byte first, 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, low order byte first) .
+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
Note 1 : Conditions and means which are employed to share and
distribute in safety the secret s between the Authentication Server and
the Smart Card are outside of the scope of this draft. It is also
supposed to have enough space and processing capabilities to compute SK
in the Smart Card.
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))
Urien & All Informational - Expires June 2004 9
EAP-SSC Secured Smart Card Channel December 2003
========================== - - - - - - - - - - >
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.
4.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.
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 positive number r1 which length depends only on him (the high
order byte of r1 is set to 0). This r1 number and the optional sequence
of certificates named C1 belonging to the Authentication Server are
coded in BER ASN.1 [12] format and packed in plaintext in an EAPOR-
Request/EAP-SSC/Start packet which is sent to the Supplicant. This
packet format is illustrated in the figure 8 hereafter.
Urien & All Informational - Expires June 2004 10
EAP-SSC Secured Smart Card Channel December 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=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 Smart Card 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 positive 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.
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 to 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 positive 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 positive number r2 which length is variable (but with always the
high order byte set to 0) 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 C2 | value U in BER 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 positive number r2 with the
public key of the Authentication Server, and the message digest D0 with
the private key of the Supplicant.
Urien & All Informational - Expires June 2004 11
EAP-SSC Secured Smart Card Channel December 2003
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 BER 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.
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 C2 .
. 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
positive 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.
Note 2 : Before using data from certificates, it is assumed their
validity and authenticity have been checked. And this verification
aspect of the certificate is outside of the scope of this draft.
4.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
Urien & All Informational - Expires June 2004 12
EAP-SSC Secured Smart Card Channel December 2003
channel between the Supplicant and the Authentication Server. There is
no difference between the way this phase is proceeded in a 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 ended with a message digest D1 which is computed as D1 = D(M1 |
SK), according to the format presented in the followed figure 10.
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=0x02| Length = y"y" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-SSC-TYPE | Sub-Type = n | Flags=0x08 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. M1 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| D1(M1, SK) (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 : EAP-SSC 2nd packet format sent by the Authentication Server
to the Supplicant.
Generally, the Length field value y"y" of the packet will depend on the
length of the message M1. Sub-Type field value n will be either 1 for
symmetric key exchange context, or 2 for asymmetric key exchange
context. The Flags field value shows the bit D (Digest) is set.
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 checks the received D1
to see if itĘs equal to the message digest that is computed locally by
using its sessionĘs key SK. When this comparison failed, the Supplicant
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 to M1. M2
may be a null length message. M2 with D2 will be packed in an EAPOL-
Response/EAP-SSC packet as presented in the figure 11 and conveyed to
the Authentication Server via the Authenticator.
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
Urien & All Informational - Expires June 2004 13
EAP-SSC Secured Smart Card Channel December 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code=0x02 |Identifier=0x02| Length = zĘzĘ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-SSC-TYPE | Sub-Type = n | Flags=0x08 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. M2 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| D2(M2, D1, SK) (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 : EAP-SSC 2nd packet format sent from the Supplicant to the
Authentication Server.
Similarly to the previous packet, the Length field value zĘzĘ of the
packet will depend on the length of the message M2. Sub-Type field
value n will be either 1 or 2 depending on the key exchange context and
the D bit will be set in the Flags field.
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.
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 they are not equal, the Authentication
Server silently discards the packet. Otherwise, one can affirm that the
Supplicant shares indeed the same sessionĘs key with the Authentication
Server: sessionĘs key SK has been validated between the Supplicant and
the Authentication Server.
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 12 : Exchanges during the sessionĘs key validation.
Urien & All Informational - Expires June 2004 14
EAP-SSC Secured Smart Card Channel December 2003
In the figure 12 is shown an example of exchange during the sessionĘs
key validation phase.
5 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 appended 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) triplet in secret key encryption
context, and only from (r1, r2) couple otherwise.
At least three messages M1, M2 and Mf (f equals 3 here) 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;
* Mf a final message originated by the Authentication Server for
terminating the exchanges on the secured channel. The EAP-SSC packet
containing this last message as presented in the figure 13 will have in
its Flags field the E (End) bit set. As this message is also ended with
a digest, all rogue packets with E bit set will have no effect on the
Supplicant.
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=0x03 |Identifier=0x03| Length = y"y" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-SSC-TYPE | Sub-Type = n | Flags=0x18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Mf .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Df(Mf, Df-1, SK) (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 : EAP-SSC final packet format sent by the Authentication
Server to the Supplicant.
For this packet also, the Length y"y" will depend on the length of the
message Mf. Sub-Type field value n will be either 1 or 2 depending on
the key exchange context. In the Flags field the E (End) and D (Digest)
bits will be set.
Urien & All Informational - Expires June 2004 15
EAP-SSC Secured Smart Card Channel December 2003
Between message M2 and message Mf, the Authentication Server and the
Supplicant can continue to exchange messages, by taking care to end
each Mi message with the required message digest Di.
6 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
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.
7 LDAP messages
If it is assumed a Smart Card 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.
8 Messages encryption
One of the best ways to assure confidentiality of the exchanged
messages between the Authentication Server and the Smart Card is to use
encryption. This capability is basically assured by setting up the C
(Ciphering) bit of the Flags field which means the payload in the
packet has been enciphered. The cryptographic algorithm by default used
to encrypt the payload is the Triple Data Encryption Algorithm (TDEA)
as described in ANSI X9.52 [13] [14], according to the EDE scheme
(Encryption-Decryption-Encryption) in CBC (Cipher Block Chaining) with
keying triplet (K1, K2, K3), where K1 and K2 are independent keys when
K1 and K3 are identical keys. For this reason, two important features
must be specified : first the cryptographic keys that are used and
shared by the sender and the receiver of the message, and secondly the
way to assure message padding if necessary.
As the cryptographic key controls the encryption process, the same key
must be also used during the decryption process to assure that the
receiver will obtain the original data used before encryption. Since
cryptographic security depends on the secrecy of the keys, it is
important to avoid their transmission during exchanges, to prevent
spoofing attacks. So it is decided to produce dynamically these
cryptographic keys in each side of the exchange between the
Authentication Server and the Smart Card. And the materials used to
produce these keys are first the Session Key (SK) which is set up after
the sessionĘs key calculation phase and secondly a counter
corresponding to the Identifier field value.
Let i be the value of the Identifier field of the packet to be sent and
in which the payload must be enciphered. Let us consider SK as a 160-
bits integer where bits are numbered from 0 for the lowest bit and 159
for the highest bit. The index f(i) whose value lies between 0 and 159
represents the number of circular right shifts (binary rotations) to
Urien & All Informational - Expires June 2004 16
EAP-SSC Secured Smart Card Channel December 2003
apply to SK, before getting from this result the lowest 112 bits that
will correspond to the cryptographic key at a given time by the Triple
DES algorithm. f(x) is a determinist well known function which is by
default chosen as ((3391*x) MOD 160)).
The way to obtain a cryptographic key is illustrated by the figure 14.
It is also assumed for the security improvement that the Authentication
Server is the only one entity allowed to start encryption. When the
Smart Card receive an enciphered packet, it must respond with an
enciphered packet too. And when one side of the exchange receives an
encrypted packet it canĘt decrypt, it silently discards it.
f(i)
|
|<---------------------->
v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | |y . . . .| |. . x| | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 0 0 0 0
5 5 1 1 0 0
9 8 7 6 5 4 3 2 1 0 . . . . . 6 . . . . . 0 9 8 7 6 5 4 3 2 1 0
<------- SK material before circular right shifting ------------>
cryptographic key (112 bits)
|<--------------------------------------->|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | |y . . . .| |. . x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 0 0 0 0
5 5 1 1 0 0
9 8 7 6 5 4 3 2 1 0 . . . . . 6 . . . . . 0 9 8 7 6 5 4 3 2 1 0
<-------- SK material after circular right shifting ------------>
Figure 14 : EAP-SSC basic encryption keys calculation.
Since the CBC mode is a block method of encryption which operates on
64-bits data blocks, it is important to take care of the partial data
blocks (ending blocks of the messages that are less than 64 bits long).
So it is decided to pad these final partial blocks before processing
their encryption. The following method of padding is used.
The bytes of a final partial block is left justified and completed to
8-bytes block with padding bytes. The value of the padding byte depends
on the value of the last byte of the original message and corresponds
to its complement. As the padding message must include a special
indicator for the entity in charge of the decryption, even final
complete block will be followed by a block made of padding bytes only.
So, after the deciphering operation of the last block of a message, the
decryption entity must systematically reverse padding process by
removing all padding bytes (up to 8 identical bytes sometimes) and
producing the original plain text. The figure 15 gives an illustration
of this padding method.
Urien & All Informational - Expires June 2004 17
EAP-SSC Secured Smart Card Channel December 2003
Original message is a 8-bytes multiple length.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|h e l l o w o r l d s t o p|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
68656c6c6f20776f726c642073746f70 <-- ASCII code of characters
Splitting blocks
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|h e l l o w o| |r l d s t o p|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
68656c6c6f20776f 726c642073746f70 <-- ASCII code of characters
padding block
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|h e l l o w o| |r l d s t o p| |p'p'p'p'p'p'p'p'|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
68656c6c6f20776f 726c642073746f70 8f8f8f8f8f8f8f8f
Original message is not a 8-bytes multiple length.
+-+-+-+-+-+-+-+-+-+-+-+
|h e l l o w o r l d|
+-+-+-+-+-+-+-+-+-+-+-+
68656c6c6f20776f726c64 <-- ASCII code of characters
Splitting and padding blocks
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|h e l l o w o| |r l d p'p'p'p'p'|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
68656c6c6f20776f 726c649b9b9b9b9b <-- ASCII code of characters
with p' = complement(p), which means that for each bit set in the "p"
byte, its corresponding bit is changed to zero in "p'", and each bit
zero in the "p" is associated to a set bit in the padding byte "p'".
Figure 15 : Examples of padding before EAP-SSC message encryption.
9 Examples of traces with plain text payload
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);
- The payload is not enciphered.
9.1 Traces in a symmetrical key exchange context
//* value of the shared secret s
83D972D101F40973DEC8E32068B1DE581641EA76
//******** Beginning of the 1st packet of the exchange **********
Urien & All Informational - Expires June 2004 18
EAP-SSC Secured Smart Card Channel December 2003
//*********** 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)
//******************* End of the 1rst packet ********************
//* value of r2 (20 bytes) generated by the Smart Card
E72D5787D1C037E1DE3CFE63DCF5DF8DF2523693
//* value of D(r1 | s)
A575616DE4EB41230E39B28A94BB86039E27F8C9
//******** Beginning of the 2nd packet of the exchange **********
//************* sent by the Smart Card 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 set to 27
| +------- Identifier field equals to that of the request packet
+------- Code Field set for EAP-Response packet
425836EA352B76C2D0054CE9484E598E6C75CE5A ; Z = r2 XOR D(r1 | s)
//******************* End of the 2nd packet *********************
//* value of the computed SessionĘs Key SK
AB5AFE7AC13CEE477BEACE3A5178AD9D7BD7D374
//******** Beginning of the 3rd packet of the exchange **********
//************* sent by the AS to the Smart Card ****************
01 A6 00 20 FF 01 08 ; header
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with D (Digest) bit set
| | | | +---- Sub-Type field set for symmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 32
| +------- Identifier field has been incremented to 166
+------- Code Field set for EAP-Request packet
68 65 6C 6C 6F ; M1="hello"
22F182938CBA24E4E49D2B5E9EA3B53321DE84FD ; D1 = D("hello" | SK)
//******************* End of the 3rd packet *********************
//******** Beginning of the 4th packet of the exchange **********
//************* sent by the Smart Card to the AS ****************
02 A6 00 20 FF 01 08 ; header
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- Flags field with D (Digest) bit set
| | | | +---- Sub-Type field set for symmetrical case
| | | +----- EAP-SSC-Type
| | +------- Packet Length field set to 32
| +------- Identifier field equals to that of the request packet
+------- Code Field set for EAP-Response packet
Urien & All Informational - Expires June 2004 19
EAP-SSC Secured Smart Card Channel December 2003
77 6F 72 6C 64 ; M2="world"
AB10AB506D923CE0BC60221ACF503D6338C1EDA2 ; D2=D("world" | D1 | SK)
//******************* End of the 4th packet *********************
//******** Beginning of the 5th packet of the exchange **********
//************* sent by the AS (EAP-Success/End) ****************
03 A7 00 1F 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 set to 31
| +------- Identifier field has been incremented to 167
+------- Code Field set for EAP-Success packet
73 74 6F 70 ; M3="stop"
E69D06BA33DF2799B436D65A348F33840B332810 ; D3=D("stop" | D2 | SK)
//******************* End of the 5th packet *********************
9.2 Traces in an asymmetrical key exchange context
We assume the Authentication Server knows the public key of the Smart
Card, and the public key of the Authentication Server is also known by
the Smart Card. For these reasons, fields used by certificates C1 and
C2 in exchanged packets are empty.
//** 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 Smart Card
//* 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
//******** Beginning of the 1st packet of the exchange *********
//*********** sent by the Authentication Server (AS) ***********
01 A5 00 2D FF 02 20 ; header
Urien & All Informational - Expires June 2004 20
EAP-SSC Secured Smart Card Channel December 2003
^ ^ ----- ^ ^ ^
| | ^ | | |
| | | | | +----- 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
//******************* End of the 1rst packet *******************
//* 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 by the Smart Card
9E7EFE6B9C60428CC61C8798C8F4FE4835BA0861
//* Value of V on 64 bytes (512 bits) equals to the encryption
//* of D0 with the private key K2private of the Smart Card
3A95A34B98F5E009FAE2ECE3F836DFEBB73EEC8B89F733C02F74EBB236AB6151
5D003228F355877C94AFDAAADEC5C47F236F09FE1D8E651FAFE757F064292B73
//******** Beginning of the 2nd packet of the exchange *********
//*************** sent by the Smart Card 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
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
//******************* End of the 2nd packet ********************
Urien & All Informational - Expires June 2004 21
EAP-SSC Secured Smart Card Channel December 2003
//* value of the SessionĘs Key SK
3B4C5E8CD72D723A6CC971612DFFED0EB1E8B514
//* value of D1=D("hello" | SK)
772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77
//******** Beginning of the 3rd packet of the exchange *********
//************** sent by the AS to the Smart Card **************
01 A6 00 20 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 32
| +------- Identifier field has been incremented to 166
+------- Code Field set for EAP-Request packet
68 65 6C 6C 6F ; M1="hello"
772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77 ; D1=D("hello" | SK)
//******************* End of the 3rd packet ********************
//* value of D2=D("world" | D1 | SK)
CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122
//******** Beginning of the 4th packet of the exchange *********
//************** sent by the Smart Card to the AS **************
02 A6 00 20 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 32
| +------- Identifier field is the same as for request packet
+------- Code Field set for EAP-Response packet
77 6F 72 6C 64 ; M2="world"
CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122 ; D2=D("world" | D1 | SK)
//******************* End of the 4th packet ********************
//* value of D3=D("stop" | D2 | SK)
D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C
//******** Beginning of the 5th packet of the exchange *********
//************** sent by the AS (EAP-Success/End) **************
03 A7 00 1F 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 31
| +------- Identifier field has been incremented
+------- Code Field set for EAP-Success packet
73 74 6F 70 ; M3="stop"
D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C ; D3=D("stop" | D2 | SK)
//******************* End of the 4th packet ********************
Urien & All Informational - Expires June 2004 22
EAP-SSC Secured Smart Card Channel December 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 Smart Cards for Wireless
LAN Security", 10th International Conference on Telecommunication
Systems, Monterey, California, October 3-6 2002.
[4] P. Urien, M. Loutrel, "The EAP Smart Card, 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.
[13] FIPS PUB 46-3, Data Encryption Standard (DES), October 1999,
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf.
[14] FIPS PUB 81, DES modes of operation, December 1980,
http://www.itl.nist.gov/fipspub/fip81.htm.
12 Author's Addresses
Pascal Urien
ENST
Urien & All Informational - Expires June 2004 23
EAP-SSC Secured Smart Card Channel December 2003
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 June 2004 24
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:53 |