Internet Engineering Task Force M. Badra
INTERNET DRAFT P. Urien
ENST Paris
Expires: December 2006 June 15, 2006
EAP-Double-TLS Authentication Protocol
<draft-badra-eap-double-tls-05.txt>
Status
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 obsoleted 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
This Internet-Draft will expire on December 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
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 peer and
server and to share a secret key. EAP-Double-TLS extends this
authentication negotiation by establishing a secure connection based
on the use of Pre Shared Keys (PSK). The secure connection may then
be used to allow the server and the peer to securely exchange their
identity and to update security attributes for next sessions.
EAP-Double-TLS allows the peer and the server to establish keying
material for use in the data connection between the peer and the
authenticator. The keying material is established implicitly between
peer and server based on the TLS Pre-Shared-Key handshake.
Badra & Urien Expires December 2006 [Page 1]
Internet-Draft EAP-Double-TLS June 2006
It provides additional security services such as anonymous exchanges
and identity protection against eavesdropping and the PFS (Perfect
Forward Secrecy).
Table of Contents
1 Abstract.........................................................1
2 Introduction.....................................................3
2.1 Requirements language.......................................4
3 Protocol design considerations and overview......................4
3.1 EAP identity protection.....................................4
3.2 Structure of the session identifier.........................4
3.3 Overview of the EAP-Double-TLS conversation.................5
3.3.1 Phase 1: Handshake....................................7
3.3.2 Phase 2...............................................8
3.3.2.1 Case 1: TLS Handshake...............................9
3.3.2.2 Case 2: AVP Exchanges...............................9
3.4. Retry behavior............................................10
3.5. Fragmentation.............................................10
3.6. Key derivation............................................10
3.7. CCP and CCP negotiation...................................11
3.8. Inner method encapsulation................................11
3.7. Examples.....................................................12
4 Detailed description of the EAP-Double-TLS protocol.............15
4.1 EAP-Double-TLS Packet Format...............................15
4.2 EAP-Double-TLS Request Packet..............................16
4.3 EAP-Double-TLS Response Packet.............................17
5 Security Considerations.........................................18
5.1 Security claims............................................18
5.1.1 Authentication, confidentiality, and Integrity.
Replay, man in-the-middle and dictionary attack protection.18
5.1.2 Session independence or perfect forward secrecy....19
5.1.4 Key strength.......................................20
5.1.5 Channel binding....................................20
5.1.6 Fast reconnect.....................................20
7 IANA Considerations.............................................20
Acknowledgements..................................................20
References........................................................20
Author's Addresses................................................21
Appendix A. EAP-Double-TLS protocol within EAP Smartcards.........21
A.1 Fragmentation issues.......................................22
Badra & Urien Expires December 2006 [Page 2]
Internet-Draft EAP-Double-TLS June 2006
2 Introduction
The Extensible Authentication Protocol (EAP) [EAP] defines a
mechanism that may be extended with additional authentication
protocols within PPP [PPP] such as MD5 [MD5], TLS [TLS] and PEAP
[PEAP].
The EAP-TLS authentication method, described in [EAPTLS], provides a
standard method for mutual authentication and key generation.
However, this method requires the use of certificates and Public Key
Infrastructures (PKI) that MUST be well maintained. On the other
hand, this protocol can not provide some security services, such as
the supplicant's identity protection.
TLS itself allows the peer and the server to resume secure sessions
[TLS]. A secure connection may be terminated and resumed later.
Secure sessions can be resumed if the peer and the server agree.
During a resume Handshake, both the peer and the serve will use the
old master_secret and the new random numbers to calculate new
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.
Shared-key handshake runs as a resume session using pre-installed
secret key. A detailed description may be found in [SKTLS]. However,
it may be an advantageous to use shared-key authentication handshake
instead of PKI based certificates. Further, shared-key TLS does not
require any asymmetric cryptographic operation (e.g. asymmetric
encrypt/decrypt or certificates verification).
EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS,
a TLS handshake is used to mutually authenticate a peer and a
server. EAP-Double-TLS extends this authentication negotiation;
using the PSK authentication.
EAP-Double-TLS is composed of two phases. The first phase is based
on the use of PSKs to mutually authenticate the peer and the server
and to generate cryptographic keys, as it is defined in [SKTLS].
The second phase is used to allow additional security services, such
as identity protection. It allows also the peer and the server to
update their security attributes for next sessions and then to
ensure the PFS (Perfect Forward Secrecy).
EAP-Double-TLS provides a mechanism for session key establishment
for encryption protocols within PPP such as PPP-DES [PPPDES] and
PPP-3DES [PPP3DES] protocols.
Badra & Urien Expires December 2006 [Page 3]
Internet-Draft EAP-Double-TLS June 2006
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 design considerations and 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
eavesdroppers. In fact, the current session_id will be replaced by a
new one computing or generating during phase 2 (see 3.2).
3.2 Structure of the session identifier
According to TLS, the peer hello message includes a variable length
session identifier. If not empty, the identifier identifies a TLS
session already established between the peer and the authentication
server.
EAP-Double-TLS defines a new structure of the session identifier,
used during the first phase. The structure is defined as follows:
struct {
opaque random_bytes<0..24>;
SecondPhaseExchange second_phase_exchange<1..8>;
} SessionID;
SecondPhaseExchange None = { 0x00 };
SecondPhaseExchange TLS = { 0x01 };
SecondPhaseExchange TLS_RSA_anon = { 0x02 };
SecondPhaseExchange TLS_DH_anon = { 0x03 };
SecondPhaseExchange AVP = { 0x04 };
This new structure allows to the peer and to the server to negotiate
the key exchange method during the second phase. These methods are
sent by the peer, ordered according to its preference. There MUST be
Badra & Urien Expires December 2006 [Page 4]
Internet-Draft EAP-Double-TLS June 2006
at least one method acceptable to the server. This document defines
five methods: None, TLS, TLS_RSA_anon, TLS_DH_anon and AVP.
None refers to the option that means that the peer is satisfied by
running TLS resumed handshake (phase 2 will then not be executed).
TLS refers to the RFC2246 authentication based-certificate,
TLS_RSA_anon and TLS_DH_anon refers respectively to unauthenticated
(or ephemeral) RSA key exchange and Diffie_Hellman anonymous key
exchange. These last three types allow both the peer and the server
to generate new session_id and new master_secret. Concerning the
attribute-value pairs (AVPs), it is used to allow the server to send
back to the peer, a new master_secret and a new session_id. More
details are given through the document.
Note that TLS generates a variable length session identifier, which
MAY be at maximum 32 bytes. EAP-Double-TLS implementation MUST then
generate a variable length session identifier smaller than 24 bytes.
3.3 Overview of the EAP-Double-TLS conversation
In order to apply the use of shared key TLS, this document suggests
sharing a TLS session between the peer and the server. The session
is identified by a 24-byte session_id. It corresponds to, among
others, the value of the master_secret and the cipher_suite. The
cipher_suite represents the cryptographic option supported by both
the server and the peer and it is initialized by them to a
particular option.
In general, EAP-Double-TLS negotiation consists in two phases:
During the first phase, Shared-key handshake is used for mutual
authentication and key generation. This phase uses a cipher suite
allowing phase 2 to securely exchange TLS records or AVP.
peer Server
---- ------
ClientHello -------->
(session_id) ServerHello
ChangeCipherSpec
<-------- Finished
ChangeCipherSpec
Finished -------->
Figure 1: Phase 1, the Shared-key handshake
The second phase MAY be a full TLS handshake with mutual
authentication, only server-side authentication, or with anonymous
key exchange. Nevertheless, it MAY be an exchange of AVPs. In this
latter case, the server MUST generate a new (session_id,
Badra & Urien Expires December 2006 [Page 5]
Internet-Draft EAP-Double-TLS June 2006
master_secret) and send them to the peer, over a link encrypted with
the cryptographic keys generated during the first phase (examples of
exchanges are given in the section 3.7).
peer 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 2- Relationship between the EAP-Double-TLS peer and the EAP-
Double-TLS server, in the case of the use of TLS during
the second phase.
Badra & Urien Expires December 2006 [Page 6]
Internet-Draft EAP-Double-TLS June 2006
peer server
---- ------
AVP exchange
................................
. +--------+ +--- ----+ .
. | AVP | | AVP | .
. |Phase 2 | |Phase 2 | .
. +---^----+ +---^----+ .
......|................|........
+---------+ | | +---------+
|Handshake| | | |Handshake|
| phase 1 | | | | phase 1 |
+----^----+ | | +----^----+
| | | |
| | | |
| | | |
+-v------------v---+ +-v-----------v---+
| Record (Phase 1)|<-------->| Record(Phase 1)|
+-----^------------+ +-----^-----------+
| |
<=============================>
Carrier Protocol (PPP, EAPOL, RADIUS, etc)
Figure 3- Relationship between the EAP-Double-TLS peer and the EAP-
Double-TLS server, in the case of AVP exchange during the
second phase.
3.3.1 Phase 1: Handshake
In the first phase, 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 (User Identifier). 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 back-end 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 data field encapsulates
the TLS client_hello resumed handshake message. This message
contains, among others parameters, a random number and the
session_id corresponds to the TLS shared session the peer wishes to
use. The session_id contains both the SessionID.random_bytes and
SessionID.SecondPhaseExchange.
Badra & Urien Expires December 2006 [Page 7]
Internet-Draft EAP-Double-TLS June 2006
The server then checks its sessions' database for a match. If a
match is found and that the server is able to negotiate one of the
second_phase_exchange methods supported by the peer, the server
replays with EAP-Request with an EAP-Type= EAP-Double-TLS. This
packet will encapsulate the TLS server_hello handshake message. This
message transports, among others, the same value of
SessionID.random_bytes and another random number. The session_id
includes the second_phase_exchange method selected by the server
(SessionID.SecondPhaseExchange).
After the hello messages, the server will send its TLS change cipher
spec message and proceed directly to finished message. The finished
message will serve to authenticate the server to the peer since it
is encrypted and MACed using keys derived from the shared key.
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.
A fatal error message results 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 [EAPTLS], the server MUST
reply with an EAP-Failure packet since server authentication failure
is a terminal condition.
If the EAP server authenticates successfully (the peer decrypts the
finished message and verify the MAC), the peer MUST send an EAP-
Response packet of EAP-Type= EAP-Double-TLS, that transports the
change cipher spec and the finished messages. Once this
establishment is complete, the peer and the server MAY start the
second phase. Otherwise, the server will send data connection keying
information and other authorization information to the
authenticator.
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.
3.3.2 Phase 2
EAP-Double-TLS Phase 2 will occur if the establishment of its first
phase is successfully terminated. Phase 2 is used to ensure
Badra & Urien Expires December 2006 [Page 8]
Internet-Draft EAP-Double-TLS June 2006
additional services such as peer identity protection and PFS. This
phase MAY be established by executing a TLS session or by exchanging
AVPs between the peer and the server.
3.3.2.1 Case 1: TLS Handshake
During the second phase, the TLS Record layer is used to securely
tunnel data related to the second phase. TLS session data will be
encapsulated in sequences of TLS attributes, whose use and format
are described in [TLS].
The peer starts the second phase by sending its hello. The
ClientHello follows the Finished message sent by the peer during the
first phase
Next, the peer and the server continue to exchange EAP packets until
either the TLS session is successfully established or an error
occurs. If the session is successfully established, the peer MUST
send an EAP-Response packet of EAP-Type= EAP-Double-TLS, and no
data. The EAP-Server must then respond with an EAP-Success message.
At this point, the server distributes data connection keying
information and other authorization data to the authenticator, which
are derived from the shared key that was used during the first
phase. Next, the server and the peer replace the security parameters
(e.g. the shared key and its identity) with the security parameters
that are generated by TLS during the second phase. These new TLS
security parameters will be then used during the next EAP-Double-TLS
sessions.
3.3.2.2 Case 2: AVP Exchanges
The second phase MAY be established using AVP exchanges, if the peer
and the server agree. The AVP is securely tunneled between the
client and server by TLS Record.
This document defines the AVP Session-Id-Master-Secret (AVP Code
TBS). The Data field is 48 or more octets and contains a new
(session_id, master_secret) generated by the server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code (TBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data = master_secret#session_id (# means concatenation)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Badra & Urien Expires December 2006 [Page 9]
Internet-Draft EAP-Double-TLS June 2006
In this case of AVPs exchange, the server encodes a new 24-byte
session_id (e.g. SessionID.random_bytes) and a new 48-byte
master_secret, encapsulates them in the AVP Session-Id-Master-
Secret, passes the result to the TLS record layer, and sends the
resulting data to the peer. The peer recovers the AVP in clear text
from the TLS record layer. If this is successfully established, the
peer MUST send an EAP-Response packet of EAP-Type= EAP-Double-TLS,
and no data. The EAP-Server must then respond with an EAP-Success
message.
At this point, the peer and the server update their shared
master_secret and session_id with the new ones generated by the
server and delivered to the peer. Next, the server distributes data
connection keying information and other authorization data to the
authenticator.
3.4. Retry behavior
See section 3.2 of RFC 2716.
3.5. Fragmentation
See section 3.3 of RFC 2716.
3.6. Key derivation
EAP-Double-TLS derives keying material after each successful
negotiation in each phase. The first phase allows the peer and the
server to generate a 48-byte master_secret (MS1) by applying the
TLS-PRF (Pseudo Random Function) [TLS] on the shared key (SK),
ClientHello.random and ServerHello.random:
MS1 = PRF(SK, "master_secret",
ClientHello.random + ServerHello.random)[0..48]
This key is used to derive keying material used to encrypt and to
calculate the MAC of each message. Keys derived from MS1 are then
delivered to the authenticator for additional keys computation.
When TLS is selected as second_key_exchange, the peer and the server
will exchange new random values. The peer is also able to randomly
generate a secret key (the pre_master_secret in TLS terminology).
This key is sent securely to the server using the server public key
and it is used to generate a new and fresh master_secret key (FMS)
by applying the PRF on, among others, the pre_master_secret (PMS).
The generated key will be then used during the future EAP-Double-TLS
session.
FMS = PRF(PMS, "master_secret",
ClientHello.random + ServerHello.random) [0..48]
Badra & Urien Expires December 2006 [Page 10]
Internet-Draft EAP-Double-TLS June 2006
When AVP is selected as second_key_exchange, both the peer and the
server will replace the old master_secret and the old session_id
with the new ones that are generated by the server and delivered to
the peer.
Note: the client and the server can derive and compute the required
keys (e.g. MSK, EMSK, etc.) by applying the TLS-PRF on the MS1 and
the random values of the first phase. PRF's P_hash can be iterated
as many times as is necessary to produce the required key length
(e.g., OutputKey = PRF(MS1, "output_key",
ClientHello.random + ServerHello.random) [OutputLength])
3.7. CCP and CCP negotiation
See section 3.6 and 3.7 of RFC 2716.
3.8. Inner method encapsulation
As stated before, EAP-Double-TLS uses the TLS record layer to tunnel
information between the peer and the server to, among others
operations perform additional authentication. In this optic, EAP-
Double-TLS reuses the attribute-value pairs (AVPs) defined in
[EAPTTLS].
Badra & Urien Expires December 2006 [Page 11]
Internet-Draft EAP-Double-TLS June 2006
3.7. Examples
The following exchanges show where TLS is selected as
second_key_exchange:
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
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 Expires December 2006 [Page 12]
Internet-Draft EAP-Double-TLS June 2006
The following exchanges show where AVP is selected as
second_key_exchange:
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
(AVP
[session_id, master_secret])
EAP-Response/
EAP-Type= EAP-Double-TLS ->
<- EAP-Success
The following exchanges show where TLS is selected as
second_key_exchange 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)
Badra & Urien Expires December 2006 [Page 13]
Internet-Draft EAP-Double-TLS June 2006
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 peer successfully, but the peer fails to authenticate to the
server, 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 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)
Badra & Urien Expires December 2006 [Page 14]
Internet-Draft EAP-Double-TLS June 2006
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)
4 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 [EAPTLS].
4.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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The description of the EAP/Response/identity is detailed according
to the IETF RFC 2284.
Badra & Urien Expires December 2006 [Page 15]
Internet-Draft EAP-Double-TLS June 2006
4.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
TBD - 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
Badra & Urien Expires December 2006 [Page 16]
Internet-Draft EAP-Double-TLS June 2006
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.
4.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
TBD - EAP Double TLS
Badra & Urien Expires December 2006 [Page 17]
Internet-Draft EAP-Double-TLS June 2006
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.
5 Security Considerations
The EAP-Double-TLS server MUST stock the TLS session in a secure and
protected manner in order to prevent attackers from retrieving the
master_secret values and session' parameters.
5.1 Security claims
This section describes EAP-Double-TLS in terms of specific security
terminology as required by [EAP].
5.1.1 Authentication, confidentiality, and Integrity. Replay, man
in-the-middle and dictionary attack protection
EAP-Double-TLS provides mutual authentication using the shared key
during the first phase. EAP-Double-TLS mitigates man-in-the-middle
vulnerabilities because of the mutual authentication established
during the first phase. The confidentiality and integrity are
provided using the negotiated cryptographic algorithms as well as
Badra & Urien Expires December 2006 [Page 18]
Internet-Draft EAP-Double-TLS June 2006
encryption and authentication keys derived from the shared key.
Furthermore and during the second phase, messages notification
(failure or success) are also protected against man-in-the-middle
and eavesdropping attacks. This is because they are encrypted with
the tunnel established during the first phase. On the other hand and
like TLS, EAP-Double-TLS natively protects against replay protection
attacks using sequence numbers. The use of sequence numbers and of
strong cryptographic algorithms (e.g., AES) defends the protocol
against dictionary attacks.
5.1.2 Session independence or perfect forward secrecy
EAP-Double-TLS protocol independently generates keys per session and
it MAY uses ephemeral public/private keys during its second phase.
As a result, it provides Perfect Forward Secrecy (i.e. ephemeral
Deffie-Hellman and RSA public keys are both supported by EAP-Double-
TLS as key exchange methods in the case where TLS is selected as
second_phase_exchange). Added to that, passive attacks (such as
capture of the EAP conversation) or active attacks (including the
recovery of the shared key) do not entail the compromising of prior
shared keys and are thus incapable of decrypting previous sessions.
In the case of AVP, the PFS is provided, by generating new secret
key which is independent to any old secret.
5.1.3 Protected cipher suite negotiation and user identity
protection
EAP-Double-TLS ensures cipher suite negotiation in a protected
manner. In fact, it uses the same TLS principle that offers an
integrated mechanism to protect cipher suite negotiation. This is
because at the end of the first phase, the peer and server exchange
the finished messages. These messages are always sent immediately
after a change cipher spec message to verify that the key exchange
and authentication processes were successful. They are the first
messages protected with the just-negotiated algorithms and the
secret key, and it is computed in function of, among others, all
handshake messages data, including the negotiated cipher suite.
Concerning the identity protection and as we cited above, the shared
key and its identity are replaced with new values if the second
phase of EAP-Double-TLS is successfully terminated. This process
will protect the user's privacy and identity against surveillance
and make the subscriber's EAP exchanges untraceable to
eavesdroppers. In fact, the EAP-ID value used at the beginning and
the session_id used during the first phase will be replaced by a new
session_id securely computing and generating during the EAP-Double-
TLS second phase.
Badra & Urien Expires December 2006 [Page 19]
Internet-Draft EAP-Double-TLS June 2006
5.1.4 Key strength
EAP-Double-TLS reuses the TLS-PRF for keys generation (See [TLS]).
5.1.5 Channel binding
EAP-Double-TLS does not explicitly include any channel binding.
5.1.6 Fast reconnect
Due to the nature of wireless connections, the peer MAY be
disconnected at any time. Fortunately, the EAP-Double-TLS peer and
the server don't have to go through the entire process every time
they want to communicate. While EAP-Double-TLS is based on TLS, fast
reconnection option is implicitly included; executing TLS resumed
Handshake (as described in phase 1).
7 IANA Considerations
This document requires IANA to allocate a new EAP Type for EAP-
Double-TLS, new AVP Code for Session-Id-Master-Secret AVP and for
values related to the SecondPhaseExchange.
Acknowledgements
This EAP method has been inspired by [EAPTLS] and [TLS]. Thus, it
reused extracts of these documents.
References
[TLS] Dierks, T., et. al, "The TLS Protocol Version 1.0", RFC
2246, November 1998.
[SKTLS] Gutmann, P., "Use of Shared Keys in the TLS Protocol",
draft-ietf-tls-sharedkeys-02 (expired), October 2003.
[PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[EAPTLS] Aboba, B., and D., Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[MD5] Rivest, R., and S., Dusse, "The MD5 Message-Digest
Algorithm", RFC 1321, April 1992.
[EAP] Aboba, B., et. al., "PPP Extensible Authentication
Protocol EAP)", RFC 3748, June 2004.
[PPPDES] Sklower, K., and G., Meyer, "The PPP DES Encryption
Protocol, Version 2 (DESE-bis)", RFC 2419, September
Badra & Urien Expires December 2006 [Page 20]
Internet-Draft EAP-Double-TLS June 2006
1998.
[PPP3DES] Hummert, K., "The PPP Triple-DES Encryption Protocol
(3DESE)", RFC 2420, September 1998.
[EAPTTLS] Funk, P., et. al., "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)" draft-ietf-pppext-eap-ttls-05.txt,
Internet draft (work in progress), August 2004.
[PEAP] TBC
[EAPSC] Urien, P., et. al., "EAP support in smartcards",
draft-urien-eap-smartcard-08.txt, Internet draft (work in
progress), July 2005.
[GSM] 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.
[802.11] IEEE Std. 802.11, IEEE Standard for Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications, 1997.
[ISOAPDU] ISO 7816-4 SmartCard Standard: Part 4: Inter industry
Commands for Interchange, 1995.
Author's Addresses
Mohamad Badra
ENST
46 rue Barrault
75634 Paris Phone: NA
France Email: Mohamad.Badra@enst.fr
Pascal Urien
ENST
46 rue Barrault
75634 Paris Phone: NA
France Email: Pascal.Urien@enst.fr
Appendix A. EAP-Double-TLS protocol within EAP Smartcards
EAP-support in smartcards is described and detailed by an Internet
draft [EAPSC]. 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
Badra & Urien Expires December 2006 [Page 21]
Internet-Draft EAP-Double-TLS June 2006
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) [GSM] 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 [802.11] offers the enhanced functionality of tighter
authentication.
A.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 [ISOAPDU] 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 [TLS]. 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
smaller blocks, acknowledged by the recipient. In this context, the
RADIUS server generates acknowledged requests and the supplicant
answers by acknowledged responses.
Badra & Urien Expires December 2006 [Page 22]
Internet-Draft EAP-Double-TLS June 2006
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 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 3). 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 APDUs 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 APDUs
status (if the APDU was arrived and correctly processed or no).
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 .
. .
Badra & Urien Expires December 2006 [Page 23]
Internet-Draft EAP-Double-TLS June 2006
.
<-- 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
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 3 - 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.
Badra & Urien Expires December 2006 [Page 24]
Internet-Draft EAP-Double-TLS June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the IETF's procedures with respect to rights in IETF
Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Badra & Urien Expires December 2006 [Page 25]