tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4764

Experimental
Pages: 64
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec-eap

The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method

Part 1 of 3, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
      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

Top      ToC       Page 4 
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:

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
   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

Top      ToC       Page 7 
             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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   "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).

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
   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.

Top      ToC       Page 12 
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 |

Top      ToC       Page 13 
                                     |               |          Method |
                                     |               |                 |
                                     V               V                 |
                                 *************************             V
                                 *   AAA  Key Derivation *          ---+
                                 *   Naming & Binding    *
                                 *************************

                 Figure 1: EAP-PSK Key Hierarchy Overview

2.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.

Top      ToC       Page 14 
                   +---------------------------+
                   |            PSK            |
                   |        (16 bytes)         |
                   +---------------------------+
                      |                     |
                      v                     v
   +---------------------------+     +---------------------------+
   |            AK             |     |            KDK            |
   |        (16 bytes)         |     |        (16 bytes)         |
   +---------------------------+     +---------------------------+

              Figure 2: Derivation of AK and KDK from the PSK

2.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

Top      ToC       Page 15 
   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)

Next RFC Part