Internet Draft H. Andersson
S. Josefsson
RSA Security
August 2001
Protecting EAP with TLS (EAP-TLS-EAP)
<draft-josefsson-pppext-eap-tls-eap-00>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 made 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 may be found at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories may be found at
http://www.ietf.org/shadow.html.
Abstract
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for mutual authentication and session key generation in a
roaming environment. The server authentication and the negotiation of
the session key is done using the PPP EAP Transport Layer Security
(TLS) Authentication Protocol. The user authenticates using a PPP EAP
mechanism, integrity and privacy protected by TLS. In essence, a
wrapping of EAP inside TLS inside EAP is specified. An important
application discussed in this document is to provide authentication
of access points and stations within an IEEE 802.11 Wireless Local
Area Network (WLAN), but other applications such as LAN access over
Bluetooth might also be considered in the future.
1. Introduction
The PPP Extensible Authentication Protocol [2] defines a general
authentication framework. This document specifies an EAP mechanism
for mutual authentication and session key generation, with support
for a roaming environment. The connection is made, using EAP
terminology, between a peer and an authenticator. The (public-key)
Andersson, Josefsson Expires: February 2002 [Page 1]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
authentication of the authenticator and the negotiation of the
session key is done using the PPP EAP Transport Layer Security (TLS)
Authentication Protocol [1]. The user performs authentication using
any defined PPP EAP mechanism, see [2].
Section 2 defines the model and some terminology. A overview of this
EAP mechanism is given in Section 3, and Section 4 gives a detailed
description of packet formats. In Section 5, the protocol is applied
to an IEEE 802.11 Wireless Local Area Network (WLAN). Finally,
Section 6 discusses security issues.
2. Model and Terminology
The term peer refers to a client, acting on behalf of a user, that
requests access to a network. The entity contacted by the peer is
denoted authenticator. The authenticator is in turn connected to an
entity called back-end server. In our model, the authenticator is
acting merely as a passthrough device during the authentication
phase, forwarding each packet received from the peer to the back-end
server, and vice versa. It should be noted that the back-end server
may be a logical entity located in the same physical device as the
authenticator. The realisation of the back-end server and the
communication between the authenticator and backend server are
outside the scope of this document.
+---+
| B |
| a |
| c |
| k | +---------------+ +--------+
| | <-----------> | Authenticator | <-----> | Peer |
| e | +---------------+ EAP +--------+
| n | .
| d | .
| | .
| S | +---------------+ . EAP
| e | <-----------> | Authenticator | .
| r | +---------------+
| v |
| e |
| r |
+---+
An overview of the assumed environment is found in the figure above.
The peer initially contacts the first authenticator (at the top of
the figure). The dotted line between the peer and the second
authenticator symbolizes roaming, i.e. the situation where the peer
transits from one authenticator to another while still maintaining
Andersson, Josefsson Expires: February 2002 [Page 2]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
server and user authentication. It is assumed that the same logical
back-end server sits behind all of the authenticators contacted by
the peer. In practice, the back-end server may be distributed over
several machines, for e.g. fail-over or load-balancing purposes, but
in this document we regard them as one logical unit.
This document frequently uses the following terms and abbreviations:
authenticator
The end of the link requiring the authentication.
EAP
Extensible Authentication Protocol. After a connection link has
been established between two entities, an authentication phase may
take place. The PPP EAP protocol [2] is a general authentication
protocol. The authenticator sends one or more requests to the
peer, and the peer sends a response in reply to each request. The
authenticator ends the authentication phase with a success or
failure message.
peer
The other end of the point-to-point link; the end which is
being authenticated by the authenticator.
TLS
Transport Layer Security. Internet security protocol for
point-to-point connections (enhancement of Secure Sockets Layer,
SSL). Defined in [3]. Under this protocol, two entities are able
to authenticate each other and to establish a secure link. TLS
operates at the transport layer. The protocol PPP EAP TLS [1]
describes how to provide for TLS mechanisms within EAP.
3. Overview of the conversation
A peer wishes to set up a connection with an authenticator, for the
purpose of authenticating itself to e.g. a wireless infrastructure.
In our model, the authenticators are in connection with an back-end
server. The following describes each EAP packet that is sent between
the authenticator and peer during the EAP connection.
3.1. Initial registration
The first two steps are described in detail in Section 3.1 of [2], we
include them here for illustration. Note that as per the EAP
Andersson, Josefsson Expires: February 2002 [Page 3]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
specification, this Identity exchange is not required.
1. The first EAP Request packet sent by the authenticator to the
peer is of type Identity. The data field may optionally contain a
displayable message.
2. The peer responds with an EAP-Response packet of type Identity.
Note that the data field of the Identity packet, which contains the
peer identity, cannot be assumed to be integrity or privacy
protected. Accordingly, it should not be used instead of the peer
identity sent inside the TLS channel later on.
The entities now initiate an EAP-TLS conversation. The following is
an example of a successful TLS handshake within EAP -- the packets
are described in detail in Section 4 of [1]. The EAP method defined
in this document does not terminate the TLS connection once the TLS
handshake phase is concluded (and thus differs subtly from how TLS is
used in [1]). The retry behavior and fragmentation concerns of
section 3.2 and 3.3 of [1] are still applicable (but not illustrated
in this example).
3. The authenticator sends an EAP-TLS packet of type Start with empty
data field. The data field of following packets will encapsulate
TLS Handshake Protocol messages.
4. Client hello: The peer sends a preferred TLS protocol version
number, an empty Session ID field, a list of preferred
cryptographic algorithms, and a random number to initialize the
TLS handshake.
5. Server hello: The authenticator responds with a selected TLS
protocol version number, a new Session ID, a list of selected
cryptographic algorithms, and another random number. Server
certificate: The authenticator then sends a chain of X.509v3
certificates, starting with its own certificate. The packet may
optionally include a server key exchange. Server hello
done: Finally, the authenticator indicates the end of this message
stream. (Note that the authenticator must NOT send any certificate
request.)
6. Client key exchange: The peer generates a premaster secret,
encrypts it using the public key obtained from the server
certificate, and sends the result. Change cipher spec: The
peer selects the cipher(s) to use. Client finished: The peer also
calculates a master secret from the premaster secret, and sends a
hash of a message consisting of the master secret; all of the data
from all previous handshake messages; the string "client
Andersson, Josefsson Expires: February 2002 [Page 4]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
finished".
7. Change cipher spec: The authenticator selects the cipher(s) to
use. Server finished: Finally, the authenticator itself
generates the master secret from the premaster secret and
responds with a hash of a message consisting of the master
secret; all of the data from all previous handshake messages;
the string "server finished".
8. The peer acknowledges the end of the TLS negotiation by sending
an empty EAP Response packet.
This concludes the TLS handshake phase and the authentication of the
authenticator. It remains to perform user authentication. Note that
it is not until now that we deviate from the TLS EAP specification.
The authenticator will now intiate a second EAP handshake, within
TLS, to provide peer authentication in a protected channel. In this
EAP handshake, any EAP mechanism may be used to provide the peer
authentication.
This concludes the mutual authentication, and upon success both
authenticator and peer may generate any amount of new key material to
be forwarded to the underlying transport. This is accomplished within
the TLS Record Protocol by using the so-called PRF (Pseudo-Random
Function), see Section 3.5 "Key Derivation" of [3].
It remains to be described what happens upon failures. In case the
TLS negotiation has failed fatally (after the proper TLS Alert
messages have been sent), an EAP-Failure messages is transmitted.
Within the TLS channel, in the second EAP handshake, after any EAP-
Success and EAP-Failure messages has successfully been sent, the same
type of packet should be send in the outer EAP channel as well.
3.2. Roaming
We now describe the case where the peer is transiting between two
authenticators during a session. In order to obtain a seamless
transition to a connection between the peer and the new
authenticator, we use the connection re-establishment mechanism
provided by the TLS Handshake Protocol. Note that the new
authenticator is assumed to use the same back-end server as the old
one, hence the old security parameters are still available. In the
case where the back-end server is just a logical entity residing at
the authenticator, the second authenticator will be required to
(securely) transfer the security parameters from the first
authenticator.
The steps 1-3 above are repeated without change. The following
Andersson, Josefsson Expires: February 2002 [Page 5]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
describes a successful TLS handshake:
4. Client hello: The peer sends the TLS protocol version number, the
Session ID of the old connection, the previously negotiated
cryptographic algorithms, and a random number.
5. Server hello: The authenticator responds with the TLS protocol
version number, the Session ID, the negotiated cryptographic
algorithms, and another random number. If the old Session ID has
expired, then a new Session ID is presented to the peer and full
authentication takes place, as described in Subsection 3.1.
Change cipher spec: the server selects the cipher(s) to
use. Server finished: The authenticator responds with a hash of
a message consisting of the master secret; data from all
previous handshake messages; the string "server finished".
6. Change cipher spec: The peer select cipher(s) to use. Client
finished: The peer sends a hash of a message consisting of
the previously calculated master secret; data from all previous
handshake messages; the string "client finished".
Note that mutual authentication is achieved, since both peer and
authenticator have to know the old master secret in order to
successfully complete the protocol. An alternative to TLS resumption
has been discussed, whereby a "Roaming ID" is used to identify the
user moving between authenticators. At a new connection, server
authentication and generation of new security parameters is
mandatory. The advantage of this approach is that the authentication
server does not have to store so much key material, since all data
except the Roaming ID may be deleted when entities are disconnected.
This can be an important issue if there are many peers to be served.
On the other hand, having to generate much new key material could be
very time consuming for the back-end server, and this potential
danger has led us to choose TLS resumption as described above.
Finally, the length of time that a Session ID is valid should be
limited. The time of validity is application dependent. In some
environments it may be desirable that the authenticator notify the
peer that the Session ID is about to expire. No mechanism is defined
in this document to handle such a scenario, but note that the Session
ID validity is checked during connection re-establishment (see 5
above).
4. Packet formats
It is assumed that underlying transport protocols has set up the
connection so that it is ready to transfer EAP packets.
Andersson, Josefsson Expires: February 2002 [Page 6]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
4.1. TLS in EAP
The syntax of EAP packets containing TLS messages are per [1], and
the TLS protocol description is per [3]. Note that [1] does not use
the negotiated TLS tunnel to transfer any data, while this
specification does, however this does not affect the EAP protocol
syntax. We include the EAP syntax in the following figure, referring
to Sections 4.2 and 4.3 of [1] for the definition of the Request and
Response packets.
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 | Data ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
2 - Response
Identifier
The identifier field is one octet and aids in matching responses
with requests.
Length
The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, and Data
fields. Octets outside the range of the Length field should be
treated as Data Link Layer padding and should be ignored on
reception.
Type
TBA - EAP TLS EAP
Data
The format of the Data field is determined by the Code field.
4.2. EAP negotiation inside TLS
We now assume that the TLS handshake has been successfully completed
and that a secure TLS connection is available within the TLS Record
Andersson, Josefsson Expires: February 2002 [Page 7]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
Protocol. The following packets (protected by TLS Record Protocol and
sent inside EAP packets) are used to negotiate the peer EAP
authentication.
The following figure describes the template packet structure that is
used during this communication.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Data as per RFC 2284 ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The party acting as authenticator in this second, wrapped, EAP
channel MUST be the same party that acted as authenticator in the
original EAP channel.
5. Example: IEEE 802.11 WLAN
IEEE 802.11 Wireless Local Area Network (WLAN) is a standard for
wireless computer networks, see [5]. Any device that contains an IEEE
802.11 conformant medium access control and physical layer interface
to the wireless medium is called a Station (STA). An entity that has
station functionality and also provides access to the distribution
services (e.g. a wired LAN) via the wireless medium for associated
stations is called an Access Point (AP). The authentication services
defined within IEEE 802.11 are discussed below, and the need for
higher level authentication is addressed.
IEEE 802.11 defines two types of authentication methods -- Open
system authentication and Shared key authentication. Open system
authentication is essentially a null authentication. The conversation
is done in clear, no challenge procedure is performed. The purpose of
Shared key authentication is to check that both parties share a pre-
negotiated encryption key. The AP sends a challenge and the STA
responds by encrypting this challenge. If the AP successfully
decrypts that message, the authentication is finished. In other
words, the AP is never required to authenticate itself. This opens up
for a number of attacks, such as denial of service attacks via rogue
APs. It is thus crucial to achieve mutual authentication.
The IEEE 802.1X draft [4] specifies a general method for the
provision of port based network access control. A port in this
context is an attachment point to the LAN infrastructure, e.g. an
association between a STA and an AP. The specification describes the
architectural framework within which the authentication takes place,
and establishes the requirements for a higher level authentication
Andersson, Josefsson Expires: February 2002 [Page 8]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
protocol between the station and the access point.
The IEEE 802.1X draft provides a framework, Extensible Authentication
Protocol Over Local area networks (EAPOL), that makes it possible to
send EAP packets between IEEE 802.11 entities. In a WLAN environment,
the "Authenticator" is the AP, and the "Peer" is a STA. An
Authentication Server is an entity connected with the AP. The server
is communicating with the STA during the authentication -- the AP is
sitting in between, acting merely as a passthrough device. In a
roaming environment, the STA may connect to several APs during a
session. All the APs are assumed to be connected to the same
authentication server. The protocol described in this paper may
therefore be applied to a WLAN environment, providing authentication
of the AP, strong authentication of the user of the STA, and session
key negotiation.
Note that the present protocol is partly based on [1], which in turn
assumes PPP EAP and not EAPOL as the underlying protocol. However,
this minor difference will cause no problems whatsoever, since the
TLS conversation carries over word by word to the new environment.
Let us finally comment on the Wired Equivalent Privacy (WEP)
encryption scheme defined in the IEEE 802.11 standard. WEP uses the
stream cipher RC4 with key obtained as the concatenation of a 24 bit
IV and a 40 bit WEP key. Four WEP keys can be prestored, but it is
also possible to use a session key negotiated during the
authentication phase, i.e. follow the approach outlined in this work.
WEP suffers from some serious security weaknesses, e.g. the WEP key
is too short to withstand a brute force attack. Also, the IV is too
short -- even if a new random IV is used for each packet, collisions
will start appearing within a few seconds (according to the birthday
paradox). XORing messages with the same IV results in plaintext
difference that can be further analyzed. Finally, there is no real
data integrity since the integrity check value used is just a linear
checksum. An active attacker wishing to alter the plaintext can
easily modify the checksum to be valid for the new plaintext. The
IEEE 802.11 working group recognizes the need to improve security,
and is currently working on a revision of the standard.
6. Security considerations
The Transport Layer Security protocol is presumed to be a strong
security protocol and it is widely accepted. Here we discuss some
security issues. The Session ID is sent in clear, so an attacker may
contact an authenticator, pretending to be the legitimate user.
However, by sending correct Finished messages, the parties prove to
each other that they know the correct premaster secret. The attacker
will not be able to finish the handshake properly (unless the
Andersson, Josefsson Expires: February 2002 [Page 9]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
protocol has been completely broken).
An attacker, acting as an active man-in-the-middle, might try to
influence the choice of encryption algorithm by altering the
corresponding handshake message. However, this will also be detected
in the verification of the Finished messages, since each of these
consists of a hash of all previous messages. The hash functions MD5
and SHA-1 are used in tandem wherever possible. The TLS designers
claim that this approach ensures that a serious flaw in one of the
functions will not lead to failure of the entire TLS protocol.
Finally, the strength of the user authentication is dependent on the
EAP mechanism chosen. With the approach described here, the EAP
packets sent by the peer are not transmitted in clear, which improve
the security of some EAP mechanisms. This is particularly important
in a wireless environment where passive eavesdropping is a serious
threat.
7. Acknowledgements
We wish to thank Jan-Ove Larsson and Magnus Nystrom for helpful
discussions and comments during the development of this draft. We
would also like to thank Glen Zorn and Simon Blake-Wilson for
comments on the first version of this draft.
References
[1] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[2] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[3] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, January
1999.
[4] IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Draft 802.1X/D10, January
2001.
[5] Information technology -- Telecommunications and information
exchange between systems -- Local and metropolitan area
networks -- Specific requirements -- Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, IEEE Std. 802.11, 1999.
Address of the authors
Andersson, Josefsson Expires: February 2002 [Page 10]
INTERNET-DRAFT Protecting EAP with TLS (EAP-TLS-EAP) August 2001
Hakan Andersson
RSA Security
Box 107 04
SE-121 29 Stockholm
Sweden
E-mail: handersson@rsasecurity.com
Phone: +46 8 725 9758
Fax: +46 8 649 4970
Simon Josefsson
RSA Security
Box 107 04
SE-121 29 Stockholm
Sweden
E-mail: sjosefsson@rsasecurity.com
Phone: +46 8 725 0914
Fax: +46 8 649 4970
Andersson, Josefsson Expires: February 2002 [Page 11]