RFC 4764
The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method
Pages: 64
Experimental
Experimental
Part 1 of 3 – Pages 1 to 15
Network Working Group F. Bersani Request for Comments: 4764 France Telecom R&D Category: Experimental H. Tschofenig Siemens Networks GmbH & Co KG January 2007 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. The IESG thinks that this work is related to IETF work done in WGs EMU and EAP, but this does not prevent publishing.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). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.
Table of Contents
1. Introduction ....................................................4 1.1. Design Goals for EAP-PSK ...................................4 1.1.1. Simplicity ..........................................4 1.1.2. Wide Applicability ..................................5 1.1.3. Security ............................................5 1.1.4. Extensibility .......................................5 1.2. Terminology ................................................5 1.3. Conventions ................................................8 1.4. Related Work ...............................................9 2. Protocol Overview ..............................................12 2.1. EAP-PSK Key Hierarchy .....................................13 2.1.1. The PSK ............................................13 2.1.2. AK .................................................14 2.1.3. KDK ................................................14 2.2. The TEK ...................................................15 2.3. The MSK ...................................................15 2.4. The EMSK ..................................................15 2.5. The IV ....................................................15 3. Cryptographic Design of EAP-PSK ................................15 3.1. The Key Setup .............................................16 3.2. The Authenticated Key Exchange ............................19 3.3. The Protected Channel .....................................23 4. EAP-PSK Message Flows ..........................................25 4.1. EAP-PSK Standard Authentication ...........................26 4.2. EAP-PSK Extended Authentication ...........................28 5. EAP-PSK Message Format .........................................31 5.1. EAP-PSK First Message .....................................32 5.2. EAP-PSK Second Message ....................................34 5.3. EAP-PSK Third Message .....................................36 5.4. EAP-PSK Fourth Message ....................................39 6. Rules of Operation for the EAP-PSK Protected Channel ...........41 6.1. Protected Result Indications ..............................41 6.1.1. CONT ...............................................42 6.1.2. DONE_SUCCESS .......................................43 6.1.3. DONE_FAILURE .......................................43 6.2. Extended Authentication ...................................43 7. IANA Considerations ............................................45 7.1. Allocation of an EAP-Request/Response Type for EAP-PSK ....45 7.2. Allocation of EXT Type Numbers ............................45 8. Security Considerations ........................................46 8.1. Mutual Authentication .....................................46 8.2. Protected Result Indications ..............................47 8.3. Integrity Protection ......................................48 8.4. Replay Protection .........................................48 8.5. Reflection Attacks ........................................48 8.6. Dictionary Attacks ........................................49
8.7. Key Derivation ............................................49
8.8. Denial-of-Service Resistance ..............................51
8.9. Session Independence ......................................51
8.10. Exposition of the PSK ....................................52
8.11. Fragmentation ............................................52
8.12. Channel Binding ..........................................53
8.13. Fast Reconnect ...........................................53
8.14. Identity Protection ......................................53
8.15. Protected Ciphersuite Negotiation ........................55
8.16. Confidentiality ..........................................55
8.17. Cryptographic Binding ....................................55
8.18. Implementation of EAP-PSK ................................55
9. Security Claims ................................................56
10. Acknowledgments ...............................................57
11. References ....................................................57
11.1. Normative References .....................................57
11.2. Informative References ...................................58
Appendix A. Generation of the PSK from a Password - Discouraged ...62
1. Introduction
1.1. Design Goals for EAP-PSK
The Extensible Authentication Protocol (EAP) [3] provides an authentication framework that supports multiple authentication methods. This document specifies an EAP method, called EAP-PSK, that uses a Pre-Shared Key (PSK). EAP-PSK was developed at France Telecom R&D in 2003-2004. It is published as an RFC for the general information of the Internet community and to allow independent implementations. Because PSKs are of frequent use in security protocols, other protocols may also refer to a PSK or contain this word in their name. For instance, Wi-Fi Protected Access (WPA) [48] specifies an authentication mode called "WPA-PSK". EAP-PSK is distinct from these protocols and should not be confused with them. Design goals for EAP-PSK were: o Simplicity: EAP-PSK should be easy to implement and deploy without any pre-existing infrastructure. It should be available quickly because recently-released protocols, such as IEEE 802.11i [27], employ EAP in a different threat model than PPP [44] and thus require "modern" EAP methods. o Wide applicability: EAP-PSK should be suitable to authenticate over any network, and in particular over IEEE 802.11 [28] wireless LANs. o Security: EAP-PSK should be conservative in its cryptographic design. o Extensibility: EAP-PSK should be easily extensible.1.1.1. Simplicity
For the sake of simplicity, EAP-PSK relies on a single cryptographic primitive, AES-128 [7]. Restriction to such a primitive, and in particular, not using asymmetric cryptography like Diffie-Hellman key exchange, makes EAP- PSK:
o Easy to understand and implement while avoiding cryptographic
negotiations.
o Lightweight and well suited for any type of device, especially
those with little processing power and memory.
However, as further discussed in Section 8, 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.
For the sake of simplicity, EAP-PSK has also chosen a fixed message
format and not a Type-Length-Value (TLV) design.
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 EAP threat
model that is presented in Section 7.1 of [3].
1.1.3. Security
Since the design of authenticated key exchange is notoriously known
to be hard and error prone, EAP-PSK tries to avoid inventing any new
cryptographic mechanism. It attempts instead to build on existing
primitives and protocols that have been reviewed by the cryptographic
community.
1.1.4. Extensibility
EAP-PSK explicitly provides a mechanism to allow future extensions
within its protected channel (see Section 3.3). Thanks to this
mechanism, EAP-PSK will be able to provide more sophisticated
services as the need to do so arises.
1.2. Terminology
Authentication, Authorization, and Accounting (AAA)
Please refer to [10] for more details.
AES-128 A block cipher specified in the Advanced Encryption
Standard [7].
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
[14] for more details.
Backend Authentication Server
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 [26], and has the same meaning in this
document.)
CMAC Cipher-based Message Authentication Code. It is the
authentication mode of operation of AES recommended by NIST
in [8].
Extensible Authentication Protocol (EAP)
Defined in [3].
EAP Authenticator (or simply Authenticator)
The end of the EAP link initiating the EAP authentication
methods. (This terminology is also used in [26], 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 [26], this end is known as the Supplicant.)
EAP server (or simply server)
The entity that terminates the EAP authentication with the
peer. When there is no Backend Authentication Server, this
term refers to the EAP Authenticator. Where the EAP
Authenticator operates in pass-through mode, it refers to
the Backend Authentication Server.
EAX An authenticated-encryption with associated data mode of
operation for block ciphers [4].
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
reserved for future uses that are not defined yet and is
not provided to a third party. Please refer to [9] for
more details.
EAP-PSK generates a 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 [11], 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. Please refer to
[9] 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
[40]. IEEE 802.11i uses the acronym MIC (Message Integrity
Check) to avoid confusion with the other meaning of the
acronym MAC (Medium Access Control).
Master Session Key (MSK)
Keying material that is derived between the EAP peer and
server and exported by the EAP method. In existing
implementations, a AAA server acting as an EAP server
transports the MSK to the Authenticator [9].
EAP-PSK generates a 64-byte MSK.
Network Access Identifier (NAI)
Identifier used to identify the communicating parties [2].
One Key CBC-MAC 1 (OMAC1)
A method to generate a Message Authentication Code [29].
CMAC is the name under which NIST has standardized OMAC1.
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,
each bit of which 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 [3] for a definition of
this term. This feature has been introduced because EAP-
Success/Failure packets are unidirectional and are not
protected.
Transient EAP Key (TEK)
A session key that 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 [9].
EAP-PSK uses a 16-byte TEK for its protected channel, which
is the only ciphersuite available between the EAP peer and
server to protect the EAP conversation. This ciphersuite
uses AES-128 in the EAX mode of operation.
1.3. Conventions
All numbers presented in this document 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 CMAC with AES-
128; see Section 3.2).
[String] denotes the concatenation of String with the MAC of String
calculated as specified by the context. Hence, we have, with K
specified by the context: [String]=String||MAC(K,String)
** 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. 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 [1].1.4. 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 [3], which uses a MD5 challenge similar to [45]. o OTP (EAP-Request/Response type 5), defined in [3], which aims at providing One-Time Password support similar to [22] and [39]. o GTC (EAP-Request/Response type 6), defined in [3], which aims at providing Generic Token Card Support. Unfortunately, all three methods are deprecated for security reasons that are explained in part in [3]. Myriads of EAP methods have, however, been otherwise proposed: o One as an experimental RFC (EAP-TLS [11]), which therefore is not a standard (see [25]). o Some as individual Internet-Draft submissions (e.g., [42] 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 yet easily and widely available, which is all the more regrettable because 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 of EAP methods).
Among these proposals, there are some that:
o Are broken from a security point of view, e.g.:
* LEAP, which is specified in [38] and whose vulnerabilities are
discussed in [49].
* EAP-MSCHAPv2, which is specified in [34] and whose
vulnerabilities are indirectly discussed in [43].
o Essentially require additional infrastructure, e.g., EAP-SIM [24],
EAP-AKA [12], or OTP/token card methods like [31].
o Are not shared key methods but are often confused with them,
namely, the password methods, e.g., EAP-SRP [18] or SPEKE [30],
whose wide adoption very unfortunately seems to be hindered by
Intellectual Property Rights issues.
o Are generic tunneling methods, which do not essentially rely on
Pre-Shared Keys as they require a public-key certificate for the
server and allow the peer to authenticate with whatever EAP method
or even other non-EAP authentication mechanisms, namely, [32] and
[21].
o Are abandoned but have provided the basis for EAP-PSK, namely,
EAP-Archie [47].
o Are possible alternatives to EAP-PSK (i.e., claimed to be secure
and subject of active work):
* EAP-FAST [42].
* EAP-IKEv2 [46].
* EAP-TLS (when shared key/password support is added to TLS; see
[50]).
EAP-PSK differs from the aforementioned methods on the following
points:
o No attacks on EAP-PSK within its threat model have yet been found.
o EAP-PSK was not designed to leverage a pre-existing
infrastructure. Thus, it does not inherit potential limitations
of such an infrastructure and it should be easier to deploy "from
scratch".
o EAP-PSK wished to avoid IPR blockages.
o EAP-PSK does not have any dependencies on protocols other than
EAP.
o EAP-PSK was restricted to simply proposing a Pre-Shared Key method
with symmetric cryptography
* To remain simple to understand and implement
* To avoid potentially complex configurations and negotiations
o EAP-PSK was designed with efficiency in mind.
2. Protocol Overview
Figure 1 presents an overview of the EAP-PSK key hierarchy. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ | | ^ | EAP-PSK Protocol: a Pre-Shared Key EAP Method | | | | | | +----------+ | | | | PSK | | | | |(16 bytes)| | | | +----------+ | | | | | | | v | | | *********************** | | | *Modified Counter Mode* | | | *********************** | | | | | | | | v v | | | +----------+ +----------+ +----------------+ | | | | AK | | KDK | | RAND_P | | | | |(16 bytes)| |(16 bytes)| | (16 bytes) | | | | +----------+ +----------+ +----------------+ | | | | | | | | | | | | | +-----------+ | | | | | +--------+|Plain Text | | | | | |+-------+|Header H||Var.Length | | | | | ||Nonce N||22 bytes|+-----------+ v v Local | ||4 bytes|+--------+ | *********************** to EAP | |+-------+ | +--------+ +------*Modified Counter Mode* Method | | | v v v *********************** | | | | ******* +--------+ |64 |64 | | | | * EAX *-------|TEK | |bytes |bytes | | | +-->******* |16 bytes| | | | | | | +--------+ | | | | | +-----+----+ | | | | | v v | | | | |+--------+ +-------------------+ | | | | ||Tag | |Cipher Text Payload| | | | | ||16 bytes| | Variable length L | | | | | |+--------+ +-------------------+ | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ | | ^ +-+-+-+-+-++ +-+-+-+-+-++ | |MSK | |EMSK | | | | | | Exported | +-+-+-+-+-++ +-+-+-+-+-++ by EAP |
| | Method | | | | V V | ************************* V * AAA Key Derivation * ---+ * Naming & Binding * ************************* Figure 1: EAP-PSK Key Hierarchy Overview2.1. EAP-PSK Key Hierarchy
This section presents the key hierarchy used by EAP-PSK. This hierarchy is inspired by the EAP key hierarchy described in [9].2.1.1. The PSK
The 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 are compromised if it has wider distribution. Please note that EAP-PSK shares this property with all other symmetric key methods (including all password-based methods). EAP-PSK also assumes the EAP server and EAP peer identify the correct PSK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This PSK is used, as shown in Figure 2, to derive two 16-byte static long-lived subkeys, respectively called the Authentication Key (AK) and the Key-Derivation Key (KDK). This derivation should only be done once: it is called the key setup. See Section 3.1 for an explanation of why PSK is not used as a static long-lived key, but only as the initial keying material for deriving the static long- lived keys, AK and KDK, which are actually used by the protocol EAP- PSK.
+---------------------------+ | PSK | | (16 bytes) | +---------------------------+ | | v v +---------------------------+ +---------------------------+ | AK | | KDK | | (16 bytes) | | (16 bytes) | +---------------------------+ +---------------------------+ Figure 2: Derivation of AK and KDK from the PSK2.1.2. AK
EAP-PSK uses AK to mutually authenticate the EAP peer and the EAP server. AK is a static long-lived key derived from the PSK; see Section 3.1. AK is not a session key. The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case when there is at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI; see Section 2.1.1. The EAP peer chooses the AK to use based on the EAP server NAI that has been sent by the EAP server in the first EAP-PSK message (namely, ID_S; see Section 4.1) and the EAP peer NAI it chooses to include in the second EAP-PSK message (namely, ID_P; see Section 4.1).2.1.3. KDK
EAP-PSK uses KDK to derive session keys shared by the EAP peer and the EAP server (namely, the TEK, MSK, and EMSK). KDK is a static long-lived key derived from the PSK; see Section 3.1. KDK is not a session key. The EAP server and EAP peer identify the correct AK to use with each other thanks to their respective NAIs. This means that there MUST only be at most one AK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI. This is the case
when there is at most one PSK shared between an EAP server using a given server NAI and an EAP peer using a given peer NAI; see Section 2.1.1. The EAP peer chooses the AK to use based on the EAP server NAI that has been sent by the EAP server in the first EAP-PSK message (namely, ID_S; see Section 4.1) and the EAP peer NAI it chooses to include in the second EAP-PSK message (namely, ID_P; see Section 4.1).2.2. The TEK
EAP-PSK derives a 16-byte TEK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and KDK. This TEK is used to implement a protected channel for both mutually authenticated parties to communicate over securely.2.3. The MSK
EAP-PSK derives a MSK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and the KDK. The MSK is 64 bytes long, which complies with [3].2.4. The EMSK
EAP-PSK derives an EMSK thanks to a random number exchanged during authentication (RAND_P; see Section 5.1) and the KDK. The EMSK is 64 bytes long, which complies with [3].2.5. The IV
EAP-PSK does not derive any IV, which complies with [9].
(page 15 continued on part 2)