EAP F. Bersani
Internet-Draft France Telecom R&D
Expires: November 30, 2004 June 2004
The EAP-PSK Protocol: a Pre-Shared Key EAP Method
draft-bersani-eap-psk-03
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 November 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document specifies EAP-PSK, an Extensible Authentication
Protocol (EAP) method for mutual authentication and session key
derivation using a Pre-Shared Key (PSK).
In case the authentication is successful, EAP-PSK provides a
protected channel for both parties to communicate over. This
protected channel is currently used to exchange protected result
indications and may be used in the future to implement extensions.
EAP-PSK is designed to be easy to deploy and well-suited for
authentication over insecure networks such as IEEE 802.11.
It is proposed as a replacement for MD5-Challenge.
Bersani Expires November 30, 2004 [Page 1]
Internet-Draft EAP-PSK June 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Design goals for EAP-PSK . . . . . . . . . . . . . . . . . 4
1.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Wide Applicability . . . . . . . . . . . . . . . . . . 4
1.1.3 Security . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.4 Extensibility . . . . . . . . . . . . . . . . . . . . 5
1.2 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Security Level to Be Confirmed . . . . . . . . . . . . 5
1.2.2 Confusion with Other PSK Protocols . . . . . . . . . . 5
1.2.3 Insecure Generation of the PSK . . . . . . . . . . . . 6
1.2.4 Reuse of the PSK . . . . . . . . . . . . . . . . . . . 6
1.2.5 Choice of the PSK Repository . . . . . . . . . . . . . 6
1.2.6 Network Quality of EAP-PSK to Be Evaluated . . . . . . 6
1.3 Specification of Requirements . . . . . . . . . . . . . . 6
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . 9
2. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 12
2.1 EAP-PSK key hierarchy . . . . . . . . . . . . . . . . . . 12
2.1.1 The PSK . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 The TEK . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 The MSK . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.4 The EMSK . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.5 The IV . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Cryptographic design of EAP-PSK . . . . . . . . . . . . . 13
2.2.1 The Key Setup . . . . . . . . . . . . . . . . . . . . 14
2.2.2 The Authenticated Key Exchange . . . . . . . . . . . . 15
2.2.3 The Protected Channel . . . . . . . . . . . . . . . . 19
2.3 EAP-PSK Message Flows . . . . . . . . . . . . . . . . . . 21
2.3.1 EAP-PSK Standard Authentication . . . . . . . . . . . 22
2.3.2 EAP-PSK Extended Authentication . . . . . . . . . . . 23
3. EAP-PSK Message format . . . . . . . . . . . . . . . . . . . . 25
3.1 EAP-PSK First Message . . . . . . . . . . . . . . . . . . 25
3.2 EAP-PSK Second Message . . . . . . . . . . . . . . . . . . 25
3.3 EAP-PSK Third Message . . . . . . . . . . . . . . . . . . 26
3.4 EAP-PSK Fourth Message . . . . . . . . . . . . . . . . . . 29
4. Rules of Operation for the EAP-PSK Protected Channel . . . . . 33
4.1 Protected Result Indications . . . . . . . . . . . . . . . 33
4.1.1 CONT . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.2 DONE_SUCCESS . . . . . . . . . . . . . . . . . . . . . 34
4.1.3 DONE_FAILURE . . . . . . . . . . . . . . . . . . . . . 34
4.2 Extended Authentication . . . . . . . . . . . . . . . . . 35
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 37
5.1 Allocation of an EAP-Request/Response Type for EAP-PSK . . 37
5.2 Allocation of EXT Type numbers . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
Bersani Expires November 30, 2004 [Page 2]
Internet-Draft EAP-PSK June 2004
6.1 Mutual Authentications . . . . . . . . . . . . . . . . . . 39
6.2 Protected Result Indications . . . . . . . . . . . . . . . 39
6.3 Integrity Protection . . . . . . . . . . . . . . . . . . . 40
6.4 Replay Protection . . . . . . . . . . . . . . . . . . . . 40
6.5 Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 40
6.6 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 41
6.7 Denial of Service Resistance . . . . . . . . . . . . . . . 42
6.8 Session Independance . . . . . . . . . . . . . . . . . . . 43
6.9 Exposition of the PSK . . . . . . . . . . . . . . . . . . 43
6.10 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 43
6.11 Channel Binding . . . . . . . . . . . . . . . . . . . . . 44
6.12 Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 44
6.13 Identity Protection . . . . . . . . . . . . . . . . . . . 44
6.14 Protected Ciphersuite Negotiation . . . . . . . . . . . . 46
6.15 Confidentiality . . . . . . . . . . . . . . . . . . . . . 46
6.16 Cryptographic Binding . . . . . . . . . . . . . . . . . . 46
6.17 Implementation of EAP-PSK . . . . . . . . . . . . . . . . 46
7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 47
8. Intellectual Property Rights Notice . . . . . . . . . . . . . 48
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 50
10.2 Informative References . . . . . . . . . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 54
A. Generation of the PSK from a password - Discouraged . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . 56
Bersani Expires November 30, 2004 [Page 3]
Internet-Draft EAP-PSK June 2004
1. Introduction
1.1 Design goals for EAP-PSK
The Extensible Authentication Protocol (EAP) [2] provides an
authentication framework which supports multiple authentication
methods.
This document specifies an EAP method called EAP-PSK that uses a
Pre-Shared Key (PSK).
Design goals for this method were:
o Simplicity: EAP-PSK should be easy to implement and deploy without
any pre-existing infrastructure. It should be available quickly
as new protocols, such as IEEE 802.11i [28], that employ EAP in a
different threat model than PPP [46], have just been released.
o Wide applicability: EAP-PSK should be suitable to authenticate
over any network, and in particular over IEEE 802.11 [29] wireless
LANs.
o Security: EAP-PSK should be conservative in its cryptographic
design and enjoy security proofs.
o Extensibility: EAP-PSK should be easily extensible.
o Patent-avoidance: EAP-PSK should be free of any Intellectual
Property Rights claims.
1.1.1 Simplicity
For the sake of simplicity, EAP-PSK has chosen to rely on a single
cryptographic primitive, AES-128 [9].
Restricting to such a primitive (and in particular, not using
asymmetric cryptography like Diffie-Hellman key exchange) should make
EAP-PSK light-weight and well suited for any type of device,
especially those with little processing power and memory.
However, as further discussed in Section 6, this prevents EAP-PSK
from offering advanced features such as identity protection, password
support or Perfect Forward Secrecy (PFS). This choice has been
deliberately made as a trade-off between simplicity and security.
EAP-PSK has also chosen a fixed message format to meet the simplicity
design goal.
1.1.2 Wide Applicability
EAP-PSK has been designed in a threat model where the attacker has
full control over the communication channel. This is the threat
model of EAP that is presented in Section 7.1 of [2].
Bersani Expires November 30, 2004 [Page 4]
Internet-Draft EAP-PSK June 2004
1.1.3 Security
Since the design of authenticated key exchange is notoriously known
to be hard and error prone, EAP-PSK does not invent any new
mechanism. It builds instead on existing primitives and protocols
that have been reviewed by the cryptographic community, some of which
enjoy proofs of security in the cryptographic provable security
paradigm.
1.1.4 Extensibility
EAP-PSK explicitly provides a mechanism to allow for future
extensions within its protected channel (see Section 2.2.3). As
EAP-PSK currently only provides authenticated key exchange, this
mechanism guarantees that EAP-PSK will be able to provide more
sophisticated services, as the need to do so appears.
1.2 Caveats
The reader is strongly advised to keep the following points in mind
while reading this document:
o Security to be confirmed: the level of security provided by
EAP-PSK is still to be assessed.
o Confusion with other PSK protocols: EAP-PSK should not be confused
with other protocols that also have the word "PSK" in their name.
o Insecure generation of the PSK: the PSK used by EAP-PSK MUST be
chosen at random among the set of possible keys.
o Reuse of the PSK: the PSK used by EAP-PSK MUST be
cryptographically separated from keys used by other protocols.
o Choice of the PSK repository for the PSK: EAP-PSK does not mandate
in any way how the PSK is to be stored.
o Network quality of EAP-PSK to be evaluated: the quality of EAP-PSK
as a network protocol is still to be evaluated.
1.2.1 Security Level to Be Confirmed
As explained in Section 1.1.3, the design of authenticated key
exchange protocols is error prone. Great care should thus be taken
regarding EAP-PSK. It is still work in progress and has to be
further reviewed by cryptographic experts before it can be trusted.
1.2.2 Confusion with Other PSK Protocols
Since PSKs are of frequent use in security protocols, attention
should be paid not to confuse EAP-PSK with other protocols that also
refer to a PSK, for instance, Wi-Fi Protected Access (WPA) [51] when
used in its PSK mode.
Bersani Expires November 30, 2004 [Page 5]
Internet-Draft EAP-PSK June 2004
1.2.3 Insecure Generation of the PSK
Although, the generation of the PSK that EAP-PSK uses is outside of
the scope of this document, it is reminded that this PSK MUST be
generated by a good source of randomness (see [20]). In particular,
this PSK MUST NOT be confused with a password (see Section 6.5 for
further discussion).
1.2.4 Reuse of the PSK
It is a rule of the thumb in cryptography to use different keys for
different applications. Hence, the PSK used by EAP-PSK MUST be
cryptographically separated from keys used by any other protocol.
Otherwise the security of EAP-PSK may be compromised.
1.2.5 Choice of the PSK Repository
The specification of a repository for the PSK that EAP-PSK uses is
outside of the scope of this document. In particular, nothing
prevents from storing this PSK on a tamper-resistant device such as a
smart card rather than having it memorized or written down on a sheet
of paper. The choice of the PSK repository may have important
security impacts (see Section 6.9 for further discussion).
1.2.6 Network Quality of EAP-PSK to Be Evaluated
Last, the overall quality of EAP-PSK as a network protocol is still
to be evaluated, e.g., its efficiency and its functional soundness.
1.3 Specification of Requirements
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 [5].
1.4 Terminology
Authentication, Authorization and Accounting (AAA) Please refer to
[11] for more details.
AES-128 A block cipher specified in the Advanced Encryption
Standard, please refer to [9] for more details.
Authentication Key (AK) A 16-byte key derived from the PSK that the
EAP peer and server use to mutually authenticate.
AKEP2 An authenticated key exchange protocol, please refer to [3]
for more details.
Bersani Expires November 30, 2004 [Page 6]
Internet-Draft EAP-PSK June 2004
Backend Authentication Server A Backend Authentication Server is an
entity that provides an authentication service to an
Authenticator. When used, this server typically executes
EAP Methods for the Authenticator (This terminology is also
used in [27], and has the same meaning in this document).
Extensible Authentication Protocol (EAP) Please refer to [2] for more
details.
EAP Authenticator (or simply Authenticator) The end of the EAP link
initiating the EAP authentication methods. (This
terminology is also used in [27], and has the same meaning
in this document).
EAP peer (or simply peer) The end of the EAP link that responds to
the Authenticator. (In [27], this end is known as the
Supplicant).
EAP server (or simply server) The entity that terminates the EAP
authentication with the peer. In the case where there is
no Backend Authentication Server, this term refers to the
EAP Authenticator. Where the EAP Authenticator operates in
pass-through, it refers to the Backend Authentication
Server.
EAX An authenticated-encryption with associated data mode of
operation for block ciphers, please refer to [4] for more
details.
Extended Master Session Key (EMSK) Additional keying material derived
between the EAP peer and server that is exported by the EAP
method. The EMSK is at least 64 bytes in length. The EMSK
is reserved for future uses that are not defined yet and is
not provided to a third party. Please refer to [10] for
more details. EAP-PSK generate as 64-byte EMSK.
Initialization Vector (IV) A quantity of at least 64 bytes, suitable
for use in an initialization vector field, that is derived
between the peer and EAP server. Since the IV is a known
value in methods such as EAP-TLS [12] , it cannot be used
by itself for computation of any quantity that needs to
remain secret. As a result, its use has been deprecated
and EAP methods are not required to generate it. However,
when it is generated it MUST be unpredictable. Please
refer to [10] for more details. EAP-PSK does not generate
an IV.
Key-Derivation Key (KDK) A 16-byte key derived from the PSK that the
EAP peer and server use to derive session keys (namely, the
TEK, MSK and EMSK).
Message Authentication Code (MAC) Informally, the purpose of a MAC
is to provide assurances regarding both the source of a
message and its integrity. Please refer to [40] for more
details. IEEE 80211i uses the acronym MIC (Message
Integrity Check) to avoid confusion with the other meaning
of the acronym MAC (Medium Access Control).
Bersani Expires November 30, 2004 [Page 7]
Internet-Draft EAP-PSK June 2004
Master Session Key (MSK) Keying material that is derived between the
EAP peer and server and exported by the EAP method. The
MSK is at least 64 bytes in length. In existing
implementations a AAA server acting as an EAP server
transports the MSK to the Authenticator. Please refer to
[10] for more details.
Network Access Identifier (NAI) The NAI is used to identify the
parties that are communicating. Please refer to [1] for
more details.
One Key CBC-MAC 1 (OMAC1) A method to generate a Message
Authentication Code. OMAC1 is the variant of the OMAC
message authentication code family that is used by EAP-PSK.
Please refer to [7] for more details.
Perfect Forward Secrecy (PFS) The confidence that the compromise of a
long-term private key does not compromise any earlier
session keys. In other words, once an EAP dialog is
finished and its corresponding keys are forgotten, even
someone who has recorded all of the data from the
connection and gets access to all of the long-term keys of
the peer and the server cannot reconstruct the keys used to
protect the conversation without doing a brute force search
of the session key space. EAP-PSK does not have this
property.
Pre-Shared Key (PSK) A Pre-Shared Key simply means a key in symmetric
cryptography. This key is derived by some prior mechanism
and shared between the parties before the protocol using it
takes place. It is merely a bit sequence of given length
of which each bit has been chosen at random uniformly and
independently. For EAP-PSK, the PSK is the long term
16-byte credential shared by the EAP peer and server.
Protected Result Indication Please refer to Section 7.16 of [2] for a
definition of this term. This feature has been introduced
because EAP-Success/Failure packets are unidirectional and
are not protected.
Pseudo-random function (PRF) Informally, a family of functions is
pseudo-random if there is no efficient procedure to
distinguish between a member of this family chosen at
random and a function with the same domain and range chosen
at random. By improper though common extension, a member
of a family of pseudo-random functions is itself called a
pseudo-random function. Please refer, for instance, to
[4], for a precise cryptographic definition of this term.
PRP (Pseudo-random permutation) Informally a family of permutations
is pseudo-random if there is no efficient procedure to
distinguish between a member of this family chosen at
random and a permutation with the same domain chosen at
random. By improper though common extension, a member of a
family of pseudo-random permutations is itself called a
Bersani Expires November 30, 2004 [Page 8]
Internet-Draft EAP-PSK June 2004
pseudo-random permutation. Please refer, for instance, to
[4], for a precise cryptographic definition of this term.
Transient EAP Key (TEK) A session key which is used to establish a
protected channel between the EAP peer and server during
the EAP authentication exchange. The TEK is appropriate
for use with the ciphersuite negotiated between the EAP
peer and server to protect the EAP conversation. Note that
the ciphersuite used to set up the protected channel
between the EAP peer and server during EAP authentication
is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and Authenticator.
Please refer to [10] for more details. EAP-PSK uses a
16-byte TEK for its protected channel.
1.5 Conventions
All numbers involved in cryptographic calculations are considered in
network-byte order.
|| denotes concatenation of strings (and not the logical OR).
MAC(K, String) denotes the MAC of String under the key K (the
algorithm used in this document to compute the MACs is OMAC1 with
AES-128, see Section 2.2.2).
[String] denotes the concatenation of String with the MAC of String
calculated as specified by the context. Hence,
[String]=String||MAC(K,String) where K is specified by the context.
** denotes integer exponentiation.
"i" denotes the unsigned binary representation on 16 bytes of the
integer i in network byte order. Therefore this notation only makes
sense when i is between 0 and 2**128-1.
<i> denotes the unsigned binary representation on 4 bytes of the
integer i in network byte order. Therefore this notation only makes
sense when i is between 0 and 2**32-1.
1.6 Related Work
At the time this document is written, only three EAP methods are
standards track EAP methods per IETF terminology (see [17]), namely:
o MD5-Challenge (EAP-Request/Response type 4), defined in [2], which
uses a MD5 challenge similar to [47].
o OTP (EAP-Request/Response type 5), defined in [2], which aims at
providing One-Time Password support similar to [22] and [41].
Bersani Expires November 30, 2004 [Page 9]
Internet-Draft EAP-PSK June 2004
o GTC (EAP-Request/Response type 6), defined in [2], which aims at
providing Generic Token Card Support.
Unfortunately, all three methods are deprecated for security reasons
that are explained in part in [2].
Myriads of EAP methods have however been otherwise proposed:
o One as informational RFCs (EAP-TLS [12]) - which therefore is not
a standard (see [26] and [17])
o Some as individual Internet-Drafts submissions (e.g., [44] or this
document).
o And some even undocumented (e.g. Rob EAP which has EAP-Request/
Response type 31).
However, no secure and mature Pre-Shared Key EAP method is available,
which is all the more regrettable that Pre-Shared Key methods are the
most basic ones!
The existing proposals for a future Pre-Shared Key EAP method are
briefly reviewed hereafter (please refer to [16] for a more thorough
synthesis on EAP methods).
Among these proposals, there are some which:
o Are broken from a security point of view, e.g.:
* LEAP which is specified in [39] and which vulnerabilities are
discussed in [52].
* EAP-MSCHAPv2 which is specified in [34] and which
vulnerabilities are indirectly discussed in [45].
o Essentially require additional infrastructure, e.g., EAP-SIM [25],
EAP-AKA [13] or OTP/token card methods like [31].
o Are not shared key methods but often confused with them, namely
the password methods, e.g., EAP-SRP [18] or SPEKE [30] - which
very unfortunately seem to have serious Intellectual Property
Rights concerns.
o Are generic tunneling methods that require a public-key
certificate for the server and allow the peer to authenticate with
another EAP method or even other authentication mechanisms, namely
[32] and [21].
o Are abandoned but have provided the basis for EAP-PSK, namely,
EAP-Archie [50].
o Are possible alternatives to EAP-PSK (i.e., claimed to be secure
and subject of active work):
* EAP-FAST [44].
* EAP-IKEv2 [49].
* EAP-TLS (when shared key/password support is added to TLS, see
[53]).
EAP-PSK is proposed as a replacement for MD5-Challenge:
Bersani Expires November 30, 2004 [Page 10]
Internet-Draft EAP-PSK June 2004
o Its development process has been
<http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAP-PSK_Issues.htm>
.
o It tried to borrow all the best features of the other proposals
and merge them into a single method.
o It restricted to simply proposing a Pre-Shared Key method and,
unlike EAP-IKEv2 or EAP-TLS, it does not allow a variety of
alternative credentials, like for instance, public-key
certificates.
Bersani Expires November 30, 2004 [Page 11]
Internet-Draft EAP-PSK June 2004
2. Protocol overview
2.1 EAP-PSK key hierarchy
This section instantiates for EAP-PSK the EAP Key hierarchy described
in [10].
2.1.1 The PSK
EAP-PSK uses a 16-byte Pre-Shared Key called the PSK as its long term
credential.
This PSK is shared between the EAP peer and the EAP server.
EAP-PSK assumes that the PSK is known only to the EAP peer and EAP
server. The security properties of the protocol may be compromised
if it has wider distribution.
The protocol also assumes the EAP server and EAP peer identify the
correct PSK to use with each other by their respective NAIs.
This PSK is used to derive two 16-byte subkeys, respectively called
the Authentication Key (AK) and the Key-Derivation Key (KDK). This
derivation need only be done once: it is called the key setup, see
Section 2.2.1.
+---------------------------+
| PSK |
| (16 bytes) |
+---------------------------+
| |
v v
+---------------------------+ +---------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+---------------------------+ +---------------------------+
2.1.1.1 AK
EAP-PSK uses AK to mutually authenticate the EAP peer and the EAP
server.
2.1.1.2 KDK
EAP-PSK uses KDK to derive session keys shared by the EAP peer and
the EAP server (namely, the TEK, MSK and EMSK).
Bersani Expires November 30, 2004 [Page 12]
Internet-Draft EAP-PSK June 2004
2.1.2 The TEK
EAP-PSK derives a 16-byte TEK thanks to a random number exchanged
during authentication and KDK.
This TEK is used to implement a protected channel for both mutually
authenticated parties to communicate over securely.
2.1.3 The MSK
EAP-PSK derives a MSK thanks to a random number exchanged during
authentication and the KDK.
As specified in [10], the MSK is 64 bytes long.
2.1.4 The EMSK
EAP-PSK allows for EMSK derivation thanks to a random number
exchanged during authentication and the KDK.
As specified in [10], the EMSK is 64 bytes long.
2.1.5 The IV
EAP-PSK does not derive any IV.
2.2 Cryptographic design of EAP-PSK
EAP-PSK relies on a single cryptographic primitive, a block cipher,
which is instantiated with AES-128. AES-128 takes as inputs a
16-byte Pre-Shared Key and a 16-byte Plain Text block. It outputs a
16-byte Cipher Text block. For a detailed description of AES-128,
please refer to [9].
AES-128 has been chosen because:
o It is standardized and implementations are widely available.
o It has been carefully reviewed by the community and is believed to
be secure.
Other block ciphers could easily be proposed for EAP-PSK, as it does
not intricately depend on AES-128. The only parameters of AES-128
that EAP-PSK depends on, are its block size (16 bytes) and its key
size (16 bytes). For the sake of simplicity, it has however been
chosen to restrict to a single mandatory block cipher and not allow
the negotiation of other block ciphers. In case AES-128 is
deprecated for security reasons, EAP-PSK should also be deprecated
and a cut-and-paste EAP-PSK' should be defined with another block
cipher. This EAP-PSK' should not be backward compatible with EAP-PSK
Bersani Expires November 30, 2004 [Page 13]
Internet-Draft EAP-PSK June 2004
because of the security issues with AES-128. EAP-PSK' should
therefore use a different EAP-Request/Response Type number.
EAP-PSK uses three cryptographic parts:
o A key setup to derive AK and KDK from the PSK.
o An authenticated key exchange protocol to mutually authenticate
the communicating parties.
o A protected channel protocol for both mutually authenticated
parties to communicate over.
2.2.1 The Key Setup
EAP-PSK needs two cryptographically separated 16-byte subkeys for
authenticated key exchange and session key derivation. Indeed, it is
a rule of the thumb in cryptography to use different keys for
different applications.
It could have implemented these two subkeys either by specifying a
32-byte PSK that would then be splitted in two 16-byte subkeys, or by
specifying a 16-byte PSK that would then be cryptographically
expanded to two 16-byte subkeys.
Because provisioning a 32-byte long terme credential is more
cumbersome than a 16-byte one, and the strength of the derived
session keys is 16 bytes either ways, the latter option was chosen.
Hence, the PSK is only used by EAP-PSK to derive AK and KDK. It is
RECOMMENDED that this derivation be done only once, immediately after
the PSK has been provisioned. As soon as AK and KDK have been
derived, the PSK MAY be deleted.
Derivation of AK and KDK from the PSK is called the key setup:
o The input to the key setup is the PSK.
o The outputs of the key setup are AK and KDK.
AK and KDK are derived from the PSK using the modified counter mode
of AES-128. The modified counter mode is a length increasing
function, i.e., it expands one AES-128 input block into a longer
t-block output, where t>=2. This mode was chosen for the key setup
because it had already been chosen for the derivation of the session
keys (see Section 2.2.2).
+--------------------------+
| "0" |
| Input Block (16 bytes) |
+--------------------------+
|
v
Bersani Expires November 30, 2004 [Page 14]
Internet-Draft EAP-PSK June 2004
+----------------+
| |
| AES-128(PSK,.) |
| |
+----------------+
|
|
+----------------------------+
| |
v v
+--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ |
| |
+----------------+ +----------------+
| | | |
| AES-128(PSK,.) | | AES-128(PSK,.) |
| | | |
+----------------+ +----------------+
| |
| |
v v
+------------------------+ +------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+------------------------+ +------------------------+
Figure 2: Derivation of AK and KDK from the PSK in Details
The input block is "0". For the sake of simplicity, this input block
has been chosen constant: it could have been set to a value depending
on the peer and the server (for instance, the XOR of their respective
NAIs approprailtely truncated or zero-padded), but this did not seem
to add any security to the scheme. Any 16-byte constant could have
been chosen, as the security is not supposed to depend on the
particular value taken by the constant. "0" was arbitrarily chosen.
2.2.2 The Authenticated Key Exchange
The authentication protocol used by EAP-PSK is inspired of AKEP2
which is described in [3].
AKEP2 consists of a one and half round trip exchange.
Bersani Expires November 30, 2004 [Page 15]
Internet-Draft EAP-PSK June 2004
Bob Alice
| A||RA |
|<---------------------------------------------------------|
| |
| [B||A||RA||RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
Figure 3: Overview of AKEP2
In AKEP2,
o RA and RB are random numbers chosen respectively by Alice and Bob.
o A and B are Alice's and Bob's respective identities.
o The MACs (please see Section 1.5 for the notation "[]") are
calculated using a dedicated key.
EAP-PSK instantiates this protocol with:
o The server as Alice and the peer as Bob.
o RA and RB as 16-byte random numbers.
o A and B as Alice's and Bob's respective NAIs.
o The MAC algorithm as OMAC1 with AES-128 using AK and producing a
tag length of 16 bytes.
o The modified counter mode of operation of AES-128 using KDK, to
derive session keys as a result of this exchange.
Actually, EAP-PSK makes some slight modifications to AKEP2, which are
however believed to be compatible with its security:
o EAP-PSK assumes that the peer knows the identity of the server it
is authenticating to. Thus, the server neither sends its identity
A to the peer in the first message of AKEP2, nor in the third.
The peer may indeed believe that its EAP dialog has been
established with the right server because:
* Either the peer is only supposed to communicate with one
server, i.e., every Authenticator the peer talks to is supposed
to be connected to the same Backend Authentication Server (from
a logical point of view, there could be several such physical
servers but they would be logical clones for EAP-PSK). This
scenario typically occurs when the peer is an employee
connecting to its corporate wireless access.
* Or the AAA infrastructure has routed the EAP dialog of the peer
to the right server thanks to the Identity it chose to provide
in EAP-Response/Identity.
o EAP-PSK assumes that both communicating parties remember the
information they have provided to the other party and the
information that the other party provided (remembering information
warrants some caution to avoid Denial of Service attacks, see
Bersani Expires November 30, 2004 [Page 16]
Internet-Draft EAP-PSK June 2004
Section 6.7 for further discussion). Namely:
* The server remembers which random number RA it has sent to the
peer in the first message of AKEP2. Hence, there is no need
for the peer to resend this number to the server within the
second message of EAP-PSK.
* Similarly, the server remembers which random number RB it has
received in the second message and therefore does not resend it
in the third message of EAP-PSK.
Thus, the mutual authentication within EAP-PSK consists in the
following exchange.
Peer Server
| RA |
|<---------------------------------------------------------|
| |
| B||RB||MAC(AK, B||A||RA||RB) |
|--------------------------------------------------------->|
| |
| MAC(AK, A||RB) |
|<---------------------------------------------------------|
Figure 4: AKEP2 Instantiated by EAP-PSK
OMAC1 was chosen as the MAC algortihm because it is capable of
handling of arbitrary length messages, and its design is simple. It
also enjoys a security proof, which has not been found to be flawed
so far. For a detailed description of OMAC1, please refer to [7].
In AKEP2 the key exchange is "implicit": the session keys are derived
from RB using KDK. This cryptographic derivation is realized using
the modified counter mode described in [6].
This mode was chosen because it seems to a simple key derivation
schemes that relies on a block cipher and has a proof of its
security. It is a length increasing function, i.e., expands one
AES-128 input block into a longer t-block output, where t>=2.
Bersani Expires November 30, 2004 [Page 17]
Internet-Draft EAP-PSK June 2004
+--------------------------+ +-------------------------------+
| RB | | KDK |
| Input Block (16 bytes) | | Key Derivation Key (16 bytes) |
+--------------------------+ +-------------------------------+
| |
v v
+-----------------------------------------------------------------+
| |
| Modified Counter Mode |
| |
+-----------------------------------------------------------------+
| | |
v v v
+------------+ +----------------------+ +----------------------+
| TEK | | MSK | | EMSK |
| (16 bytes) | | (64 bytes) | | (64 bytes) |
+------------+ +----------------------+ +----------------------+
The input to the session keys derivation is RB.
The outputs of the session keys derivation are:
* The 16-byte TEK (the first output block).
* The 64-byte MSK (the concatenation of the second to fifth
output blocks).
* The 64-byte EMSK (the concatenation of the sixth to ninth
output blocks).
+--------------------------+
| RB |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| AES-128(KDK,.) |
| |
+----------------+
|
|
+---------------------+-- - - - - - - - - - --+
| | |
v v v
+--------+ +---+ +--------+ +---+ +--------+ +---+
| c1="1" |->|XOR| | c2="2" |->|XOR|.......| c9="9" |->|XOR|
|16 bytes| +---+ |16 bytes| +---+ |16 bytes| +---+
+--------+ | +--------+ | +--------+ |
| | |
+----------------+ +----------------+ +----------------+
Bersani Expires November 30, 2004 [Page 18]
Internet-Draft EAP-PSK June 2004
| | | | | |
| AES-128(KDK,.) | | AES-128(KDK,.) |......| AES-128(KDK,.) |
| | | | | |
+----------------+ +----------------+ +----------------+
| | |
| | |
v v v
+-----------------+ +-----------------+ +------------------+
| Output Block #1 | | Output Block #2 | | Output Block #9 |
| (16 bytes) | | (16 bytes) |.....| (16 bytes) |
| TEK | | MSK (block 1/4) | | EMSK (block 4/4) |
+-----------------+ +-----------------+ +------------------+
The counter values are set respectively to the first t integers (that
is ci="i", with i=1 to 9).
2.2.3 The Protected Channel
EAP-PSK provides a protected channel for both parties to communicate
over, in case of a successful authentication . This protected
channel is currently used to exchange protected result indications
and may be used in the future to implement extensions (such as
account reporting and provisioning).
EAP-PSK uses the EAX mode of operation to provide this protected
channel. For a detailed description of EAX, please refer to [4].
Bersani Expires November 30, 2004 [Page 19]
Internet-Draft EAP-PSK June 2004
+-----------+ +----------------+ +---------------------+ +----------+
| Nonce N | | Header H | | Plain Text Payload | | TEK |
| 4 bytes | | 5 bytes | | Variable length L | | 16 bytes |
+-----------+ +----------------+ +---------------------+ +----------+
| | | |
v v v v
+-------------------------------------------------------------------+
| |
| EAX |
| |
+-------------------------------------------------------------------+
| |
v v
+---------------------+ +----------+
| Plain Text Payload | | Tag |
| Variable length L | | 16 bytes |
+---------------------+ +----------+
This protected channel:
o Provides replay protection.
o Encrypts and authenticates a Plain Text Payload that is becomes an
Encrypted Payload.
o Only authenticates a Header that is thus sent in clear.
EAX is instantiated with AES-128 as the underlying block cipher keyed
with the TEK.
The nonce N is used to provide cryptographic security to the
encryption and to the MAC as well as to provide protection replay.
Indeed, N is a 4-byte sequence number starting from <0> that is
monotonically incremented at each EAP-PSK message within one EAP-PSK
dialog, except retransmissions of course.
N was taken to be 4 bytes to avoid 16-byte arithmetic. Since EAX
uses a 16-byte nonce, N is padded with 96 zero bits for its high
order bits.
For cryptographic reasons, N is not allowed to wrap up. In the
unlikely yet possible event of the server having sent an EAP-PSK
message with N set to <2**32-2>, it MUST NOT send any further message
on this protected channel, which would cause to reuse the value 0.
Either the conversation is finished after the server receives the
EAP-PSK answer from the peer with N set to <2**32-1> and the server
proceeds (typically by sending an EAP-Success or Failure), or the
conversation is not finished and MUST then be aborted (a new EAP-PSK
dialog MAY subsequently be started to try again to authenticate).
Thus, the maximum number of messages that can be exchanged over the
same protected channel is 2**32 (which should not be a limitation in
practice as this is approximately equal to 4 billions).
Bersani Expires November 30, 2004 [Page 20]
Internet-Draft EAP-PSK June 2004
The Header H consists in the first 5 bytes of the EAP Request or
Response packet (i.e. the EAP Code, Identifier, Length and Type
fields). Although it may appear unorthodox that an upper layer (EAP-
PSK) protects some information of the lower layer (EAP), this was
chosen to comply with EAP recommendation (see Section 7.5. of [2])
and seems to be existing practice at IETF (see, for instance, [36]).
The Plain Text Payload is the payload that is to be encrypted and
integrity protected.
The Tag is a MAC that protects both the Header and the Plain Text
Payload.
If the verification of the Tag succeeds, then the Encrypted Payload
is decrypted to recover the Plain Text Payload. If the verification
of the Tag fails, then no decryption is performed and this MAC
failure is reported.
The tag length is chosen to be 16 bytes for EAX within EAP-PSK. This
length is considered appropriate by the cryptographic community.
EAX was mainly chosen because:
o It strongly relies on OMAC in its design and OMAC1, a variant of
OMAC, had already been chosen in EAP-PSK for the authentication
part.
o Its design is simple.
o It enjoys a security proof.
o It is free of any Intellectual Property Rights claims.
It should however be understood that:
o There are currently many other proposed modes for authenticated
encryption with associated data - including Intellectual Property
Rights free ones, like CCM, CWC or GCM (please refer to the
<http://www.csrc.nist.gov/CryptoToolkit/modes/> for more details).
o And that the complexity and novelty of the proof of security of
EAX may be a concern.
2.3 EAP-PSK Message Flows
EAP-PSK may consist of two different types of message flows:
o The "standard authentication", which is:
* Mandatory to implement.
* Fully specified in this document.
* The simpler type of message flow that is expected to be used
frequently.
o The "extended authentication", which is:
* Optional to implement (i.e, there are no mandatory extensions).
* Partly specified in this document since it depends on
extensions and none are currently specified.
Bersani Expires November 30, 2004 [Page 21]
Internet-Draft EAP-PSK June 2004
* The type of message flow that should be used when extensions of
EAP-PSK are needed by more sophisticated usage scenarios and
when they are available.
2.3.1 EAP-PSK Standard Authentication
EAP-PSK standard authentication is comprised of four messages, i.e.,
two round trips.
peer server
| RAND_S |
|<---------------------------------------------------------|
| |
| RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| MAC_S||PCHANNEL_S_0 |
|<---------------------------------------------------------|
| |
| PCHANNEL_P_1 |
|--------------------------------------------------------->|
| |
o The first message is sent by the server to the peer and consists
in a 16-byte random challenge (RAND_S).
o The second message is sent by the peer to the server to:
* Send another 16-byte random challenge (RAND_P)
* State its identity (ID_P)
* Authenticate to the server by proving that it is able to
compute a particular MAC (MAC_P), which is a function of the
two challenges and AK:
MAC_P = OMAC1-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P) where
ID_S is the server's NAI.
o The third message is sent by the server to the peer to:
* Authenticate to the peer by proving that it is able to compute
another MAC (MAC_S), which is a function of the peer's
challenge and AK:
MAC_S = OMAC1-AES-128(AK, ID_S||RAND_P)
* Set up the protected channel (P_CHANNEL_S_0) to:
+ Confirm that it has derived session keys (at least the TEK).
+ Give a protected result indication of the authentication.
o The fourth message is sent by the peer to the server to finish the
setup of the protected channel (P_CHANNEL_P_1) to:
* Confirm that it has derived session keys (at least the TEK).
* Give a protected result indication of the authentication.
This standard message flow could be comprised of only three messages,
like AKEP2, were it not the request/response nature of EAP that
Bersani Expires November 30, 2004 [Page 22]
Internet-Draft EAP-PSK June 2004
prevents the third message to be the last one. Since the fourth
message is mandatory, EAP-PSK uses it to set up the protected channel
(actually it starts this setup in the third message).
The standard message flow also includes a statement by the peer of
its identity, in addition to the EAP-Response/Identity it may have
sent. This behavior follows Section 5.1 of [2] which recommends that
the EAP-Response/Identity be used primarily for routing purposes and
selecting which EAP method to use.
2.3.2 EAP-PSK Extended Authentication
To remain simple and yet be extensible to meet future requirements,
EAP-PSK provides an extension mechanism within its protected channel:
the payload of the protected channel may contain an optional
extension field (EXT).
Although support of the EXT field is mandatory, there is no mandatory
extension type to support. The mandatory support of the EXT field is
dictated:
o To guarantee a robust behavior in the future where some peers
might support some extensions and others not. All peers will thus
be able to understand that an extended authentication is being
attempted and indicate whether or not they support the extension
that is tried.
o To ensure that all implementations will indeed be extensible.
No extension is currently defined.
One extension at most may be run within an EAP-PSK dialog: there can
neither be sequences of extensions nor interleaved extensions.
However, extensions may take a variable number of round trips to
complete.
Only the server can start an extension and, if it does so, it MUST
start it in the first payload it sends over the protected channel.
Bersani Expires November 30, 2004 [Page 23]
Internet-Draft EAP-PSK June 2004
peer server
| RAND_S |
|<---------------------------------------------------------|
| |
| RAND_P||MAC_P||ID_P |
|--------------------------------------------------------->|
| |
| MAC_S||PCHANNEL_S_0(EXT) |
|<---------------------------------------------------------|
| |
| PCHANNEL_P_1(EXT) |
|--------------------------------------------------------->|
| |
. .
. .
. .
| PCHANNEL_S_2i(EXT) |
|<---------------------------------------------------------|
| |
| PCHANNEL_P_2i+1(EXT) |
|--------------------------------------------------------->|
| |
Bersani Expires November 30, 2004 [Page 24]
Internet-Draft EAP-PSK June 2004
3. EAP-PSK Message format
For the sake of simplicity, EAP-PSK uses a fixed message format.
There are four different types of EAP-PSK messages:
o The first EAP-PSK message, which is sent by the server to the
peer.
o The second EAP-PSK message, which is sent by the peer to the
server.
o The third EAP-PSK message, which is sent by the server to the
peer.
o The fourth EAP-PSK message, which is sent by the peer to the
server. This is also the type of the message that the peer
further sends to the server in case of an extended authentication.
This is also essentially the type of message that the server
further sends to the peer in case of an extended authentication
(the only slight modification that occurs is the EAP Code that is
set to 1 instead of 2).
For the sake of clarity, the whole EAP packet that encapsulates the
EAP-PSK message, i.e., the EAP-PSK message plus its EAP headers, are
depicted here after.
3.1 EAP-PSK First Message
The first EAP-PSK message, which is sent by the server to the peer,
has the following format.
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
The first EAP-PSK message consists of a 16-byte random number RAND_S.
3.2 EAP-PSK Second Message
The second EAP-PSK message, which is sent by the peer to the server,
Bersani Expires November 30, 2004 [Page 25]
Internet-Draft EAP-PSK June 2004
has the following format.
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=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| RAND_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_P |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: ID_P :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It consists of:
o A 16-byte random number: RAND_P
o A 16-byte MAC: MAC_P
o A variable length field that conveys the peer's NAI: ID_P. The
length of this field is deduced from the EAP length field. This
peer's NAI MUST NOT exceed 983 bytes. This restriction aims at
avoiding fragmentation issues (see Section 6.10).
3.3 EAP-PSK Third Message
The third EAP-PSK message, which is sent by the server to the peer,
has the following format.
Bersani Expires November 30, 2004 [Page 26]
Internet-Draft EAP-PSK June 2004
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=1 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| MAC_S |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It consists of:
o A 16-byte MAC: MAC_S
o A variable length field that constitutes the protected channel:
PCHANNEL
If there is no extension, i.e., if the authentication is standard,
the PCHANNEL field consists of:
o A 4-byte Nonce N (see Section 2.2.3).
o A 16-byte Tag (see Section 2.2.3).
o A 2-bit result indication flag R.
o A 1-bit extension flag E, which is set to 0.
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
R, E and Reserved are sent encrypted by the protected channel (see
Section 2.2.3).
Bersani Expires November 30, 2004 [Page 27]
Internet-Draft EAP-PSK June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |0| Reserved|
+-+-+-+-+-+-+-+-+
If there is an extension, i.e., if the authentication is extended,
the PCHANNEL field consists of:
o A 4-byte Nonce N (see Section 2.2.3).
o A 16-byte Tag (see Section 2.2.3).
o A 2-bit result indication flag R.
o A 1-bit extension flag E, which is set to 1.
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
o A variable length EXT field.
R, E, Reserved and EXT are sent encrypted by the protected channel
(see Section 2.2.3).
Bersani Expires November 30, 2004 [Page 28]
Internet-Draft EAP-PSK June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |1| Reserved| |
+-+-+-+-+-+-+-+-+ +
: EXT :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This EXT field is split in two subfields:
o The EXT_Type subfield which indicates the type of the extension
o The EXT_Payload subfield which consists in the payload of the
extension. The EXT_Payload length is derived from the EAP Length
field. EXT_Payload MUST have a bit-length that is a multiple of 8
bits and MUST NOT exceed 977 bytes. The latter restriction aims
at avoiding fragmentation issues (see Section 6.10).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXT_Type | |
+-+-+-+-+-+-+-+-+ +
: EXT_Payload :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4 EAP-PSK Fourth Message
The fourth EAP-PSK message, which is sent by the peer to the server,
has the following format.
Bersani Expires November 30, 2004 [Page 29]
Internet-Draft EAP-PSK June 2004
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=2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type EAP-PSK | |
+-+-+-+-+-+-+-+-+ +
: PCHANNEL :
: :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It consists of a variable length field that consitutes the protected
channel: PCHANNEL
The PCHANNEL field has the following structure, which was already
described in Section 3.3.
If there is no extension, i.e., if the authentication is standard,
the PCHANNEL field consists of:
o A 4-byte Nonce N (see Section 2.2.3).
o A 16-byte Tag (see Section 2.2.3).
o A 2-bit result indication flag R.
o A 1-bit extension flag E, which is set to 0.
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
R, E and Reserved are sent encrypted by the protected channel (see
Section 2.2.3).
Bersani Expires November 30, 2004 [Page 30]
Internet-Draft EAP-PSK June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |0| Reserved|
+-+-+-+-+-+-+-+-+
If there is an extension, i.e., if the authentication is extended,
the PCHANNEL field consists of:
o A 4-byte Nonce N (see Section 2.2.3).
o A 16-byte Tag (see Section 2.2.3).
o A 2-bit result indication flag R.
o A 1-bit extension flag E, which is set to 1.
o A 5-bit Reserved field, which is set to zero on emission and
ignored on reception.
o A variable length EXT field.
R, E, Reserved and EXT are sent encrypted by the protected channel
(see Section 2.2.3).
Bersani Expires November 30, 2004 [Page 31]
Internet-Draft EAP-PSK June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tag |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |1| Reserved| |
+-+-+-+-+-+-+-+-+ +
: EXT :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This EXT field is split in two subfields:
o The EXT_Type subfield which indicates the type of the extension
o The EXT_Payload subfield which consists in the payload of the
extension. The EXT_Payload length is derived from the EAP Length
field. EXT_Payload MUST have a bit-length that is a multiple of 8
bits and MUST NOT exceed 977 bytes. The latter restriction aims
at avoiding fragmentation issues (see Section 6.10).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXT_Type | |
+-+-+-+-+-+-+-+-+ +
: EXT_Payload :
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bersani Expires November 30, 2004 [Page 32]
Internet-Draft EAP-PSK June 2004
4. Rules of Operation for the EAP-PSK Protected Channel
In this section, the rules of operation of the EAP-PSK protected
channel are presented:
o How protected result indications are implemented.
o How an extended authentication works in details.
4.1 Protected Result Indications
The R flag of the PCHANNEL field in the third and fourth EAP-PSK
messages is used to provide result indications.
Since this 2-bit flag is communicated over the protected channel, it
is:
o Encrypted so that only the peer and the server can know its value.
o Integrity-protected so that it cannot be modified by an attacker
without the peer or the server detecting this modification.
o Protected against replays.
This 2-bit R flag can take the following values:
o 01 to mean CONT
o 10 to mean DONE_SUCCESS
o 11 to mean DONE_FAILURE
The peer and the server each remember some information about both the
R's that they have sent and the R's they have received. It is the
conjunction of both sent and received R values that indicate the
success or the failure of the EAP-PSK dialog.
In case of a standard authentication, the following R's should be
exchanged:
o Either the server sends a DONE_SUCCESS in the PCHANNEL of the
third EAP-PSK message, to which the peer replies with a
DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK message, which
successfully ends the EAP-PSK dialog.
o Or the server sends a DONE_FAILURE in the PCHANNEL of the third
EAP-PSK message, to which the peer replies with a DONE_FAILURE in
the PCHANNEL of the fourth EAP-PSK message, which unsuccessfully
ends the EAP-PSK dialog.
In case of an extended authentication, more complex echanges may
occur, which is why the CONT value was introduced.
The rules of operation for each value R may take are presented in
details hereafter.
Bersani Expires November 30, 2004 [Page 33]
Internet-Draft EAP-PSK June 2004
4.1.1 CONT
The server and the peer each initialize the values of R they intend
to send and receive as CONT.
CONT stands for "Continue". It indicates that the EAP-PSK dialog is
not yet successful and that the party sending it wants to continue
the dialog to try and reach success.
Indeed, although the peer and the server MUST have successfully
authenticated each other, thanks to MAC_P and MAC_S, before they
start communicating over the protected channel, the EAP-PSK dialog
may not yet be deemed successful after this mutual authentication
because of authorization matters. For instance, a prepaid customer
of a wireless Hot-Spot might have successfully authenticated but also
have to refill its account, e.g., with a credit card transaction over
the protected channel, before it is authorized.
4.1.2 DONE_SUCCESS
DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK
dialog successful and therefore proposes to end this dialog.
Once the server has sent a DONE_SUCCESS, it MUST keep sending this
value for R.
The peer MUST first receive a DONE_SUCCESS from the server before it
is allowed to send a DONE_SUCCESS.
After the peer has received a DONE_SUCCESS from the server, it MAY:
o Send a CONT to the server if it has not reached success on its
side. The server that receives a CONT SHOULD continue the EAP-PSK
dialog (see Section 6.2 for some discussion on the security
implications of this SHOULD).
o Send a DONE_SUCCESS to the server, which will end the EAP-PSK
dialog with success.
o Send a DONE_FAILURE to the server, which will end the EAP-PSK
dialog with failure.
4.1.3 DONE_FAILURE
DONE_FAILURE indicates that the party that sent it deems the EAP-PSK
dialog unsucessful and proposes to end this dialog because nothing
will make it change its mind.
If the server is the first to send a DONE_FAILURE, then, the peer
that receives this DONE_FAILURE MUST reply with a DONE_FAILURE and
fail, which ends the EAP-PSK dialog.
Bersani Expires November 30, 2004 [Page 34]
Internet-Draft EAP-PSK June 2004
If the peer is the first to send a DONE_FAILURE, then, the server
that receives this DONE_FAILURE MUST immediately end this EAP-PSK
dialog without sending any further EAP-PSK message, and fail.
4.2 Extended Authentication
An extended authentication can only be started by the server.
Exactly one extension (identified by the EXT_Type subfield of the EXT
field) MUST be run during an EAP-PSK extended authentication dialog.
The extenstion is run over the protected channel: it can assume
confidentialy, integrity and replay protection.
To start an extended authentication, the server sets the PCHANNEL E
flag to 1 and includes the EXT_Payload of the extension it has
chosen.
Since EAP-PSK does not provide fragmentation, the extension MUST NOT
send an EXT_Payload larger than 977 bytes, which corresponds to the
1020-byte EAP MTU that may minimally be assumed (see [2]).
Moreover, an extension MUST NOT send an empty EXT_Payload (because
this has a particular meaning for EAP-PSK, see below).
When the peer receives the third EAP-PSK message with the E flag set
to 1, it checks whether it is able to process the proposed extension.
If it is not able to process the proposed extension, i.e., it does
not recognize the EXT_Type of the proposed extension, it sets E=1 in
its reply (the fourth EAP-PSK message) and include an EXT field of
the same EXT_Type but with an empty EXT_Payload.
Depending on the values taken by the R flags, the EAP-PSK dialog MAY:
o End
* In case the peer's policy mandates that it fails in case of an
unrecognized extension, it sends a DONE_FAILURE in the fourth
EAP-PSK message.
* In case the server has sent a DONE_SUCCESS in the third EAP-PSK
message and the peer's policy authorizes it to succeed even if
the extension is not recognized, the peer sends a DONE_SUCCESS
o Continue for exactly one round-trip, namely, in case the server
has sent a CONT in the third EAP-PSK message and the peer's policy
authorizes it to succeed even if the extension is not recognized,
the peer replies with a CONT in the fourth EAP-PSK message. The
server MUST then, depending on its policy, either send a
DONE_SUCCESS or a DONE_FAILURE to the peer in the fifth EAP-PSK
message. If the server sent a DONE_SUCCESS in the fifth EAP-PSK
message, the peer MUST send a DONE_SUCCESS in the sixth EAP-PSK
Bersani Expires November 30, 2004 [Page 35]
Internet-Draft EAP-PSK June 2004
message. All these messages MUST have the E flag sent to 1 with
an EXT field of with the EXT_Type of the extension that was
proposed and an empty EXT_Payload (this behavior was chosen to
simplify implementations).
If it is able to process the proposed extension, then it does so. In
this case, the extension MUST be aware of the R values sent and
received and able to propose to update them. All the subsequent
messages exchanged between the peer and the server MUST have the E
flag sent to 1 with an EXT field of the EXT_Type of the extension
that was proposed and a non-empty EXT_Payload.
Bersani Expires November 30, 2004 [Page 36]
Internet-Draft EAP-PSK June 2004
5. IANA considerations
This section provides guidance to the IANA regarding registration of
values related to the EAP-PSK protocol, in accordance with [8].
The following terms are used here with the meanings defined in [8]:
"name space" and "registration".
The following policies are used here with the meanings defined in
[8]: "Expert Review" and "Specification Required".
This document introduces two new Internet Assigned Numbers Authority
(IANA) considerations:
o It requires IANA to allocate an EAP-Request/Response Type for
EAP-PSK.
o There is one name space in EAP-PSK that requires registration: the
EXT_Type values (see Section 3.3 and Section 3.4).
For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. But in order to allow for the
allocation of values prior to the RFC being approved for publication,
the Designated Expert can approve allocations once it seems clear
that an RFC will be published. The Designated expert will post a
request to the EAP WG mailing list (or a successor designated by the
Area Director) for comment and review, including an Internet-Draft.
Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a notice
of the decision to the EAP WG mailing list or its successor, as well
as informing IANA. A denial notice must be justified by an
explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable.
5.1 Allocation of an EAP-Request/Response Type for EAP-PSK
This document requires IANA to allocate a new EAP Type for EAP-PSK.
It is not yet clear whether this request will follow the standards
track allocation process for method types (type numbers 192-253 ) or
the "informational" one (type numbers 46-191), see [2] for more
details on these two method types spaces.
5.2 Allocation of EXT Type numbers
EAP-PSK is not intended as a general-purpose protocol, and
allocations of EXT_Type SHOULD NOT be made for purposes unrelated to
Bersani Expires November 30, 2004 [Page 37]
Internet-Draft EAP-PSK June 2004
authentication, authorization and accounting.
EXT_Type numbers have a range from 1 to 255.
EXT_Type 255 has been allocated for Experimental use.
EXT_Type 1-254 may be allocated on the advice of a Designated Expert,
with Specification Required.
Bersani Expires November 30, 2004 [Page 38]
Internet-Draft EAP-PSK June 2004
6. Security Considerations
[2] highlights several attacks that are possible against EAP as EAP
does not provide any robust security mechanism.
This section discusses the claimed security properties of EAP-PSK as
well as vulnerabilities and security recommendations in the threat
model of [2].
6.1 Mutual Authentications
EAP-PSK provides mutual authentication.
The server believes that the peer is authentic because it can
calculate a valid MAC and the peer believes that the server is
authentic because it can calculate another valid MAC.
The authentication protocol used in EAP-PSK, AKEP2, enjoys a security
proof in the provable security paradigm, see [3]. It is believed
that the way EAP-PSK instantiates AKEP2 retains its security
properties.
The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK,
OMAC1, also enjoys a security proof in the provable security
paradigm, see [7]. A tag length of 16 bytes for OMAC1 is deemed
appropriate by the cryptographic community for authentication.
The underlying block cipher used, AES-128, is widely believed to be a
secure block cipher.
Finally, the key used for mutual authentication, AK, is only used for
that purpose, which makes this part cryptographically independent of
the other parts of the protocol.
6.2 Protected Result Indications
EAP-PSK provides protected result indications thanks to its 2-bit R
flag (see Section 4.1).
Care MAY be taken against byzantine failures, that is to say, for
instance, when a peer tries to force a server to engage in a never
ending conversation. This could for example, be done by a peer that
keeps sending a CONT after it has received a DONE_SUCCESS from the
server. A policy MAY limit the number of rounds in an EAP-PSK
extended authentication to mitigate this threat, which is outside our
threat model.
It should also be noted that the cryptographic protection of the
Bersani Expires November 30, 2004 [Page 39]
Internet-Draft EAP-PSK June 2004
result indications does not prevent message deletion.
For instance, let us consider a scenario in which:
o A server sends a DONE_SUCCESS to a peer.
o The peer replies with a DONE_SUCCESS.
In case the last message from the peer is intercepted, and an EAP
Success is sent to the peer before any retransmission from the server
reaches it or the retransmissions from the server are also deleted,
the peer will believe that it has successfully authenticated to the
server while the server will fail.
This behavior is well known (see e.g., [24]) and in a sense
unavoidable. There is a trade-off between efficiency and the "level"
of information sharing that is attainable. EAP-PSK specified a
single round trip of DONE_SUCCESS because, it is believed that:
o In case there is an adversary capable of disrupting the
communication channel, it can do so whenever it wants (be it after
one or 10 round trip or even during data communication).
o Other layers/applications will generally start by doing a specific
key exchange and confirmation procedure using the keys derived by
EAP-PSK. This is typically done by IEEE 802.11i "four-way
handshake". In case the error is not detected by EAP- PSK, it
should be detected then (please note however, that it is bad
practice to rely on external mechanism to ensure synchronization,
unless this is an explicit property of the external mechanism).
6.3 Integrity Protection
EAP-PSK provides integrity protection thanks to the Tag of its
protected channel (see Section 2.2.3).
6.4 Replay Protection
EAP-PSK provides replay protection thanks to the Nonce of its
protected channel (see Section 2.2.3).
6.5 Dictionary Attacks
Because EAP-PSK is not a password protocol, it is not vulnerable to
dictionary attacks.
Indeed, the PSK used by EAP-PSK MUST NOT be derived from a password.
Derivation of the PSK from a password may lead to dictionary attacks.
However using a 16-byte PSK key has:
o Ergonomic impacts: some people may find it cumbersome to manually
provision a 16-byte PSK.
Bersani Expires November 30, 2004 [Page 40]
Internet-Draft EAP-PSK June 2004
o Deployment impacts: some people may want to reuse existing
credential databases that contain passwords and not PSKs.
Since, despite the warning not to use passwords, people will probably
do that anyway, guidance to derive a PSK from a password is provided
in Appendix A. The method proposed in Appendix A only tries to make
dictionary attacks harder. It does not eliminate them.
It is however not a fatality that passwords be used instead of PSKs:
people rarely use password derived certificates, so why should they
do so for shared keys?
6.6 Key Derivation
EAP-PSK supports key derivation.
The key hierarchy is specified in Section 2.1.
The mechanism used for key derivation is the modified counter mode.
The instantiation of the modified counter in EAP-PSK complies with
the conditions stated in [6] so that the security proof in the
provable security paradigm of [6] holds.
The underlying block cipher used, AES-128, is widely believed to be a
secure block cipher.
A first key derivation occurs to calculate AK and KDK from the PSK:
it is called the key setup (see Section 2.2.1).
It uses the PSK as the key to the modified counter mode. The input
block to the modified counter mode is a public constant.
Thus, AK and KDK are believed to be cryptographically separated and
computable only to those who have knowledge of the PSK.
A second key derivation occurs to derive session keys, namely, the
TEK, MSK and EMSK (see Section 2.2.2).
It uses uses KDK as the key to the modified counter mode. The input
block to the key derivation is taken to be RB as specified in AKEP2.
It should be emphasized that the peer has control of the session keys
derived by EAP-PSK. In particular, it can easily choose RB so that
one of the 9 derived 16-byte key blocks (see Section 2.1) takes a
pre-specified value.
It was chosen not to prevent this peer control of the session keys
because:
o Preventing it would have added some complexity to the protocol
(typically, the inclusion of a one-way mode of operation of AES in
Bersani Expires November 30, 2004 [Page 41]
Internet-Draft EAP-PSK June 2004
the key derivation part).
o It is believed that the peer won't try to force the server to use
some pre- specified value for the session keys. Such an attack is
outside the threat model and seems to have little value compared
to a peer sharing its PSK.
This session keys control by the peer is however not the behavior
recommended by EAP in section 7.10 of [2].
Since deriving the session keys requires some cryptographic
computations, it is RECOMMENDED that the session keys be derived only
once authentication has succeeded (i.e., once the server has
successfully verified MAC_P for the server side, and once the peer
has successfully verified MAC_S for the peer side).
It is RECOMMENDED to take great care in implementations, so that
derived keys are not made available if the EAP-PSK dialog fails,
e.g., ends with DONE_FAILURE.
The TEK MUST NOT be made available to anyone except to the current
EAP-PSK dialog.
6.7 Denial of Service Resistance
Denial of Service resistance (DoS) has not been a design goal for
EAP-PSK.
It is however believed that EAP-PSK does not provide any obvious and
avoidable venue for such attacks.
It is worth noting that the server has to maintain some state and do
a cryptographic calculation when it engages in an EAP-PSK
conversation, namely the 16-byte RAND_S. This should however not
lead to resource exhaustion as this state and the associated
computation are fairly lightweigth.
It is RECOMMENDED that EAP-PSK does not allow EAP notifications to be
interleaved in its dialog to prevent potential DoS attacks. Indeed,
since EAP Notifications are not integrity protected, they can easily
be spoofed by an attacker. Such an attacker could force a peer that
allows Notifications to engage in a discussion which would delay his
authentication or result in the peer taking unexpected actions (e.g.,
in case the Notification is used to prompt the peer to do some "bad"
action).
It is up to the implementation of EAP-PSK or to the peer and the
server to specify the maximum number of failed cryptographic checks
that are allowed. For instance, does the reception of a bogus MAC_P
Bersani Expires November 30, 2004 [Page 42]
Internet-Draft EAP-PSK June 2004
in the second EAP-PSK message cause a fatal error or is it discarded
to continue waiting for the valid response of the valid peer? There
is a trade-off between possibly allowing multiple tentative forgeries
and allowing a direct DoS (in case the first error is fatal).
6.8 Session Independance
Thanks to its key derivation mechanisms, EAP-PSK provides session
independence: passive attacks (such as capture of the EAP
conversation) or active attacks (including compromise of the MSK or
EMSK) does not enable compromise of subsequent or prior MSKs or
EMSKs.
6.9 Exposition of the PSK
EAP-PSK does not provide perfect forward secrecy. Compromise of the
PSK leads to compromise of recorded past sessions.
Compromise of the PSK enables the attacker to impersonate the peer
and the server: compromise of the PSK leads to "full" compromise of
future sessions.
Last, EAP-PSK provides no protection against a legitimate peer
sharing its PSK with a third party. Such protection may be provided
by appropriate repositories for the PSK, which choice is outside the
scope of this document.
6.10 Fragmentation
EAP-PSK does not support fragmentation and reassembly.
Indeed, the largest EAP-PSK frame is at most 1015 bytes long,
because:
o The maximum length for the peer NAI identity used in EAP- PSK is
983 bytes (see Section 3.2
o The maximum length for the EXT_Payload field used in EAP-PSK is
977 bytes (see Section 3.3 and Section 3.4).
Per Section 3.1 of [2], the lower layers over which EAP MAY be run
are assumed to have an EAP MTU of 1020 bytes or greater. Since the
EAP header is 5 bytes long, supporting fragmentation for EAP-PSK is
unnecessary.
Extensions that require sending a payload larger than 977 bytes
should provide their own fragmentation and reassembly mechanism.
Bersani Expires November 30, 2004 [Page 43]
Internet-Draft EAP-PSK June 2004
6.11 Channel Binding
EAP-PSK does not provide channel binding as this feature is still
very much work in progress (see [14]).
However, it should be easy to add it to EAP-PSK as an extension (see
Section 2.3.2).
6.12 Fast Reconnect
EAP-PSK does not provide any fast reconnect capability.
Indeed, as noted for instance in [15], mutual authentication (without
counters or timestamps) requires three exchanges, thus four exchanges
in EAP since any EAP-Request MUST be answered to by an EAP-Response.
Since this minimum bound is already reached in EAP-PSK standard
authentication, there is no way the number of round-trips used within
EAP-PSK can be reduced without using timestamps or counters.
Timestamps and counters were deliberately avoided for the sake of
simplicity and security (e.g., synchronization issues).
6.13 Identity Protection
Since it was chosen to restrict to a single cryptographic primitive
from symmetric cryptography, namely the block cipher AES-128, it
appears that it is not possible to provide "reasonable" identity
protection without failing to meet the simplicity goal.
Hereafter is an informal discussion of what is meant by identity
protection and the rationale behind the requirement of identity
protection. For some complementary discussion, please refer to [38].
Identity protection basically means preventing the disclosure of the
identities of the communicating parties over the network, which is
quite contradictory with authentication. There are two levels of
identity protection: protection against passive attackers and
protection against active eavesdroppers.
As explained in [38], "a common example [for identity protection] is
the case of mobile devices wishing to prevent an attacker from
correlating their (changing) location with the logical identity of
the device (or user)".
In case only symmetric cryptography is used, only a weak form of
identity protection may be offered, namely pseudonym management. In
other words, the peer and the server agree on pseudonyms that they
use to identify each other and usually change them periodically,
Bersani Expires November 30, 2004 [Page 44]
Internet-Draft EAP-PSK June 2004
possibly in a protected way so that an attacker cannot learn new
pseudonyms before they are used.
With pseudonym management, there is a trade-off between allowing for
pseudonym resynchronization (thanks to a permanent identity) and
being vulnerable to active attacks (in which the attacker forges
messages simulating a pseudonym desynchronization).
Indeed, a protocol using time-varying pseudonyms may want to
anticipate "desynchronization" situations such as, for instance, when
the peer believes that its current pseudonym is "pseudo1@bigco.com"
whereas the server believes this peer will use the pseudonym
"pseudo2@bigco.com" (which is the pseudonym the server has sent to
update "pseudo1@bigco.com").
Because pseudonym management adds complexity to the protocol and
implies this unsatisfactory trade-off, it was decided not to include
this feature in EAP-PSK.
However, EAP-PSK may provide protection against the two main attacks
that account, in our opinion, for the identity protection requirement
placed on EAP methods.
The first attack is an active probing attack, i.e. the attacker
probes a device in order to learn its logical identity.
This attack does not apply to EAP-PSK since it is the initiator of
the EAP-PSK conversation that has to disclose and prove its identity
first. In fact, the server never discloses its identity (see Section
2.2.2).
The second attack is passive and aims at learning valuable
information on the peer.
For instance, let us take the example of user John Doe that roams and
connects to a Hot-Spot owned and operated by Wireless Internet
Service Provider (WISP) BAD. Suppose this user authenticates to his
home WISP (WISP GOOD) with an EAP method under an identity (e.g.,
"john.doe@wispgood.com") that allows WISP BAD (or an attacker) to
recover his "real-life" identity, i.e. John Doe. An example
drawback of this, is that a competitor of John Doe's WISP may want to
win John Doe as a new customer by sending him some special targeted
advertisement.
EAP-PSK can very simply thwart this attack, merely by avoiding to
provide John Doe with a NAI that allows easy recovery of his real-
life identity. EAP-PSK believes that, when a NAI that is
decorrelated to a real-life identity, is used, no valuable
information leaks because of the EAP method.
Indeed, the identity of the WISP used by a peer has to be disclosed
anyway in the realm portion of its NAI to allow AAA routing.
Moreover, the Medium Access Control Address of the peer's Network
Bersani Expires November 30, 2004 [Page 45]
Internet-Draft EAP-PSK June 2004
Interface Card can generally be used to track the peer as efficiently
as a fixed NAI.
6.14 Protected Ciphersuite Negotiation
EAP-PSK does not allow to negotiate cipher suites. Hence, it is not
vulnerable to negotiation attacks and does not implement protected
cipher suite negotiation.
6.15 Confidentiality
Although EAP-PSK provides confidentiality in its protected channel,
it cannot claim to do so as per Section 7.2.1 of [2]: "A method
making this claim MUST support identity protection".
6.16 Cryptographic Binding
Since EAP-PSK is not intended to be tunneled within another protocol
that omits peer authentication, it does not implement cryptographic
binding.
6.17 Implementation of EAP-PSK
To really provide security, not only must a protocol be well-thought
and correctly specified, but its implementation must take special
care.
For instance, implementing cryptographic algorithms requires special
skills since cryptographic software is not only vulnerable to
classical attacks (e.g., buffer overflow or missing checks) but also
to some special cryptographic attacks (e.g., side channels attacks
like timing ones, see [37]). In particular, care must be taken to
avoid such attacks in EAX implementation, please refer to [4] for a
note on this point.
An EAP-PSK implementation SHOULD use a good source of randomness to
generate the random numbers required in the protocol. Please refer
to [20] for more information on generating random numbers for
security applications.
Bersani Expires November 30, 2004 [Page 46]
Internet-Draft EAP-PSK June 2004
7. Security Claims
This section provides the security claims required by [2].
[a] Mechanism. EAP-PSK is based on symmetric cryptography (AES-128)
and uses a 16-byte Pre-shared Key (PSK).
[b] Security claims. EAP-PSK provides:
* Mutual authentication (see Section 6.1)
* Integrity protection (see Section 6.3)
* Replay protection (see Section 6.4)
* Key derivation (see Section 6.6)
* Dictionary attack resistance (see Section 6.5)
* Session independence (see section Section 6.5)
[c] Key strength. EAP-PSK provides a 16-byte effective key strength.
[d] Description of key hierarchy. Please see Section 2.1.
[e] Indication of vulnerabilities. EAP-PSK does not provide:
* Identity protection (see Section 6.13)
* Confidentiality (see Section 6.15)
* Fast reconnect (see Section 6.12)
* Fragmentation (see Section 6.10)
* Cryptographic binding (see Section 6.16)
* Protected cipher suite negotiation (see Section 6.14)
* Perfect Forward Secrecy (see Section 6.6)
* Key agreement: the session key is chosen by the peer (see
Section 6.6)
* Channel binding (see Section 6.11)
Bersani Expires November 30, 2004 [Page 47]
Internet-Draft EAP-PSK June 2004
8. Intellectual Property Rights Notice
The author neither has, nor is of aware of, any patents or pending
patents relevant to material included in this draft.
Bersani Expires November 30, 2004 [Page 48]
Internet-Draft EAP-PSK June 2004
9. Acknowledgments
This EAP method has been inspired by EAP-SIM and EAP-Archie. Many
thanks to their respective authors: Jesse Walker, Russ Housley Henry
Haverinen and Joseph Salowey.
Special thanks to
o Henri Gilbert for some interesting discussions on the
cryptographic parts of EAP-PSK.
o Aurelien Magniez for his valuable feedback on network aspects of
EAP-PSK, his curiosity and rigor that led to numerous
improvements, and his help in
<http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAPPSKimplementation.htm.htm>
.
o Thomas Otto for his valuable feedback on EAP-PSK and the
implementation of <http://t13.mine.nu/EAP-PSK/>.
EAP-PSK also benefited from (unfortunately) brief exchanges with
other EAP methods designers: many thanks to Hannes Tschofenig
(EAP-IKEv2) and Nancy Cam-Winget (EAP-FAST).
Finally, thanks to Jari Arkko and Bernard Aboba, the beloved EAP WG
chairs, for the work they stimulate!
Bersani Expires November 30, 2004 [Page 49]
Internet-Draft EAP-PSK June 2004
10. References
10.1 Normative References
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[3] Bellare, M. and P. Rogaway, "Entity Authentication and Key
Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994.
[4] Bellare, M., Rogaway, P. and D. Wagner, "The EAX mode of
operation", FSE 04, Springer-Verlag LNCS 3017, 2004.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Gilbert, H., "The Security of One-Block-to-Many Modes of
Operation", FSE 03, Springer-Verlag LNCS 2287, 2003.
[7] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03,
Springer-Verlag LNCS 2887, 2003.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] National Institute of Standards and Technology, "Specification
for the Advanced Encryption Standard (AES)", Federal Information
Processing Standards (FIPS) 197, November 2001.
10.2 Informative References
[10] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-02 (work in
progress), June 2004.
[11] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Zorn, G., Dommety, G., Perkins, C., Patil, B.,
Mitton, D., Manning, S., Beadles, M., Walsh, P., Chen, X.,
Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B.,
Hirschman, B., Hsu, R., Xu, Y., Campbell, E., Baba, S. and E.
Jaques, "Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000.
[12] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
Bersani Expires November 30, 2004 [Page 50]
Internet-Draft EAP-PSK June 2004
RFC 2716, October 1999.
[13] Arkko, J. and H. Haverinen, "EAP AKA Authentication",
draft-arkko-pppext-eap-aka-12 (work in progress), April 2004.
[14] Arkko, J. and P. Eronen, "Authenticated Service Identities for
the Extensible Authentication Protocol (EAP)",
draft-arkko-eap-service-identity-auth-00 (work in progress),
April 2004.
[15] Bellare, M., Pointcheval, D. and P. Rogaway, "Authenticated Key
Exchange Secure Against Dictionary attacks", EUROCRYPT 00,
Springer-Verlag LNCS 1807, 2000.
[16] Bersani, F., "EAP shared key methods: a tentative synthesis of
those proposed so far",
draft-bersani-eap-synthesis-sharedkeymethods-00 (work in
progress), April 2004.
[17] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[18] Carlson, J., Aboba, B. and H. Haverinen, "EAP SRP-SHA1
Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt
(work in progress), July 2001.
[19] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[20] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[21] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-04 (work in
progress), April 2004.
[22] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
[23] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[24] Halpern, J. and Y. Moses, "Knowledge and common knowledge in
a distributed environment", Journal of the ACM 37:3, 1990.
[25] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for GSM Subscriber Identity Modules
(EAP-SIM)", draft-haverinen-pppext-eap-sim-13 (work in
Bersani Expires November 30, 2004 [Page 51]
Internet-Draft EAP-PSK June 2004
progress), April 2004.
[26] Huitema, C., Postel, J. and S. Crocker, "Not All RFCs are
Standards", RFC 1796, April 1995.
[27] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
[28] Institute of Electrical and Electronics Engineers, "Unapproved
Draft Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications: Specification
for Enhanced Security", IEEE Draft 802.11i (work in progress),
2004.
[29] Institute of Electrical and Electronics Engineers, "Standard
for Telecommunications and Information Exchange Between Systems
- LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications",
IEEE Standard 802.11, 1999.
[30] Jablon, D., "The SPEKE Password-Based Key Agreement Methods",
draft-jablon-speke-02 (work in progress), November 2002.
[31] Josefsson, S., "The EAP SecurID(r) Mechanism",
draft-josefsson-eap-securid-01 (work in progress), February
2002.
[32] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected
EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07
(work in progress), October 2003.
[33] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[34] Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions",
draft-kamath-pppext-eap-mschapv2-01 (work in progress), April
2004.
[35] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-14 (work in progress), June 2004.
[36] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[37] Kocher, P., "Timing Attacks on Implementations of
Bersani Expires November 30, 2004 [Page 52]
Internet-Draft EAP-PSK June 2004
Diffie-Hellman, RSA, DSS, and Other Systems", CRYPTO 96,
Springer-Verlag LNCS 1109, 1996.
[38] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE Protocols",
CRYPTO 03, Springer-Verlag LNCS 2729, June 2003.
[39] MacNally, C., "Cisco LEAP protocol description", September
2001.
[40] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook of
Applied Cryptography", , 1996.
[41] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
[42] National Institute of Standards and Technology, "Password
Usage", Federal Information Processing Standards (FIPS) 112,
May 1985.
[43] Rescorla, E., "A Survey of Authentication Mechanisms",
draft-iab-auth-mech-03 (work in progress), March 2004.
[44] Salowey, J., "EAP Flexible Authentication via Secure Tunneling
(EAP-FAST)", draft-cam-winget-eap-fast-00 (work in progress),
February 2004.
[45] Schneier, B., Mudge and D. Wagner, "Cryptanalysis of
Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE
99, Springer-Verlag LNCS 1740, October 1999.
[46] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[47] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[48] Stanley, D., "EAP Method Requirements for Wireless LANs",
draft-walker-ieee802-req-01 (work in progress), May 2004.
[49] Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method
(EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in progress),
February 2004.
[50] Walker, J. and R. Housley, "The EAP Archie Protocol",
draft-jwalker-eap-archie-01 (work in progress), June 2003.
[51] Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0", April
2003.
Bersani Expires November 30, 2004 [Page 53]
Internet-Draft EAP-PSK June 2004
[52] Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03,
August 2003.
[53] "Pre-Shared Key Ciphersuites for Transport Layer Security
(TLS)", draft-ietf-tls-psk-00 (work in progress), June 2004.
Author's Address
Florent Bersani
France Telecom R&D
38, rue du General Leclerc
Issy-Les-Moulineaux 92794 Cedex 9
FR
EMail: florent.bersani@francetelecom.com
Bersani Expires November 30, 2004 [Page 54]
Internet-Draft EAP-PSK June 2004
Appendix A. Generation of the PSK from a password - Discouraged
It is formally discouraged to use a password to generate the PSK,
since this opens the door to exhaustive search or dictionary, two
attacks that would not otherwise be possible.
However, as people will probably do this anyway, guidance is provided
hereafter to generate the PSK from a password.
For some hints on how passwords should be selected, please refer to
[42].
The technique presented herein is drawn from [33]. It is intended to
try to mitigate the risks associated with password usage in
cryptography, typically dictionary attacks.
If the binary representation of the password is strictly fewer than
16 bytes long (which by the way means that the chosen password is
probably weak because it is too short), then it is padded to 16 bytes
with zeroes as its high order bits.
If the binary representation of the password is strictly more than 16
bytes long, then it is hashed down to exactly 16 bytes using the
Matyas-Meyer-Oseas hash (please refer to [40] for a description of
this hash) with IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has
been arbitrarily selected).
We now assume that we have a 16-byte number derived from the initial
password (that can be the password itself if its binary
representation is exactly 16 bytes long). We shall call this number
P16.
Following the notations used in [33], the PSK is derived thanks to
PBKDF2 instantiated with:
o P16 as P
o The first 96 bits of the XOR of the peer and server NAIs as Salt
(zero-padded if necessary).
o 5000 as c
o 48 as dkLen
Although this gives better protection than nothing, this derivation
does not stricto sensu protect against dictionary attacks. It only
makes dictionary precomputation harder.
Bersani Expires November 30, 2004 [Page 55]
Internet-Draft EAP-PSK June 2004
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 procedures with respect to rights in RFC 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 (2004). 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.
Bersani Expires November 30, 2004 [Page 56]