Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4764

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

Pages: 64
Experimental
Part 1 of 3 – Pages 1 to 15
None   None   Next

Top   ToC   RFC4764 - 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   ToC   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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   RFC4764 - 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 Section