Internet Draft M. Badra
Document: draft-badra-eap-double-tls-00.txt P. Urien
Expires: November 7th, 2004 ENST Telecom
May 7th, 2004
EAP-Double-TLS Authentication Protocol
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
EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS,
a full TLS handshake is used to mutually authenticate a client and
server and to share a secret key. EAP-Double-TLS extends this
authentication negotiation by using the secure connection
established by the TLS Pre Shared Key (PSK) handshake to exchange
additional information between client and server. The secure
connection established by the PSK handshake may then be used to
allow the server and the client to securely exchange their identity
(X509 certificates) and to update security attributes for next
sessions (session ID and master secret).
EAP-Double-TLS enables client’s anonymity, and allows client and
server to establish keying material for use in the data connection
between the client and the authenticator. The keying material is
established implicitly between client and server based on the TLS
PSK handshake.
Badra & Urien Informational - Expires November 2004 1
EAP-Double-TLS Authentication Protocol May 2004
Table of Contents
1 Abstract.........................................................1
2 Introduction.....................................................2
2.1 Requirements language.......................................3
3 Protocol overview................................................3
3.1 EAP identity protection.....................................3
3.2 Overview of the EAP-Double-TLS conversation.................4
3.2.1 Phase 1: TLS PSK Handshake............................5
3.2.2 Phase 2: TLS Handshake................................6
3.3. Retry behavior.............................................7
3.4. Fragmentation..............................................7
3.5. Key derivation.............................................7
3.6. CCP and CCP negotiation....................................7
3.7. Examples...................................................7
4 EAP-Double-TLS protocol within EAP Smartcards...................11
4.1 Fragmentation issues.......................................11
5. Detailed description of the EAP-Double-TLS protocol............14
5.1. EAP-Double-TLS Packet Format..............................14
5.2. EAP-Double-TLS Request Packet.............................15
5.3. EAP-Double-TLS Response Packet............................16
6 Security Considerations.........................................17
7 Intellectual Property Right Notice..............................17
8 Acknowledgements................................................17
9 References......................................................18
10 Author's Addresses.............................................18
2 Introduction
The Extensible Authentication Protocol (EAP) [5] defines a mechanism
that may be extended with additional authentication protocols within
PPP [1] such as MD5 [4], TLS [2] and PEAP. In agreement with almost
authentication methods with PPP specifications, EAP used to
authenticate only the client to the server.
The EAP-TLS authentication protocol, described in [3], provides a
standard method for mutual authentication and key generation. The
EAP-TLS requires certificates and PKI infrastructures to maintain
and that the client and the server MUST be authenticated using X509
certificates.
TLS itself allows the client and the server to resume sessions. A
secure connection may be terminated and resumed later. Secure
sessions can be resumed if the client and server agree. During this
phase, the peers will use the old master secret and the new random
numbers to calculate new master secret and cryptographic keys. This
will generate fewer cryptographic computations and less processing
time than a full TLS handshake. In addition, it will save the
bandwidth which is the bottleneck in the wireless networks.
Badra & Urien Informational - Expires November 2004 2
EAP-Double-TLS Authentication Protocol May 2004
Shared-key TLS runs as resume sessions using pre-installed secret
key. However, it may be an advantageous to use shared-key
authentication handshake instead of Public Key Infrastructure (PKI)
based certificates. Further, shared-key TLS doesn’t require any
asymmetric cryptographic operation like RSA encrypt/decrypt or
certificate’s verification.
EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS,
a TLS handshake is used to mutually authenticate a client and a
server. EAP-Double-TLS extends this authentication negotiation by
using the secure connection established by the TLS PSK handshake to
securely exchange additional information between client and server.
In EAP-Double-TLS, the authentication is established using pre-
installed key on both client and server. The secure connection
established by the PSK handshake may then be used to allow the
server to authenticate the client using certificate authentication
infrastructures.
EAP-Double-TLS allows anonymous exchanges and identity protection
against eavesdropping, man-in-the-middle and other cryptographic
attacks. It allows also the client and the server to update security
attributes for next sessions.
Further, EAP-Double-TLS provides a mechanism for session key
establishment for encryption protocols within PPP such as PPP-DES
[6] and PPP-3DES [7] protocols.
2.1 Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
3 Protocol overview
3.1 EAP identity protection
At the beginning of an EAP session, EAP identity (EAP-ID) is
transmitted in clear text, in the identity response message. This
parameter is used by the authenticator to forward EAP packets to the
authentication server which in turn uses it as an index for users’
database management.
In EAP-Double-TLS EAP-ID SHOULD be replaced either by the TLS
session_id value (see 3.2) or by the session-id concatenated to the
authentication server address (session_id@server.com).
This process will protect the user’s privacy against surveillance
and make the subscriber’s EAP exchanges untraceable to
Badra & Urien Informational - Expires November 2004 3
EAP-Double-TLS Authentication Protocol May 2004
eavesdroppers. In fact, the current session_id will be replaced by a
new one computing during phase 2 (see 3.2).
3.2 Overview of the EAP-Double-TLS conversation
In order to apply the use of shared key TLS, we suggest sharing
several triplets between the client and the server. Each triplet is
as follows:
{ session_Id, master_secret, cipher_suite }
The session_Id (in TLS terminology) is used to identify the triplet.
This session_Id corresponds to the value of the shared key and the
cipher_suite that represents the cryptographic option supported by
both the server and the client. The cipher_suite is initialized by
both the client and the server to a particular option.
Like others EAP methods (e.g. EAP-SIM [10]), the triplet MAY be
stored in a client smartcard.
As describes the figure 1, an EAP-Double-TLS negotiation comprises
two phases: the TLS PSK handshake phase and the TLS tunnel phase.
During phase 1, TLS PSK handshake is used for mutual authentication
and key generation. This phase uses a cipher suite allowing phase 2
to securely exchange TLS records.
The phase 2 of EAP-Double-TLS is the full TLS handshake defined in
[2]. During this phase, TLS records are exchanged in an encrypted
manner using the established tunnel in order to optionally perform
server and client authentication and to refresh the triplet
(session_Id, master_secret, cipher_suite) of the first phase.
Badra & Urien Informational - Expires November 2004 4
EAP-Double-TLS Authentication Protocol May 2004
Client server
------ Tunnel TLS ------
...................................
. +----------+ +----------+ .
. | Handshake| | Handshake| .
. | phase 2 | | phase 2 | .
. +-----^----+ +----^-----+ .
. | | .
+---------+ . | | . +---------+
|Handshake| . | | . |Handshake|
| phase 1 | . | | . | phase 1 |
+----^----+ . | | . +----^----+
| . | | . |
| . | | . |
| . +----v----+ +----v----+ . |
| . | Record | | Record | . |
| . | phase 2 |<----->| phase 2 | . |
| . +--^------+ +------^--+ . |
| ......|.....................|...... |
| | | |
| +----+ +----+ |
| | | |
+-v-------v-+ +-v-------v-+
| Record | | Record |
| phase 1 |<------------------------->| phase 1 |
+-----^-----+ +-----^-----+
| |
<=======================================>
Carrier Protocol (PPP, EAPOL, RADIUS, etc)
Figure 1 - Relationship between the EAP-Double-TLS peer and the EAP-
Double-TLS server.
3.2.1 Phase 1: TLS PSK Handshake
In phase 1, the EAP-Double-TLS begins with the authenticator sending
an EAP-Request/Identity packet to the peer. The peer will respond
with an EAP-Response/Identity packet to the authenticator,
containing the peer's UserId. Once this is established, the
authenticator MAY act as a pass-through device, with the EAP packets
received from the peer being encapsulated for transmission to a
RADIUS server or backend security server.
When the server receives the peer's Identity, it MUST respond with
an EAP-Double-TLS/Start packet. This is an EAP-Request packet with
EAP-Type= EAP-Double-TLS, the Start (S) bit set and no data.
When receiving this message, the peer will answer by EAP-Response
packet with EAP-Type= EAP-Double-TLS. The packet’s data field
encapsulates the TLS client_hello resumed handshake message. This
Badra & Urien Informational - Expires November 2004 5
EAP-Double-TLS Authentication Protocol May 2004
message contains, among others parameters, a random number and the
session_id corresponds to the master secret and the cipher_suite the
client wishes to use.
The server then checks its triplets’ database for a match. If a
match is found, the server responses with EAP-Request with EAP-Type=
EAP-Double-TLS. This packet will encapsulate the TLS server_hello
handshake with the same session_id value and another random number.
Following the hello messages, the server will send its change cipher
spec message and proceed directly to finished message. The finished
massage will serve to authenticate the server to the client since it
is calculated using the pre-installed key.
If the EAP server authenticates successfully (the peer will
calculate the same finished value using the pre-installed key), the
peer MUST send an EAP-Response packet of EAP-Type= EAP-Double-TLS,
and a data field encapsulates the change_cipher_spec and the
finished messages. Once this establishment is complete, the client
and server may begin to exchange phase 2 data.
If the EAP server authenticates unsuccessfully, the peer MAY send an
EAP-Response packet of EAP-Type= EAP-Double-TLS containing a TLS
Alert message identifying the reason for the failed authentication.
Alert messages with a level of fatal result in the immediate
termination of the connection.
In order to make sure that the server receives the TLS alert
message, the peer MUST wait for the server to reply before
terminating the conversation. Like in [3], the server MUST reply
with an EAP-Failure packet since server authentication failure is a
terminal condition.
If the peer authenticates unsuccessfully, the server MAY send an
EAP-Response packet of EAP-Type= EAP-Double-TLS containing a TLS
Alert message identifying the reason for the failed authentication.
Alert messages with a level of fatal result in the immediate
termination of the connection.
In order to make sure that the peer receives the TLS alert message,
the server MUST wait for the peer to reply before terminating the
conversation.
The EAP server then MUST respond with an EAP-Double-TLS/HelloRequest
message to indicate to the peer the success of phase 1 establishment
session and the beginning of phase 2.
3.2.2 Phase 2: TLS Handshake
In this phase, the TLS Record Layer is used to securely tunnel
information between client and server. This information is
Badra & Urien Informational - Expires November 2004 6
EAP-Double-TLS Authentication Protocol May 2004
encapsulated in sequences of TLS attributes, whose use and format
are described in [2].
In this phase, the server begins the exchange by sending the EAP-
Double-TLS/HelloRequest to the client. The hello request message is
defined in [2] and may be sent by the server at any time.
The client and the server continue the exchange of EAP packets to
complete the TLS handshake, as described in [2]. This phase is
completed when the client and the server exchange change cipher spec
and finished messages.
If this phase is successfully perfected, the client MUST send an
EAP-Response packet of EAP-Type= EAP-Double-TLS, and no data. The
EAP-Server then MUST respond with an EAP-Success message.
At this point, the server will distribute data connection keying
information and other authorization information to the access point.
Note that EAP-Double-TLS handshake uses pre-installed key and
products, as part of the TLS handshake protocol, new session key and
new master secret key. Thus, the server will distribute the pre-
installed key and will replace it and the correspondent session Id
with the new triplet (session_Id, master_secret, cipher_suite)
calculating during phase 2. The new triplet will be used for the
next EAP-Double-TLS session.
3.3. Retry behavior
See section 3.2 of RFC 2716.
3.4. Fragmentation
See section 3.3 of RFC 2716.
3.5. Key derivation
See section 3.5 of RFC 2716.
3.6. CCP and CCP negotiation
See section 3.6 and 3.7 of RFC 2716.
3.7. Examples
In the case where the EAP-Double-TLS is successful, the conversation
will be as follows:
Badra & Urien Informational - Expires November 2004 7
EAP-Double-TLS Authentication Protocol May 2004
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/Identity ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(EAP-Double-TLS Start)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS Hello Request)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS client_hello) ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS server_hello,
[TLS certificate],
[TLS server_key_exchange],
[TLS certificate_request],
TLS server_hello_done)
EAP-Response/
EAP-Type= EAP-Double-TLS
([TLS certificate],
TLS client_key_exchange,
[TLS certificate_verify],
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type= EAP-Double-TLS ->
<- EAP-Success
Badra & Urien Informational - Expires November 2004 8
EAP-Double-TLS Authentication Protocol May 2004
In the case where the EAP-Double-TLS is successful, and
fragmentation is required (during the phase 1, no fragmentation is
required), the conversation (during the phase 2) will be as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS Hello Request, S bit set)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
(Fragment 1: L, M bits set)
EAP-Response/
EAP-Type= EAP-Double-TLS ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(Fragment 2: M bits set)
EAP-Response/
EAP-Type= EAP-Double-TLS ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(Fragment 3)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS change_cipher_spec,
TLS finished)(Fragment 1:
L, M bits set)->
<- EAP-Success
During the phase 1 and in the case where the server authenticates to
the client successfully, but the client fails to authenticate to the
server, the conversation will be as follows:
Badra & Urien Informational - Expires November 2004 9
EAP-Double-TLS Authentication Protocol May 2004
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/Identity ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS Start)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request
EAP-Type= EAP-Double-TLS
(TLS Alert message)
EAP-Response/
EAP-Type= EAP-Double-TLS ->
<- EAP-Failure
(User Disconnected)
During the phase 1 and in the case where server authentication is
unsuccessful, the conversation will be as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/Identity ->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS Start)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type= EAP-Double-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type= EAP-Double-TLS
(TLS Alert message) ->
<- EAP-Failure
(User Disconnected)
Badra & Urien Informational - Expires November 2004 10
EAP-Double-TLS Authentication Protocol May 2004
4 EAP-Double-TLS protocol within EAP Smartcards
EAP-support in smartcards is described and detailed by an Internet
draft [8]. It is an opened, ISO 7816 microcontroller supporting most
authentication protocols. An EAP smartcard implements an EAP method
(EAP-TLS, etc) and works in cooperation with a smartcard interface
entity, which transparently sends and receives EAP messages to and
from this component.
Smartcard is one of the news technologies added to the world of
information technology. In fact, they can make significant impact on
current computer systems and network environments because of their
inherent security and mobility. Further, they are an effective means
of adding enhanced protection to wireless networks; namely 802.11
wireless LAN. Added to that, they are widely used in the Global
System for Mobile Communication (GSM) [9] in the form of a SIM
(Subscriber Identity Module) card for secure access to the mobile
network, for storing basic network information and for
accounting/billing procedures.
Smartcards have a bear particular attraction, as they generally
considered as the most secure computing platform. In fact, they
offer good tamper resistance. This means that certain physical
hardware and software protections are used, which makes it difficult
to extract or modify private and secret information in the module.
So it seems a good idea to store the (strong) master secret keys on
a smartcard. Further, smartcard deployment in a typical network such
as WLAN 802.11 [11] offers the enhanced functionality of tighter
authentication.
4.1 Fragmentation issues
Data is exchanged between the terminal and the smartcard through a
card acceptance device (CAD) in the form of messages exchanged from
the terminal to the card and vice versa. Data transport is
established by using Data Pocket called Application Protocol Data
Unit (APDU). Each APDU consists of two fields: 5 bytes header and 0-
255 bytes of data. The ISO [12] standard defines these
command/response packets that are used for reading, writing and
exchanging data between the host and the smartcard. These packets
transferred from the CAD to the module (command APDU) are followed
by a response APDU from the module back to the CAD.
The TLS Record Layer fragments information blocks into TLS records
carrying data in chunks of 16384 bytes or less [2]. Furthermore, TLS
message may carry multiple TLS records. Since the IEEE 802.3 MAC may
not send frames greater than 1518 bytes in length and because
fragmentation support is not provided by EAP, it is the
responsibility of EAP methods to provide the fragmentation required.
For that, EAP-Double-TLS extends the EAP-TLS segmentation method,
which defines a segmentation process that splits TLS messages in
Badra & Urien Informational - Expires November 2004 11
EAP-Double-TLS Authentication Protocol May 2004
smaller blocks, acknowledged by the recipient. In our
implementation, the RADIUS server generates acknowledged requests
and the supplicant answers by acknowledged responses.
EAP-TLS defines the fragmentation mechanism for data exchanged
between the server and the terminal. It will not define the data
segmentation between the terminal and the smartcard because the
latter is not readable to the EAP-TLS server. For that and in order
to allow smartcards use, a double segmentation mechanism was
introduces by our EAP-Double-TLS to forward TLS packets to the
smartcard. We defined this mechanism as following. First, TLS server
messages are divided in smaller segments (E1, E2), whose size is
typically 1400 bytes or less (figure 2). Next, the segments are
encapsulated in EAP-Double-TLS packets that are split in a
collection of APDUs (A11 .. A1p .. An1 .. Anq) in the form of
ISO7816 commands. Afterwards, the APDUs (each APDU’s size is around
240 bytes) are forwarded to the EAP-Double-TLS smartcard. Note that
for each APDU received by the smartcard, an APDU response, with 2
bytes of data, is generated to inform the supplicant of the APDU’s
status (if the APDU was arrived and correctly processed or no).
Badra & Urien Informational - Expires November 2004 12
EAP-Double-TLS Authentication Protocol May 2004
EAP-Double-TLS Supplicant Authentication
Smartcard Smartcard interface server
+---------------------+ +-------------+ +--------------+
| | | | | |
TLS EAP-Double-TLS EAP-Double-TLS TLS
----- --------- --------- -----
Send: TLS
message M1 = E1 .. En
EAP-Double-TLS:
E1 <= 1400 octets
<-- Frag E1 = A11 .. A1p
<-- APDU : Frag A11
(<= 240 octets)
APDU -->
Ack A11 .
. .
.
<-- APDU : Frag A1p
(<= 240 octets)
APDU -->
Ack A1p
Ack E1 -->
.
. .
. EAP-Double-TLS:
En <= 1400 octets
<-- Frag En = An1 .. Alq
<-- APDU : Frag An1
(<= 240 octets)
APDU -->
Ack Ap1 .
. .
.
<-- APDU : Frag Anq
(<= 240 octets)
<----
Receive: TLS
message M1
Send: TLS
message M2= F1 .. Fk
= A1 .. Ak
EAP-Double-TLS: F1
(<= 240 octets) -->
<-- EAP-TLS
. Ack F1
. .
. .
reassembly M2 fragments
Badra & Urien Informational - Expires November 2004 13
EAP-Double-TLS Authentication Protocol May 2004
and send the result using
packets of 1400 octets or less
-->
. <-- EAP-TLS
. Ack
EAP-Double-TLS: Fi
(<= 240 octets) -->
<-- EAP-TLS
. Ack Fi
.
EAP-Double-TLS: Fk .
(<= 240 octets) --> . .
<-- EAP-TLS .
Ack Fk
-->
Receive: TLS
message M2
Figure 2 - Smartcard double segmentation using EAP-Double-TLS
Authentication Protocol
However, for the smartcard part and in order to prevent multiple
segmentation and re-assembly operations, the maximum EAP message
length of a no fragmented packet SHALL be set to 240 bytes. For a
fragmented EAP message, the maximum length value shall be 240 bytes.
As defined in EAP-TLS, when the EAP-Double-TLS smartcard receives an
EAP-Request packet with the M bit set, it MUST respond with an EAP-
Response with EAP-Type=EAP-TLS and no data. This serves as a
fragment ACK.
5. Detailed description of the EAP-Double-TLS protocol
This section shows the conversation between the peer and the
authenticator using EAP-Double-TLS protocol. It takes the same
notifications introduced in the section 4 of RFC2716 [3].
5.1. EAP-Double-TLS Packet Format
A summary of the EAP-Double-TLS Request/Response packet format is
shown below. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Badra & Urien Informational - Expires November 2004 14
EAP-Double-TLS Authentication Protocol May 2004
The description of the EAP/Response/identity is detailed according
to the IETF RFC 2284.
5.2. EAP-Double-TLS Request Packet
A summary of the EAP-Double-TLS Request packet format is shown
below. 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=01 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flag | EAP-Double-TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-Double-TLS Message Length | EAP-Double-TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1
Identifier
The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each Request
packet.
Length
The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, and Double-TLS
Response fields.
Type
20 - EAP Double TLS
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+
L = Length included
M = More fragments
S = EAP-Double-TLS start
R = Reserved
Badra & Urien Informational - Expires November 2004 15
EAP-Double-TLS Authentication Protocol May 2004
The L bit (length included) is set to indicate the presence of the
four octet Double-TLS Message Length field, and MUST be set for the
first fragment of a fragmented EAP-Double-TLS message or set of
messages. The M bit (more fragments) is set on all but the last
fragment. The S Bit (EAP-Double-TLS start) is set in an EAP-Double-
TLS Start message. This differentiates the EAP-Double-TLS Start
message from a fragment acknowledgement.
Double-TLS Message Length
The Double-TLS Message Length field is four octets, and is present
only if the L bit is set. This field provides the total length of
the Double-TLS message or set of messages that is being fragmented.
Double-TLS data
The Double-TLS data consists of the encapsulated Double-TLS packet
in TLS record format.
5.3. EAP-Double-TLS Response Packet
A summary of the EAP-Double-TLS Request packet format is shown
below. 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=01 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flag | EAP-Double-TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-Double-TLS Message Length | EAP-Double-TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2
Identifier
The Identifier field is one octet and MUST match the Identifier
field from the corresponding request.
Length
The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, and Double-TLS
Response fields.
Type
Badra & Urien Informational - Expires November 2004 16
EAP-Double-TLS Authentication Protocol May 2004
20 - EAP Double TLS
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+
L = Length included
M = More fragments
S = EAP-Double-TLS start
R = Reserved
The L bit (length included) is set to indicate the presence of the
four octet Double-TLS Message Length field, and MUST be set for the
first fragment of a fragmented EAP-Double-TLS message or set of
messages. The M bit (more fragments) is set on all but the last
fragment. The S Bit (EAP-Double-TLS start) is set in an EAP-Double-
TLS Start message. This differentiates the EAP-Double-TLS Start
message from a fragment acknowledgement.
Double-TLS Message Length
The Double-TLS Message Length field is four octets, and is present
only if the L bit is set. This field provides the total length of
the Double-TLS message or set of messages that is being fragmented.
Double-TLS data
The Double-TLS data consists of the encapsulated Double-TLS packet
in TLS record format.
6 Security Considerations
The EAP-Double-TLS server MUST stock the triplets (session_Id,
master_secret, cipher_suite) in a secure and protected manner in
order to prevent attackers from retrieving the master_secret values.
On the other hand, this document does not introduce any additional
security considerations in comparison to TLS, EAP-TLS and EAP
smartcards.
7 Intellectual Property Right Notice
To be specify according to the author and participant.
8 Acknowledgements
This EAP method has been inspired by [3] and [2]. Thus, it reused
extracts of these documents.
Badra & Urien Informational - Expires November 2004 17
EAP-Double-TLS Authentication Protocol May 2004
9 References
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, November 1998.
[3] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[4] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[5] Blunk, L. et al; "Extensible Authentication Protocol (EAP)",
Draft-ietf-eap-rfc2284bis-06.txt, October 2003.
[6] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
[7] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.
[8] Urien, P., et al., 2004. "EAP support in smartcards", draft-
urien-eap-smartcard-04.txt, Internet draft (work in progress),
August 2004.
[9] GSM Technical Specification GSM 11.11. Digital cellular
telecommunications system (Phase 2+); Specification of the
Subscriber Identity Module - Mobile Equipment (SIM – ME)
interface, Version 5.0.0, December 1995.
[10] Haverinen, H. and J. Salowey, "EAP SIM Authentication",
draft-haverinen-pppext-eap-sim-12.txt, Internet draft (work in
progress), October 2003.
[11] IEEE Std. 802.11, IEEE Standard for Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications, 1997.
[12] ISO 7816-4 SmartCard Standard: Part 4: Inter industry Commands
for Interchange, 1995.
10 Author's Addresses
Mohamad Badra
ENST
46 rue Barrault
75013 Paris Phone: NA
France Email: Mohamad.Badra@enst.fr
Badra & Urien Informational - Expires November 2004 18
EAP-Double-TLS Authentication Protocol May 2004
Pascal Urien
ENST
46 rue Barrault
75013 Paris Phone: NA
France Email: Pascal.Urien@enst.fr
Badra & Urien Informational - Expires November 2004 19