| TOC |
|
This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 August 17, 2005.
Copyright (C) The Internet Society (2005).
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.
1.
Introduction
1.1
Design goals for EAP-PSK
1.1.1
Simplicity
1.1.2
Wide Applicability
1.1.3
Security
1.1.4
Extensibility
1.2
Terminology
1.3
Conventions
1.4
Related Work
2.
Protocol overview
2.1
EAP-PSK key hierarchy
2.1.1
The PSK
2.1.2
The TEK
2.1.3
The MSK
2.1.4
The EMSK
2.1.5
The IV
2.2
Cryptographic design of EAP-PSK
2.2.1
The Key Setup
2.2.2
The Authenticated Key Exchange
2.2.3
The Protected Channel
2.3
EAP-PSK Message Flows
2.3.1
EAP-PSK Standard Authentication
2.3.2
EAP-PSK Extended Authentication
3.
EAP-PSK Message format
3.1
EAP-PSK First Message
3.2
EAP-PSK Second Message
3.3
EAP-PSK Third Message
3.4
EAP-PSK Fourth Message
4.
Rules of Operation for the EAP-PSK Protected Channel
4.1
Protected Result Indications
4.1.1
CONT
4.1.2
DONE_SUCCESS
4.1.3
DONE_FAILURE
4.2
Extended Authentication
5.
IANA considerations
5.1
Allocation of an EAP-Request/Response Type for EAP-PSK
5.2
Allocation of EXT Type numbers
6.
Security Considerations
6.1
Mutual Authentication
6.2
Protected Result Indications
6.3
Integrity Protection
6.4
Replay Protection
6.5
Dictionary Attacks
6.6
Key Derivation
6.7
Denial of Service Resistance
6.8
Session Independence
6.9
Exposition of the PSK
6.10
Fragmentation
6.11
Channel Binding
6.12
Fast Reconnect
6.13
Identity Protection
6.14
Protected Ciphersuite Negotiation
6.15
Confidentiality
6.16
Cryptographic Binding
6.17
Implementation of EAP-PSK
7.
Security Claims
8.
Acknowledgments
9.
References
9.1
Normative References
9.2
Informative References
§
Authors' Addresses
A.
Generation of the PSK from a password - Discouraged
§
Intellectual Property and Copyright Statements
| TOC |
The Extensible Authentication Protocol (EAP) [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004. 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).
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) [52]Wi-Fi Alliance, Wi-Fi Protected Access, version 2.0, April 2003. 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:
For the sake of simplicity, EAP-PSK relies on a single cryptographic primitive, AES-128 [7]National Institute of Standards and Technology, Specification for the Advanced Encryption Standard (AES), November 2001..
Restriction to such a primitive, and in particular, not using asymmetric cryptography like Diffie-Hellman key exchange, makes EAP-PSK:
However, as further discussed in Section 6Security Considerations, 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.
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 [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004..
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 to build instead on existing primitives and protocols that have been reviewed by the cryptographic community.
EAP-PSK explicitly provides a mechanism to allow future extensions within its protected channel (see Section 2.2.3The Protected Channel). Thanks to this mechanism, EAP-PSK will be able to provide more sophisticated services as the need to do so appears.
- Authentication, Authorization and Accounting (AAA)
- Please refer to [10]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, November 2000. for more details.
- AES-128
- A block cipher specified in the Advanced Encryption Standard [7]National Institute of Standards and Technology, Specification for the Advanced Encryption Standard (AES), November 2001..
- 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]Bellare, M. and P. Rogaway, Entity Authentication and Key Distribution, 1994. 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 [28]Institute of Electrical and Electronics Engineers, Local and Metropolitan Area Networks: Port-Based Network Access Control, September 2001., and has the same meaning in this document).
- Extensible Authentication Protocol (EAP)
- Defined in [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004..
- EAP Authenticator (or simply Authenticator)
- The end of the EAP link initiating the EAP authentication methods. (This terminology is also used in [28]Institute of Electrical and Electronics Engineers, Local and Metropolitan Area Networks: Port-Based Network Access Control, September 2001., 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 [28]Institute of Electrical and Electronics Engineers, Local and Metropolitan Area Networks: Port-Based Network Access Control, September 2001., 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, [3]Bellare, M., Rogaway, P. and D. Wagner, The EAX mode of operation, 2004..
- 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 [8]Aboba, B., Extensible Authentication Protocol (EAP) Key Management Framework, November 2004. 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]Aboba, B. and D. Simon, PPP EAP TLS Authentication Protocol, October 1999., 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 [8]Aboba, B., Extensible Authentication Protocol (EAP) Key Management Framework, November 2004. 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 [41]Menezes, A., van Oorschot, P. and S. Vanstone, Handbook of Applied Cryptography, 1996.. 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 [8]Aboba, B., Extensible Authentication Protocol (EAP) Key Management Framework, November 2004.. EAP-PSK generates a 64-byte MSK.
- Network Access Identifier (NAI)
- Identifier used to identify the communicating parties [1]Aboba, B. and M. Beadles, The Network Access Identifier, January 1999..
- One Key CBC-MAC 1 (OMAC1)
- A method to generate a Message Authentication Code [5]Iwata, T. and K. Kurosawa, OMAC: One-Key CBC MAC, 2003.. OMAC1 is the variant of the OMAC message authentication code family that is used by EAP-PSK.
- 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 [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004. 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 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 [8]Aboba, B., Extensible Authentication Protocol (EAP) Key Management Framework, November 2004.. 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.
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 OMAC1 with AES-128, see Section 2.2.2The Authenticated Key Exchange).
[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.
At the time this document is written, only three EAP methods are standards track EAP methods per IETF terminology (see [17]Bradner, S., The Internet Standards Process -- Revision 3, October 1996.), namely:
Unfortunately, all three methods are deprecated for security reasons that are explained in part in [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004..
Myriads of EAP methods have however been otherwise proposed:
However, no secure and mature Pre-Shared Key EAP method is yet easily and widely 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]Bersani, F., EAP shared key methods: a tentative synthesis of those proposed so far, April 2004. for a more thorough synthesis on EAP methods).
Among these proposals, there are some which:
EAP-PSK differs from the aforementioned methods on the following points:
EAP-PSK was designed with efficiency in mind.
| TOC |
Figure 1EAP-PSK overview presents an overview of the EAP-PSK protocol.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
| EAP-PSK Protocol: a Pre-Shared Key EAP Method | |
| | |
| +----------+ | |
| |PSK | | |
| |(16 bytes)| | |
| +----------+ | |
| | | |
| v | |
| *********************** | |
| *Modified Counter Mode* | |
| *********************** | |
| | | | |
| v v | |
| +----------+ +----------+ +----------------+ | |
| |AK | |KDK | |Random Number RB| | |
| |(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 overview |
This section presents the key hierarchy used by EAP-PSK. This hierarchy is inspired by the EAP Key hierarchy described in [8]Aboba, B., Extensible Authentication Protocol (EAP) Key Management Framework, November 2004..
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.
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 PSK is used, as shown in Figure 2Derivation of AK and KDK from the PSK, 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.1The Key Setup.
+---------------------------+
| PSK |
| (16 bytes) |
+---------------------------+
| |
v v
+---------------------------+ +---------------------------+
| AK | | KDK |
| (16 bytes) | | (16 bytes) |
+---------------------------+ +---------------------------+
| Figure 2: Derivation of AK and KDK from the PSK |
EAP-PSK uses AK to mutually authenticate the EAP peer and the EAP server.
EAP-PSK uses KDK to derive session keys shared by the EAP peer and the EAP server (namely, the TEK, MSK and EMSK).
EAP-PSK derives a 16-byte TEK thanks to a random number exchanged during authentication (RAND_S, see Section 3.1EAP-PSK First Message) and KDK.
This TEK is used to implement a protected channel for both mutually authenticated parties to communicate over securely.
EAP-PSK derives a MSK thanks to a random number exchanged during authentication (RAND_S, see Section 3.1EAP-PSK First Message) and the KDK.
The MSK is 64 bytes long, which complies with [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004..
EAP-PSK derives an EMSK thanks to a random number exchanged during authentication (RAND_S, see Section 3.1EAP-PSK First Message) and the KDK.
The EMSK is 64 bytes long, which complies with [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004..
EAP-PSK does not derive any IV, which complies with [8]Aboba, B., Extensible Authentication Protocol (EAP) Key Management Framework, November 2004..
EAP-PSK relies on a single cryptographic primitive, a block cipher, which is instantiated with AES-128. AES-128 takes a 16-byte Pre-Shared Key and a 16-byte Plain Text block as inputs. It outputs a 16-byte Cipher Text block. For a detailed description of AES-128, please refer to [7]National Institute of Standards and Technology, Specification for the Advanced Encryption Standard (AES), November 2001..
AES-128 has been chosen because:
Other block ciphers could easily be proposed for EAP-PSK, as EAP-PSK does not intricately depend on AES-128. The only parameters of AES-128 that EAP-PSK depends on, are the AES-128 block and key size (16 bytes). For the sake of simplicity, EAP-PSK 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 because of the security issues with AES-128. EAP-PSK' should therefore use a different EAP-Request/Response Type number. With the EAP-Request/Response Type number space structure defined in [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004., this should not be a problem.
EAP-PSK uses three cryptographic parts:
Each part is discussed in more detail in the subsequent paragraphs.
EAP-PSK needs two cryptographically separated 16-byte subkeys for mutual authentication 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 split 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 term 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. If the PSK is deleted, it should be done so securely (see, for instance, [19]Department of Defense of the United States, National Industrial Security Program Operating Manual, January 1995. for guidance on secure deletion of the PSK).
Derivation of AK and KDK from the PSK is called the key setup:
AK and KDK are derived from the PSK using the modified counter mode of operation 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.2The Authenticated Key Exchange).
The details of the derivation of AK and KDK from the PSK are shown in Figure 3Derivation of AK and KDK from the PSK in Details.
+--------------------------+
| "0" |
| Input Block (16 bytes) |
+--------------------------+
|
v
+----------------+
| |
| 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 3: 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 appropriately truncated or zero-padded), but this did not seem to add much security to the scheme, whereas it added complexity. 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.
The authentication protocol used by EAP-PSK is inspired of AKEP2 which is described in [14]Bellare, M. and P. Rogaway, Entity Authentication and Key Distribution, 1994..
AKEP2 consists of a one and half round trip exchange, as shown in Figure 4Overview of AKEP2.
Bob Alice | A||RA | |<---------------------------------------------------------| | | | [B||A||RA||RB] | |--------------------------------------------------------->| | | | [A||RB] | |<---------------------------------------------------------|
| Figure 4: Overview of AKEP2 |
In AKEP2,
EAP-PSK instantiates this protocol with:
OMAC1 was chosen as the MAC algorithm because it is capable of handling of arbitrary length messages, and its design is simple. It also enjoys a security proof. It is also under consideration by NIST for standardization. For a detailed description of OMAC1, please refer to [5]Iwata, T. and K. Kurosawa, OMAC: One-Key CBC MAC, 2003..
In AKEP2 the key exchange is "implicit": the session keys are derived from RB. In EAP-PSK, the session keys are also derived from RB by using KDK and the modified counter mode of operation of AES-128 described in [4]Gilbert, H., The Security of One-Block-to-Many Modes of Operation, 2003.. This mode was chosen because it is 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., it expands one AES-128 input block into a longer t-block output, where t>=2. The derivation of the session keys is shown in Figure 5Derivation of the Session Keys.
+--------------------------+ +-------------------------------+
| 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) |
+------------+ +----------------------+ +----------------------+
| Figure 5: Derivation of the Session Keys |
The input to the derivation of the session keys is RB.
The outputs of the derivation of the session keys 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).
The details of the derivation of the session keys are shown in Figure 6Derivation of the Session Keys in Details.
+--------------------------+
| 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| +---+
+--------+ | +--------+ | +--------+ |
| | |
+----------------+ +----------------+ +----------------+
| | | | | |
| 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) |
+-----------------+ +-----------------+ +------------------+
| Figure 6: Derivation of the Session Keys in Details |
The counter values are set respectively to the first t integers (that is ci="i", with i=1 to 9).
Keying material is sensitive information and should be handled accordingly (see Section 6.9Exposition of the PSK for further discussion.
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.
EAP-PSK uses the EAX mode of operation to provide this protected channel. For a detailed description of EAX, please refer to [3]Bellare, M., Rogaway, P. and D. Wagner, The EAX mode of operation, 2004.. Figure 7The Protected Channel shows how EAX is used to implement EAP-PSK protected channel.
+-----------+ +----------------+ +---------------------+ +----------+
| Nonce N | | Header H | | Plain Text Payload | | TEK |
| 4 bytes | | 22 bytes | | Variable length L | | 16 bytes |
+-----------+ +----------------+ +---------------------+ +----------+
| | | |
v v v v
+-------------------------------------------------------------------+
| |
| EAX |
| |
+-------------------------------------------------------------------+
| |
v v
+---------------------+ +----------+
| Cipher Text Payload | | Tag |
| Variable length L | | 16 bytes |
+---------------------+ +----------+
| Figure 7: The Protected Channel |
This protected channel:
EAX is instantiated with AES-128 as the underlying block cipher.
AES-128 is keyed with the TEK.
The nonce N is used to provide cryptographic security to the
encryption and data origin authentication as well as 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 around. In the unlikely, yet possible, event of the server sending 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).
The Header H consists in the first 22 bytes of the EAP Request or Response packet (i.e. the EAP Code, Identifier, Length and Type fields followed by the EAP-PSK Flags and RAND_S 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]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004.) and seems to be existing practice at IETF (see, for instance, [37]Kent, S. and R. Atkinson, IP Authentication Header, November 1998.).
The Plain Text Payload is the payload that is to be encrypted and integrity protected. The Cipher Text payload is the result of the encryption of the Plain Text.
The Tag is a MAC that protects both the Header and the Plain Text
Payload.
The verification of the Tag must only be done after a successful verification of the Nonce
for replay protection.
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 should be logged.
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:
EAP-PSK may consist of two different types of message flows:
EAP-PSK introduces the concept of session to facilitate its analysis and provide a cleaner interface to other layers. A session is a particular instance of an EAP-PSK dialog between two parties. This session is identified by a session identifier.
EAP-PSK standard authentication is comprised of four messages, i.e., two round trips; see Figure 8EAP-PSK Standard Authentication.
peer server | Flags||RAND_S||ID_S | |<---------------------------------------------------------| | | | Flags||RAND_S||RAND_P||MAC_P||ID_P | |--------------------------------------------------------->| | | | Flags||RAND_S||MAC_S||PCHANNEL_S_0 | |<---------------------------------------------------------| | | | Flags||RAND_S||PCHANNEL_P_1 | |--------------------------------------------------------->| | |
| Figure 8: EAP-PSK Standard Authentication |
All EAP-PSK messages include a sort of header which is comprised of two fields:
This standard message flow could be comprised of only three messages, like AKEP2, were it not the request/response nature of EAP that prevents the third message to be the last one. Since the fourth message is mandatory, EAP-PSK chose to take advantage of this and set up a protected channel.
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]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004. which recommends that the EAP-Response/Identity be used primarily for routing purposes and selecting which EAP method to use, and therefore that EAP methods include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response..
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).
Figure 9EAP-PSK Extended Authentication presents the message sequence for EAP-PSK extended authentication.
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:
No extension is currently defined.
At most One extension may be run within a single 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.
peer server | Flags||RAND_S||ID_S | |<---------------------------------------------------------| | | | Flags||RAND_S||RAND_P||MAC_P||ID_P | |--------------------------------------------------------->| | | | Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT) | |<---------------------------------------------------------| | | | Flags||RAND_S||PCHANNEL_P_1(EXT) | |--------------------------------------------------------->| | | . . . . . . | Flags||RAND_S||PCHANNEL_S_2i(EXT) | |<---------------------------------------------------------| | | | Flags||RAND_S||PCHANNEL_P_2i+1(EXT) | |--------------------------------------------------------->| | |
| Figure 9: EAP-PSK Extended Authentication |
Please refer to Section 4Rules of Operation for the EAP-PSK Protected Channel for more details on how extended authentication works.
| TOC |
For the sake of simplicity, EAP-PSK uses a fixed message format. There are four different types of EAP-PSK messages:
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 in Figure 10EAP-PSK First Message, Figure 12EAP-PSK Second Message, Figure 13EAP-PSK Third Message and Figure 17EAP-PSK Fourth Message.
The first EAP-PSK message is sent by the server to the peer. It has the format presented in Figure 10EAP-PSK First Message.
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 | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : ID_S : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 10: EAP-PSK First Message |
The first EAP-PSK message consists of:
The Flags field has the format presented in Figure 11EAP-PSK Flags Field.
0 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | T | Reserved | +-+-+-+-+-+-+-+-+
| Figure 11: EAP-PSK Flags Field |
The Flags field is comprised of two subfields:
The PCHANNEL Nonce field N (see Section 3.3EAP-PSK Third Message) is used to distinguish between the different EAP-PSK messages that may be exchanged during extended authentication which all have T set to 3, i.e., the fourth EAP-PSK message and possibly the next ones.
The second EAP-PSK message is sent by the peer to the server. It has the format presented in Figure 12EAP-PSK Second Message.
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 | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_P | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + | | + + | MAC_P | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + : ID_P : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 12: EAP-PSK Second Message |
It consists of:
The Flags field format is presented in Figure 11EAP-PSK Flags Field.
The third EAP-PSK message is sent by the server to the peer. It has the format presented in Figure 13EAP-PSK Third Message.
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 | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | MAC_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + : PCHANNEL : : : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 13: EAP-PSK Third Message |
It consists of:
The Flags field format is presented in Figure 11EAP-PSK Flags Field.
If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:
R, E and Reserved are sent encrypted by the protected channel (see Section 2.2.3The Protected Channel).
If there is no extension, PCHANNEL has the format presented in Figure 14The PCHANNEL Field with E=0 (where R, E and Reserved are presented in the clear for the sake of clarity, although in reality they are sent encrypted).
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| +-+-+-+-+-+-+-+-+
| Figure 14: The PCHANNEL Field with E=0 |
If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:
R, E, Reserved and EXT are sent encrypted by the protected channel (see Section 2.2.3The Protected Channel).
If there is an extension, PCHANNEL has the format presented in Figure 15The PCHANNEL Field with E=1 where R, E, Reserved and EXT are presented in the clear for the sake of clarity, although in reality they are sent encrypted)..
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 : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 15: The PCHANNEL Field with E=1 |
This EXT field is split in two subfields:
The format of the EXT field is presented in Figure 16The EXT Field.
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 : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 16: The EXT Field |
The fourth EAP-PSK message is sent by the peer to the server. It has the format presented in Figure 17EAP-PSK Fourth Message.
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 | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : PCHANNEL : : : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 17: EAP-PSK Fourth Message |
It consists of:
The Flags field format is presented in Figure 11EAP-PSK Flags Field.
The PCHANNEL field has the following structure, which was already described in Section 3.3EAP-PSK Third Message.
If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:
R, E and Reserved are sent encrypted by the protected channel (see Section 2.2.3The Protected Channel).
If there is no extension, PCHANNEL has the format presented in Figure 14The PCHANNEL Field with E=0.
If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:
R, E, Reserved and EXT are sent encrypted by the protected channel (see Section 2.2.3The Protected Channel).
If there is an extension, PCHANNEL has the format presented in Figure 15The PCHANNEL Field with E=1.
This EXT field is split in two subfields:
The format of the EXT field is presented in Figure 16The EXT Field.
| TOC |
In this section, the rules of operation of the EAP-PSK protected channel are presented:
The R flag of the PCHANNEL field in the third and fourth type of EAP-PSK messages is used to provide result indications.
Since this 2-bit flag is communicated over the protected channel, it is:
This 2-bit R flag can take the following values:
The peer and the server each remember some information about both the values of R that they have sent and the values of R 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 values of R should be exchanged:
In case of an extended authentication, more complex exchanges 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.
The server and the peer each initialize the values of R they intend to send and receive as CONT.
Here 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 issues. For instance, a prepaid customer of a wireless Hot-Spot might have successfully authenticated but has to refill its account, e.g., with a credit card transaction over the protected channel, before it is authorized.
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:
DONE_FAILURE indicates that the party that sent it deems the EAP-PSK dialog unsuccessful 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.
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.
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 extension is run over the protected channel: it can assume confidentiality, 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 960 bytes, which corresponds to the 1020-byte EAP MTU that may minimally be assumed (see [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004.).
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 the peer 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:
If the peer 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.
| TOC |
This section provides guidance to the IANA regarding registration of values related to the EAP-PSK protocol, in accordance with [6]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998..
The following terms are used here with the meanings defined in [6]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998.: "name space" and "registration".
The following policies are used here with the meanings defined in [6]Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, October 1998.: "Expert Review" and "Specification Required".
This document introduces two new Internet Assigned Numbers Authority (IANA) considerations:
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.
This document requires IANA to allocate a new EAP Type for EAP-PSK.
EAP-PSK is not intended as a general-purpose protocol, and allocations of EXT_Type should not be made for purposes unrelated to 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.
| TOC |
[2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004. 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]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004..
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 which inspired EAP-PSK, AKEP2, enjoys a security proof in the provable security paradigm, see [14]Bellare, M. and P. Rogaway, Entity Authentication and Key Distribution, 1994..
The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK, OMAC1, also enjoys a security proof in the provable security paradigm, see [5]Iwata, T. and K. Kurosawa, OMAC: One-Key CBC MAC, 2003.. A tag length of 16 bytes for OMAC1 is currently deemed appropriate by the cryptographic community for entity 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.
EAP-PSK provides protected result indications thanks to its 2-bit R flag (see Section 4.1Protected Result Indications).
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 result indications does not prevent message deletion.
For instance, let us consider a scenario in which:
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., [25]Halpern, J. and Y. Moses, Knowledge and common knowledge in a distributed environment, 1990.) 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:
EAP-PSK provides integrity protection thanks to the Tag of its protected channel (see Section 2.2.3The Protected Channel).
EAP-PSK provides replay protection thanks to the Nonce of its protected channel (see Section 2.2.3The Protected Channel).
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:
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 AGeneration of the PSK from a password - Discouraged. The method proposed in Appendix AGeneration of the PSK from a password - Discouraged 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?
EAP-PSK supports key derivation.
The key hierarchy is specified in Section 2.1EAP-PSK key hierarchy.
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 [4]Gilbert, H., The Security of One-Block-to-Many Modes of Operation, 2003. so that the security proof for this mode 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.1The Key Setup).
It uses the PSK as the key to the modified counter mode.
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.2The Authenticated Key Exchange).
It uses
KDK as the key to the modified counter mode.
It should be emphasized that the peer has control of the session keys derived by EAP-PSK. In particular, it can easily choose the random number it sends in EAP-PSK so that one of the nine derived 16-byte key blocks (see Section 2.1EAP-PSK key hierarchy) takes a pre-specified value.
It was chosen not to prevent this control of the session keys by the peer because:
This is however not the behavior recommended by EAP in section 7.10 of [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004..
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.
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 do a cryptographic calculation and maintain some state when it engages in an EAP-PSK conversation, namely generate and remember the 16-byte RAND_S. This should however not lead to resource exhaustion as this state and the associated computation are fairly lightweight.
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 EAP Notifications to engage in a discussion which would delay his authentication or result in the peer taking unexpected actions (e.g., in case a 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 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).
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.
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.
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. The PSK used by EAP-PSK must only be shared between two parties: the peer and the server. In particular, this PSK must not be shared by a group of peers communicating with the same server.
The PSK used by EAP-PSK must be cryptographically separated from keys used by other protocols, otherwise the security of EAP-PSK may be compromised. It is a rule of the thumb in cryptography to use different keys for different applications.
EAP-PSK does not support fragmentation and reassembly.
Indeed, the largest EAP-PSK frame is at most 1015 bytes long, because:
Per Section 3.1 of [2]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004., 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 960 bytes should provide their own fragmentation and reassembly mechanism.
EAP-PSK does not provide channel binding as this feature is still very much work in progress (see [13]Arkko, J. and P. Eronen, Authenticated Service Identities for the Extensible Authentication Protocol (EAP), October 2004.).
However, it should be easy to add it to EAP-PSK as an extension (see Section 2.3.2EAP-PSK Extended Authentication).
EAP-PSK does not provide any fast reconnect capability.
Indeed, as noted for instance in [15]Bellare, M., Pointcheval, D. and P. Rogaway, Authenticated Key Exchange Secure Against Dictionary attacks, 2000., 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).
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, refer to [39]Krawczyk, H., SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols, June 2003..
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 [39]Krawczyk, H., SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols, June 2003., "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, 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 trivially provide some protection when the concern is to avoid the "real-life" identity of the user being "discovered". 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