<pre>Network Working Group                                         F. Bersani
Request for Comments: 4764                            France Telecom R&amp;D
Category: Experimental                                     H. Tschofenig
                                           Siemens Networks GmbH &amp; Co KG
                                                            January 2007


                         <span class="h1">The EAP-PSK Protocol:</span>
    <span class="h1">A Pre-Shared Key Extensible Authentication Protocol (EAP) Method</span>

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 <a href="./rfc3932">RFC 3932</a> 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.





<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Design Goals for EAP-PSK ...................................<a href="#page-4">4</a>
           <a href="#section-1.1.1">1.1.1</a>. Simplicity ..........................................<a href="#page-4">4</a>
           <a href="#section-1.1.2">1.1.2</a>. Wide Applicability ..................................<a href="#page-5">5</a>
           <a href="#section-1.1.3">1.1.3</a>. Security ............................................<a href="#page-5">5</a>
           <a href="#section-1.1.4">1.1.4</a>. Extensibility .......................................<a href="#page-5">5</a>
      <a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-5">5</a>
      <a href="#section-1.3">1.3</a>. Conventions ................................................<a href="#page-8">8</a>
      <a href="#section-1.4">1.4</a>. Related Work ...............................................<a href="#page-9">9</a>
   <a href="#section-2">2</a>. Protocol Overview ..............................................<a href="#page-12">12</a>
      <a href="#section-2.1">2.1</a>. EAP-PSK Key Hierarchy .....................................<a href="#page-13">13</a>
           <a href="#section-2.1.1">2.1.1</a>. The PSK ............................................<a href="#page-13">13</a>
           <a href="#section-2.1.2">2.1.2</a>. AK .................................................<a href="#page-14">14</a>
           <a href="#section-2.1.3">2.1.3</a>. KDK ................................................<a href="#page-14">14</a>
      <a href="#section-2.2">2.2</a>. The TEK ...................................................<a href="#page-15">15</a>
      <a href="#section-2.3">2.3</a>. The MSK ...................................................<a href="#page-15">15</a>
      <a href="#section-2.4">2.4</a>. The EMSK ..................................................<a href="#page-15">15</a>
      <a href="#section-2.5">2.5</a>. The IV ....................................................<a href="#page-15">15</a>
   <a href="#section-3">3</a>. Cryptographic Design of EAP-PSK ................................<a href="#page-15">15</a>
      <a href="#section-3.1">3.1</a>. The Key Setup .............................................<a href="#page-16">16</a>
      <a href="#section-3.2">3.2</a>. The Authenticated Key Exchange ............................<a href="#page-19">19</a>
      <a href="#section-3.3">3.3</a>. The Protected Channel .....................................<a href="#page-23">23</a>
   <a href="#section-4">4</a>. EAP-PSK Message Flows ..........................................<a href="#page-25">25</a>
      <a href="#section-4.1">4.1</a>. EAP-PSK Standard Authentication ...........................<a href="#page-26">26</a>
      <a href="#section-4.2">4.2</a>. EAP-PSK Extended Authentication ...........................<a href="#page-28">28</a>
   <a href="#section-5">5</a>. EAP-PSK Message Format .........................................<a href="#page-31">31</a>
      <a href="#section-5.1">5.1</a>. EAP-PSK First Message .....................................<a href="#page-32">32</a>
      <a href="#section-5.2">5.2</a>. EAP-PSK Second Message ....................................<a href="#page-34">34</a>
      <a href="#section-5.3">5.3</a>. EAP-PSK Third Message .....................................<a href="#page-36">36</a>
      <a href="#section-5.4">5.4</a>. EAP-PSK Fourth Message ....................................<a href="#page-39">39</a>
   <a href="#section-6">6</a>. Rules of Operation for the EAP-PSK Protected Channel ...........<a href="#page-41">41</a>
      <a href="#section-6.1">6.1</a>. Protected Result Indications ..............................<a href="#page-41">41</a>
           <a href="#section-6.1.1">6.1.1</a>. CONT ...............................................<a href="#page-42">42</a>
           <a href="#section-6.1.2">6.1.2</a>. DONE_SUCCESS .......................................<a href="#page-43">43</a>
           <a href="#section-6.1.3">6.1.3</a>. DONE_FAILURE .......................................<a href="#page-43">43</a>
      <a href="#section-6.2">6.2</a>. Extended Authentication ...................................<a href="#page-43">43</a>
   <a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-45">45</a>
      <a href="#section-7.1">7.1</a>. Allocation of an EAP-Request/Response Type for EAP-PSK ....<a href="#page-45">45</a>
      <a href="#section-7.2">7.2</a>. Allocation of EXT Type Numbers ............................<a href="#page-45">45</a>
   <a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-46">46</a>
      <a href="#section-8.1">8.1</a>. Mutual Authentication .....................................<a href="#page-46">46</a>
      <a href="#section-8.2">8.2</a>. Protected Result Indications ..............................<a href="#page-47">47</a>
      <a href="#section-8.3">8.3</a>. Integrity Protection ......................................<a href="#page-48">48</a>
      <a href="#section-8.4">8.4</a>. Replay Protection .........................................<a href="#page-48">48</a>
      <a href="#section-8.5">8.5</a>. Reflection Attacks ........................................<a href="#page-48">48</a>
      <a href="#section-8.6">8.6</a>. Dictionary Attacks ........................................<a href="#page-49">49</a>



<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


      <a href="#section-8.7">8.7</a>. Key Derivation ............................................<a href="#page-49">49</a>
      <a href="#section-8.8">8.8</a>. Denial-of-Service Resistance ..............................<a href="#page-51">51</a>
      <a href="#section-8.9">8.9</a>. Session Independence ......................................<a href="#page-51">51</a>
      <a href="#section-8.10">8.10</a>. Exposition of the PSK ....................................<a href="#page-52">52</a>
      <a href="#section-8.11">8.11</a>. Fragmentation ............................................<a href="#page-52">52</a>
      <a href="#section-8.12">8.12</a>. Channel Binding ..........................................<a href="#page-53">53</a>
      <a href="#section-8.13">8.13</a>. Fast Reconnect ...........................................<a href="#page-53">53</a>
      <a href="#section-8.14">8.14</a>. Identity Protection ......................................<a href="#page-53">53</a>
      <a href="#section-8.15">8.15</a>. Protected Ciphersuite Negotiation ........................<a href="#page-55">55</a>
      <a href="#section-8.16">8.16</a>. Confidentiality ..........................................<a href="#page-55">55</a>
      <a href="#section-8.17">8.17</a>. Cryptographic Binding ....................................<a href="#page-55">55</a>
      <a href="#section-8.18">8.18</a>. Implementation of EAP-PSK ................................<a href="#page-55">55</a>
   <a href="#section-9">9</a>. Security Claims ................................................<a href="#page-56">56</a>
   <a href="#section-10">10</a>. Acknowledgments ...............................................<a href="#page-57">57</a>
   <a href="#section-11">11</a>. References ....................................................<a href="#page-57">57</a>
      <a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-57">57</a>
      <a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-58">58</a>
   <a href="#appendix-A">Appendix A</a>. Generation of the PSK from a Password - Discouraged ...<a href="#page-62">62</a>

































<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Design Goals for EAP-PSK</span>

   The Extensible Authentication Protocol (EAP) [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>] 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&amp;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) [<a href="#ref-48" title="&quot;Wi-Fi Protected Access, version 2.0&quot;">48</a>] 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 [<a href="#ref-27" title="&quot;Approved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems-LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security&quot;">27</a>],
      employ EAP in a different threat model than PPP [<a href="#ref-44" title="&quot;The Point-to-Point Protocol (PPP)&quot;">44</a>] 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 [<a href="#ref-28" title="&quot;Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications&quot;">28</a>] wireless
      LANs.

   o  Security: EAP-PSK should be conservative in its cryptographic
      design.

   o  Extensibility: EAP-PSK should be easily extensible.

<span class="h4"><a class="selflink" id="section-1.1.1" href="#section-1.1.1">1.1.1</a>.  Simplicity</span>

   For the sake of simplicity, EAP-PSK relies on a single cryptographic
   primitive, AES-128 [<a href="#ref-7" title="&quot;Specification for the Advanced Encryption Standard (AES)&quot;">7</a>].

   Restriction to such a primitive, and in particular, not using
   asymmetric cryptography like Diffie-Hellman key exchange, makes EAP-
   PSK:





<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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 <a href="#section-8">Section 8</a>, 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.

<span class="h4"><a class="selflink" id="section-1.1.2" href="#section-1.1.2">1.1.2</a>.  Wide Applicability</span>

   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 [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

<span class="h4"><a class="selflink" id="section-1.1.3" href="#section-1.1.3">1.1.3</a>.  Security</span>

   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.

<span class="h4"><a class="selflink" id="section-1.1.4" href="#section-1.1.4">1.1.4</a>.  Extensibility</span>

   EAP-PSK explicitly provides a mechanism to allow future extensions
   within its protected channel (see <a href="#section-3.3">Section 3.3</a>).  Thanks to this
   mechanism, EAP-PSK will be able to provide more sophisticated
   services as the need to do so arises.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Terminology</span>

   Authentication, Authorization, and Accounting (AAA)
             Please refer to [<a href="#ref-10" title="&quot;Criteria for Evaluating AAA Protocols for work Access&quot;">10</a>] for more details.

   AES-128   A block cipher specified in the Advanced Encryption
             Standard [<a href="#ref-7" title="&quot;Specification for the Advanced Encryption Standard (AES)&quot;">7</a>].

   Authentication Key (AK)
             A 16-byte key derived from the PSK that the EAP peer and
             server use to mutually authenticate.





<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   AKEP2     An authenticated key exchange protocol; please refer to
             [<a href="#ref-14" title="&quot;Entity Authentication and Key Distribution&quot;">14</a>] 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 [<a href="#ref-26" title="&quot;Local and Metropolitan Area Networks: Port-Based Network Access Control&quot;">26</a>], 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 [<a href="#ref-8" title="&quot;Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication&quot;">8</a>].

   Extensible Authentication Protocol (EAP)
             Defined in [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

   EAP Authenticator (or simply Authenticator)
             The end of the EAP link initiating the EAP authentication
             methods.  (This terminology is also used in [<a href="#ref-26" title="&quot;Local and Metropolitan Area Networks: Port-Based Network Access Control&quot;">26</a>], 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 [<a href="#ref-26" title="&quot;Local and Metropolitan Area Networks: Port-Based Network Access Control&quot;">26</a>], 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 [<a href="#ref-4" title="&quot;The EAX mode of operation&quot;">4</a>].

   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 [<a href="#ref-9" title="&quot;Extensible Authentication Protocol (EAP) Key Management Framework&quot;">9</a>] 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



<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


             methods such as EAP-TLS [<a href="#ref-11" title="&quot;PPP EAP TLS Authentication Protocol&quot;">11</a>], 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
             [<a href="#ref-9" title="&quot;Extensible Authentication Protocol (EAP) Key Management Framework&quot;">9</a>] 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
             [<a href="#ref-40" title="&quot;Handbook of Applied Cryptography&quot;">40</a>].  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 [<a href="#ref-9" title="&quot;Extensible Authentication Protocol (EAP) Key Management Framework&quot;">9</a>].
             EAP-PSK generates a 64-byte MSK.

   Network Access Identifier (NAI)
             Identifier used to identify the communicating parties [<a href="#ref-2" title="&quot;The Network Access Identifier&quot;">2</a>].

   One Key CBC-MAC 1 (OMAC1)
             A method to generate a Message Authentication Code [<a href="#ref-29" title="&quot;OMAC: One-Key CBC MAC&quot;">29</a>].
             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.






<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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 [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>] 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 [<a href="#ref-9" title="&quot;Extensible Authentication Protocol (EAP) Key Management Framework&quot;">9</a>].
             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.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Conventions</span>

   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 <a href="#section-3.2">Section 3.2</a>).

   [<a id="ref-String">String</a>] 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: [<a href="#ref-String">String</a>]=String||MAC(K,String)

   ** denotes integer exponentiation.





<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


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

   &lt;i&gt; 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 [<a href="#ref-1" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">1</a>].

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>.  Related Work</span>

   At the time this document is written, only three EAP methods are
   standards track EAP methods per IETF terminology (see [<a href="#ref-17" title="&quot;The Internet Standards Process -- Revision 3&quot;">17</a>]), namely:

   o  MD5-Challenge (EAP-Request/Response type 4), defined in [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>], which
      uses a MD5 challenge similar to [<a href="#ref-45" title="&quot;PPP Challenge Handshake Authentication Protocol (CHAP)&quot;">45</a>].

   o  OTP (EAP-Request/Response type 5), defined in [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>], which aims at
      providing One-Time Password support similar to [<a href="#ref-22" title="&quot;A One-Time Password System&quot;">22</a>] and [<a href="#ref-39" title="&quot;OTP Extended Responses&quot;">39</a>].

   o  GTC (EAP-Request/Response type 6), defined in [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>], which aims at
      providing Generic Token Card Support.

   Unfortunately, all three methods are deprecated for security reasons
   that are explained in part in [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

   Myriads of EAP methods have, however, been otherwise proposed:

   o  One as an experimental RFC (EAP-TLS [<a href="#ref-11" title="&quot;PPP EAP TLS Authentication Protocol&quot;">11</a>]), which therefore is not
      a standard (see [<a href="#ref-25" title="&quot;Not All RFCs are Standards&quot;">25</a>]).

   o  Some as individual Internet-Draft submissions (e.g., [<a href="#ref-42" title="&quot;The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)&quot;">42</a>] 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 [<a href="#ref-16" title="&quot;EAP shared key methods: a tentative synthesis of those proposed so far&quot;">16</a>] for a more thorough
   synthesis of EAP methods).




<span class="grey">Bersani &amp; Tschofenig          Experimental                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   Among these proposals, there are some that:

   o  Are broken from a security point of view, e.g.:

      *  LEAP, which is specified in [<a href="#ref-38" title="&quot;Cisco LEAP protocol description&quot;">38</a>] and whose vulnerabilities are
         discussed in [<a href="#ref-49" title="&quot;Weaknesses in LEAP Challenge/Response&quot;">49</a>].

      *  EAP-MSCHAPv2, which is specified in [<a href="#ref-34" title="&quot;Microsoft EAP CHAP Extensions&quot;">34</a>] and whose
         vulnerabilities are indirectly discussed in [<a href="#ref-43" title="&quot;Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)&quot;">43</a>].

   o  Essentially require additional infrastructure, e.g., EAP-SIM [<a href="#ref-24" title="&quot;Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)&quot;">24</a>],
      EAP-AKA [<a href="#ref-12" title="&quot;Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)&quot;">12</a>], or OTP/token card methods like [<a href="#ref-31" title="&quot;The EAP SecurID(r) Mechanism&quot;">31</a>].

   o  Are not shared key methods but are often confused with them,
      namely, the password methods, e.g., EAP-SRP [<a href="#ref-18" title="&quot;EAP SRP-SHA1 Authentication Protocol&quot;">18</a>] or SPEKE [<a href="#ref-30" title="&quot;The SPEKE Password-Based Key Agreement Methods&quot;">30</a>],
      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, [<a href="#ref-32" title="&quot;Protected EAP Protocol (PEAP) Version 2&quot;">32</a>] and
      [<a href="#ref-21" title="&quot;EAP Tunneled TLS Authentication Protocol (EAP-TTLS)&quot;">21</a>].

   o  Are abandoned but have provided the basis for EAP-PSK, namely,
      EAP-Archie [<a href="#ref-47" title="&quot;The EAP Archie Protocol&quot;">47</a>].

   o  Are possible alternatives to EAP-PSK (i.e., claimed to be secure
      and subject of active work):

      *  EAP-FAST [<a href="#ref-42" title="&quot;The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)&quot;">42</a>].

      *  EAP-IKEv2 [<a href="#ref-46" title="&quot;EAP IKEv2 Method&quot;">46</a>].

      *  EAP-TLS (when shared key/password support is added to TLS; see
         [<a href="#ref-50" title="&quot;Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)&quot;">50</a>]).

   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.



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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.








































<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Protocol Overview</span>

   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       |    |
   |    +--&gt;*******       |16 bytes| |               |            |    |
   |           |          +--------+ |               |            |    |
   |     +-----+----+                |               |            |    |
   |     v          v                |               |            |    |
   |+--------+ +-------------------+ |               |            |    |
   ||Tag     | |Cipher Text Payload| |               |            |    |
   ||16 bytes| | Variable length L | |               |            |    |
   |+--------+ +-------------------+ |               |            |    V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
                                     |               |                 ^
                                 +-+-+-+-+-++  +-+-+-+-+-++            |
                                 |MSK       |  |EMSK      |            |
                                 |          |  |          |   Exported |
                                 +-+-+-+-+-++  +-+-+-+-+-++     by EAP |



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


                                     |               |          Method |
                                     |               |                 |
                                     V               V                 |
                                 *************************             V
                                 *   AAA  Key Derivation *          ---+
                                 *   Naming &amp; Binding    *
                                 *************************

                 Figure 1: EAP-PSK Key Hierarchy Overview

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  EAP-PSK Key Hierarchy</span>

   This section presents the key hierarchy used by EAP-PSK.  This
   hierarchy is inspired by the EAP key hierarchy described in [<a href="#ref-9" title="&quot;Extensible Authentication Protocol (EAP) Key Management Framework&quot;">9</a>].

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>.  The PSK</span>

   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 <a href="#section-3.1">Section 3.1</a> 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.












<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


                   +---------------------------+
                   |            PSK            |
                   |        (16 bytes)         |
                   +---------------------------+
                      |                     |
                      v                     v
   +---------------------------+     +---------------------------+
   |            AK             |     |            KDK            |
   |        (16 bytes)         |     |        (16 bytes)         |
   +---------------------------+     +---------------------------+

              Figure 2: Derivation of AK and KDK from the PSK

<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>.  AK</span>

   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 <a href="#section-3.1">Section 3.1</a>.
   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
   <a href="#section-2.1.1">Section 2.1.1</a>.

   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 <a href="#section-4.1">Section 4.1</a>) and the EAP peer NAI it chooses to include in
   the second EAP-PSK message (namely, ID_P; see <a href="#section-4.1">Section 4.1</a>).

<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>.  KDK</span>

   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 <a href="#section-3.1">Section 3.1</a>.
   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





<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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
   <a href="#section-2.1.1">Section 2.1.1</a>.

   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 <a href="#section-4.1">Section 4.1</a>) and the EAP peer NAI it chooses to include in
   the second EAP-PSK message (namely, ID_P; see <a href="#section-4.1">Section 4.1</a>).

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  The TEK</span>

   EAP-PSK derives a 16-byte TEK thanks to a random number exchanged
   during authentication (RAND_P; see <a href="#section-5.1">Section 5.1</a>) and KDK.

   This TEK is used to implement a protected channel for both mutually
   authenticated parties to communicate over securely.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  The MSK</span>

   EAP-PSK derives a MSK thanks to a random number exchanged during
   authentication (RAND_P; see <a href="#section-5.1">Section 5.1</a>) and the KDK.

   The MSK is 64 bytes long, which complies with [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  The EMSK</span>

   EAP-PSK derives an EMSK thanks to a random number exchanged during
   authentication (RAND_P; see <a href="#section-5.1">Section 5.1</a>) and the KDK.

   The EMSK is 64 bytes long, which complies with [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  The IV</span>

   EAP-PSK does not derive any IV, which complies with [<a href="#ref-9" title="&quot;Extensible Authentication Protocol (EAP) Key Management Framework&quot;">9</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Cryptographic Design of EAP-PSK</span>

   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 [<a href="#ref-7" title="&quot;Specification for the Advanced Encryption Standard (AES)&quot;">7</a>].

   AES-128 has been chosen because:

   o  It is standardized and implementations are widely available.





<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   o  It has been carefully reviewed by the cryptographic community and
      is believed to be secure.

   Other block ciphers could easily be proposed for EAP-PSK, as EAP-PSK
   does not intrinsically 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 the case that 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 [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>], this
   should not be a problem.  The use of a different EAP-Request/Response
   Type number for EAP-PSK' will prevent this new method from being
   vulnerable to chosen protocol attacks.

   EAP-PSK uses three cryptographic parts:

   o  A key setup to derive AK and KDK from the PSK.

   o  An authenticated key exchange protocol to mutually authenticate
      the communicating parties and derive session keys.

   o  A protected channel protocol for both mutually authenticated
      parties to communicate over.

   Each part is discussed in more detail in the subsequent paragraphs.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  The Key Setup</span>

   EAP-PSK needs two cryptographically separated 16-byte subkeys for
   mutual authentication and session key derivation.  Indeed, it is a
   rule of 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 way, the latter option was chosen.





<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   Hence, the PSK is only used by EAP-PSK to derive AK and KDK.  This
   derivation should be done only once, immediately after the PSK has
   been provisioned.  As soon as AK and KDK have been derived, the PSK
   should be deleted.  If the PSK is deleted, it should be done so
   securely (see, for instance, [<a href="#ref-19" title="&quot;National Industrial Security Program Operating Manual&quot;">19</a>] for guidance on secure deletion of
   the PSK).

   Derivation of AK and KDK from the PSK is called the key setup:

   o  The input to the key setup is the PSK.

   o  The outputs of the key setup are AK and KDK.

   AK and KDK are derived from the PSK using the modified counter mode
   of 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&gt;=2.  This mode was chosen for the key
   setup because it had already been chosen for the derivation of the
   session keys (see <a href="#section-3.2">Section 3.2</a>).

   The details of the derivation of AK and KDK from the PSK are shown in
   Figure 3.





























<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   +--------------------------+
   |            "0"           |
   |  Input Block (16 bytes)  |
   +--------------------------+
                 |
                 v
        +----------------+
        |                |
        | AES-128(PSK,.) |
        |                |
        +----------------+
                 |
                 |
                 +----------------------------+
                 |                            |
                 v                            v
   +--------+  +---+            +--------+  +---+
   | c1="1" |-&gt;|XOR|            | c2="2" |-&gt;|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.







<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  The Authenticated Key Exchange</span>

   The authentication protocol used by EAP-PSK is inspired by AKEP2,
   which is described in [<a href="#ref-14" title="&quot;Entity Authentication and Key Distribution&quot;">14</a>].

   AKEP2 consists of a one-and-a-half round-trip exchange, as shown in
   Figure 4, which is inspired by Figure 5 of [<a href="#ref-14" title="&quot;Entity Authentication and Key Distribution&quot;">14</a>].

   Bob                                                       Alice
    |                            RA                            |
    |&lt;---------------------------------------------------------|
    |                                                          |
    |                     [B||A||RA||RB]                       |
    |---------------------------------------------------------&gt;|
    |                                                          |
    |                        [A||RB]                           |
    |&lt;---------------------------------------------------------|

                        Figure 4: Overview of AKEP2

   It is also worth noting that [<a href="#ref-14" title="&quot;Entity Authentication and Key Distribution&quot;">14</a>] focuses on cryptography and not on
   designing a real-life protocol.  Thus, as noted in subsection "Out-
   Of-Band-Data" of [<a href="#ref-14" title="&quot;Entity Authentication and Key Distribution&quot;">14</a>], Alice has to send A, its identity, to Bob so
   that Bob may select the appropriate credential for the sequel to the
   conversation.  This leads to a slightly complemented version of AKEP2
   for EAP-PSK as depicted in Figure 5.

   Bob                                                       Alice
    |                         A||RA                            |
    |&lt;---------------------------------------------------------|
    |                                                          |
    |                     [B||A||RA||RB]                       |
    |---------------------------------------------------------&gt;|
    |                                                          |
    |                        [A||RB]                           |
    |&lt;---------------------------------------------------------|

                        Figure 5: Overview of AKEP2

   In AKEP2,

   o  RA and RB are random numbers chosen respectively by Alice and Bob.

   o  A and B are Alice's and Bob's respective identities.  They allow
      Alice and Bob to retrieve the key that they have to use to run an
      authenticated key exchange between each other.  They are also
      included in the protocol for cryptographic reasons.




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   o  The MACs (see <a href="#section-1.3">Section 1.3</a> for the notation "[]") are calculated
      using a dedicated key.

   EAP-PSK instantiates this protocol with:

   o  The server as Alice and the peer as Bob.

   o  RA and RB as 16-byte random numbers, using <a href="#section-4.1">Section 4.1</a> notations;
      this means RA=RAND_S and RB=RAND_P.

   o  A and B as Alice's and Bob's respective NAIs, using <a href="#section-4.1">Section 4.1</a>
      notations; this means A=ID_S and B=ID_P.

   o  The MAC algorithm as CMAC with AES-128 using AK and producing a
      tag length of 16 bytes.

   o  The modified counter mode of operation of AES-128 using KDK, to
      derive session keys as a result of this exchange.

   CMAC was chosen as the MAC algorithm because it is capable of
   handling arbitrary length messages, and its design is simple.  It
   also enjoys up-to-date review by the cryptographic community,
   especially using provable security concepts.  It has been recommended
   by the NIST.  For a detailed description of CMAC, please refer to
   [<a href="#ref-8" title="&quot;Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication&quot;">8</a>].

   In AKEP2, the key exchange is "implicit": the session keys are
   derived from RB.  In EAP-PSK, the session keys are thus derived from
   RAND_P by using KDK and the modified counter mode of operation of
   AES-128 described in [<a href="#ref-5" title="&quot;The Security of One-Block-to-Many Modes of Operation&quot;">5</a>].  This mode was chosen because it is a
   simple key derivation scheme 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&gt;=2.  The derivation of the session keys is shown in Figure 6.

















<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   +--------------------------+      +-------------------------------+
   |         RAND_P           |      |              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 6: Derivation of the Session Keys

   The input to the derivation of the session keys is RAND_P.

   The outputs of the derivation of the session keys are:

   o  The 16-byte TEK (the first output block).

   o  The 64-byte MSK (the concatenation of the second to fifth output
      blocks).

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

















<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


  +--------------------------+
  |         RAND_P           |
  |  Input Block (16 bytes)  |
  +--------------------------+
                |
                v
       +----------------+
       |                |
       | AES-128(KDK,.) |
       |                |
       +----------------+
                |
                |
                +---------------------+-- - - - - - - - - - --+
                |                     |                       |
                v                     v                       v
  +--------+  +---+     +--------+  +---+       +--------+  +---+
  | c1="1" |-&gt;|XOR|     | c2="2" |-&gt;|XOR|.......| c9="9" |-&gt;|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 7: 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 <a href="#section-8.10">Section 8.10</a> for further discussion).









<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  The Protected Channel</span>

   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 [<a href="#ref-4" title="&quot;The EAX mode of operation&quot;">4</a>].
   Figure 8 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 8: The Protected Channel

   This protected channel:

   o  Provides replay protection.

   o  Encrypts and authenticates a Plain Text Payload that becomes an
      Encrypted Payload.  The Plain Text Payload must not exceed 960
      bytes; see Sections <a href="#section-5.3">5.3</a>, <a href="#section-5.4">5.4</a>, and <a href="#section-8.11">8.11</a>.

   o  Only authenticates a Header that is thus sent in clear.

   EAX is instantiated with AES-128 as the underlying block cipher.

   AES-128 is keyed with the TEK.






<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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 &lt;0&gt; 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 &lt;2**32-2&gt;, it must not send any further message
   on this protected channel, which would cause to reusing the value 0.
   Either the conversation is finished after the server receives the
   EAP-PSK answer from the peer with N set to &lt;2**32-1&gt; 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 billion).

   The Header H consists of 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 [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>]) and seems to be existing
   practice at IETF (see, for instance, [<a href="#ref-35" title="&quot;IP Authentication Header&quot;">35</a>]).

   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.







<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   EAX was mainly chosen because:

   o  It strongly relies on OMAC in its design and OMAC1, a variant of
      OMAC, had already been chosen in EAP-PSK for the authentication
      part (please remember that OMAC1 and CMAC are analogous).

   o  Its design is simple.

   o  It enjoys a security proof.

   o  It is free of any Intellectual Property Rights claims.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  EAP-PSK Message Flows</span>

   EAP-PSK may consist of two different types of message flows:

   o  The "standard authentication", which is:

      *  Mandatory to implement.

      *  Fully specified in this document.

      *  The simpler type of message flow, which is expected to be used
         most frequently.

   o  The "extended authentication", which is:

      *  Optional to implement (i.e., there are no mandatory
         extensions).

      *  Partly specified in this document since it depends on
         extensions and none are currently specified, let alone in this
         document.

      *  The type of message flow that should be used when extensions of
         EAP-PSK are needed by more sophisticated usage scenarios and
         are available.

   EAP-PSK introduces the concept of a 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.

   In the first EAP-PSK message, the EAP server asserts its identity.
   Given that the EAP-Request/Identity and EAP-Response/Identity may not
   be assumed to have occurred prior to this sending and that the
   response included in EAP-Response/Identity (if this EAP Identity
   exchange takes place) may not contain the actual NAI the peer shall



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   use with EAP-PSK, this means that an EAP server implementing EAP-PSK
   must use the same EAP server NAI for all EAP-PSK dialogs with any EAP
   peer implementing EAP-PSK.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  EAP-PSK Standard Authentication</span>

   EAP-PSK standard authentication is comprised of four messages, i.e.,
   two round-trips; see Figure 9.

   peer                                                      server
    |                                    Flags||RAND_S||ID_S   |
    |&lt;---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||RAND_P||MAC_P||ID_P                     |
    |---------------------------------------------------------&gt;|
    |                                                          |
    |                     Flags||RAND_S||MAC_S||PCHANNEL_S_0   |
    |&lt;---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||PCHANNEL_P_1                            |
    |---------------------------------------------------------&gt;|
    |                                                          |

                 Figure 9: EAP-PSK Standard Authentication

   o  The first message is sent by the server to the peer to:

      *  Send a 16-byte random challenge (RAND_S).  RAND_S was called RA
         in <a href="#section-3.2">Section 3.2</a>

      *  State its identity (ID_S).  ID_S was denoted by A in
         <a href="#section-3.2">Section 3.2</a>.

   o  The second message is sent by the peer to the server to:

      *  Send another 16-byte random challenge (RAND_P).  RAND_P was
         called RB in <a href="#section-3.2">Section 3.2</a>

      *  State its identity (ID_P).  ID_P was denoted by B in
         <a href="#section-3.2">Section 3.2</a>.

      *  Authenticate to the server by proving that it is able to
         compute a particular MAC (MAC_P), which is a function of the
         two challenges and AK:
         MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)






<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   o  The third message is sent by the server to the peer to:

      *  Authenticate to the peer by proving that it is able to compute
         another MAC (MAC_S), which is a function of the peer's
         challenge and AK:
         MAC_S = CMAC-AES-128(AK, ID_S||RAND_P)

      *  Set up the protected channel (P_CHANNEL_S_0) to:

         +  Confirm that it has derived session keys (at least the TEK).

         +  Give a protected result indication of the authentication.

   o  The fourth message is sent by the peer to the server to finish the
      setup of the protected channel (P_CHANNEL_P_1) to:

      *  Confirm that it has derived session keys (at least the TEK).

      *  Give a protected result indication of the authentication.

   The PCHANNEL_S_0 and PCHANNEL_P_1 fields of the third and fourth EAP-
   PSK messages contain a MAC-computed thanks to TEK that protects the
   integrity of the messages.  For a detailed list of the fields of the
   messages that are integrity protected, please refer to <a href="#section-3.3">Section 3.3</a>.

   All EAP-PSK messages include a sort of header, which is comprised of
   two fields:

   o  Flags, a 1-byte field that is currently only used to number EAP-
      PSK messages.

   o  RAND_S, a 16-byte challenge sent by the server that is used as a
      session identifier.

   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 [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>], 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.




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   When a party receives an EAP-PSK message, it checks that the message
   is syntactically valid in accordance with the message formats defined
   in <a href="#section-5">Section 5</a>.  If the message is syntactically incorrect, then it is
   silently discarded.  Then it checks the cryptographic validity of
   this message, i.e., it checks the MAC(s) as follows:

   o  If the received message is the first EAP-PSK message, there is no
      MAC to check as none is included in message 1.

   o  If the received message is the second EAP-PSK message, the
      validity of MAC_P is checked.

   o  If the received message is the third EAP-PSK message, the validity
      of MAC_S is checked and then the validity of the Tag included in
      P_CHANNEL_S_0 is checked.  The validity checks must be done in
      this order to avoid unnecessarily deriving TEK, MSK, and EMSK in
      case MAC_S is invalid, meaning that mutual authentication has
      failed.  Indeed, TEK is used to verify the validity of the Tag
      included in P_CHANNEL_S_0.

   o  If the received message is the fourth EAP-PSK message, the
      validity of the Tag included in P_CHANNEL_P_1 is checked.

   If a validity check fails, the message is silently discarded.  There
   can be a counter to track the number of silently discarded messages
   <a href="#section-8.8">Section 8.8</a>.  If there is an encrypted payload in the message
   (namely, in the PCHANNEL attribute), then the encrypted payload is
   decrypted.  Then, if the decrypted payload is syntactically
   incorrect, the message is silently discarded.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  EAP-PSK Extended Authentication</span>

   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 10 presents the message sequence for EAP-PSK extended
   authentication.

   Extended authentication MUST be supported, i.e., any EAP-PSK
   implementation MUST support sending and reception of an EXT attribute
   according to rules of operation described in <a href="#section-6">Section 6</a>.  Yet,
   although support of the EXT field is mandatory, there is no mandatory
   extension type to support.  This means that if a server engages in
   EAP-PSK extended authentication, as only the server can start
   extended authentication per <a href="#section-6">Section 6</a>, a peer will recognize the
   attempt to start extended authentication through its EXT support.  If



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   the peer does not support the particular extension type used by the
   server, the peer will still be able to conclude the EAP-PSK dialog.

   The mandatory support of the EXT field is dictated:

   o  To guarantee a robust behavior in the future where some peers
      might support some extensions and others not.  All peers will thus
      be able to understand that an extended authentication is being
      attempted and indicate whether or not they support the extension
      that is tried.

   o  To ensure that all implementations will indeed be extensible.

   No extension is currently defined.

   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   |
    |&lt;---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||RAND_P||MAC_P||ID_P                     |
    |---------------------------------------------------------&gt;|
    |                                                          |
    |                Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT)   |
    |&lt;---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||PCHANNEL_P_1(EXT)                       |
    |---------------------------------------------------------&gt;|
    |                                                          |
    .                                                          .
    .                                                          .
    .                                                          .
    |                       Flags||RAND_S||PCHANNEL_S_2i(EXT)  |
    |&lt;---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||PCHANNEL_P_2i+1(EXT)                    |
    |---------------------------------------------------------&gt;|
    |                                                          |

                Figure 10: EAP-PSK Extended Authentication




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   Please refer to <a href="#section-6">Section 6</a> for more details on how extended
   authentication works.

   The PCHANNEL_S_2j and PCHANNEL_P_2j+1 fields of the EAP-PSK messages
   (where j varies from 0 to i) contain a MAC-computed thanks to TEK
   that protects the integrity of the messages.  For a detailed list of
   the fields of the messages that are integrity protected, please refer
   to <a href="#section-3.3">Section 3.3</a>.

   When a party receives an EAP-PSK message, it checks that the message
   is syntactically valid in accordance with the message formats defined
   in <a href="#section-5">Section 5</a>.  If the message is syntactically incorrect, then it is
   silently discarded.  Then it checks the cryptographic validity of
   this message, i.e., it checks the MAC(s) as follows:

   o  If the received message is the first EAP-PSK message, there is no
      MAC to check as none is included in message 1.

   o  If the received message is the second EAP-PSK message, the
      validity of MAC_P is checked.

   o  If the received message is the third EAP-PSK message, the validity
      of MAC_S is checked and then the validity of the Tag included in
      P_CHANNEL_S_0 is checked.  The validity checks must be done in
      this order to avoid unnecessarily deriving TEK, MSK, and EMSK in
      case MAC_S is invalid, meaning that mutual authentication has
      failed.  Indeed, TEK is used to verify the validity of the Tag
      included in P_CHANNEL_S_0.

   o  If the received message is the fourth EAP-PSK message, the
      validity of the Tag included in P_CHANNEL_P_1 is checked.

   o  If the received message is an EAP-PSK message different from the
      first four ones, then validity of the Tag included in P_CHANNEL is
      checked.

   If a validity check fails, the message is silently discarded.  There
   can be a counter to track the number of silently discarded messages
   <a href="#section-8.8">Section 8.8</a>.  If there is an encrypted payload in the message (namely
   in the PCHANNEL attribute), then the encrypted payload is decrypted.
   Then, if the decrypted payload is syntactically incorrect, the
   message is silently discarded.









<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  EAP-PSK Message Format</span>

   For the sake of simplicity, EAP-PSK uses a fixed message format.
   There are four different types of EAP-PSK messages:

   o  The first EAP-PSK message, which is sent by the server to the
      peer.

   o  The second EAP-PSK message, which is sent by the peer to the
      server.

   o  The third EAP-PSK message, which is sent by the server to the
      peer.

   o  The fourth EAP-PSK message, which is sent by the peer to the
      server.  This is also the type of message that the peer further
      sends to the server in case of an extended authentication.  This
      is also essentially the type of message that the server further
      sends to the peer in case of an extended authentication: the only
      slight modification that occurs in this last case is the setting
      of the EAP Code to 1 instead of 2 in the other cases.

   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) is
   depicted in Figures 11, 13, 14, and 18.


























<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  EAP-PSK First Message</span>

   The first EAP-PSK message is sent by the server to the peer.  It has
   the format presented in Figure 11.

   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 11: EAP-PSK First Message

   Since IANA has allocated EAP method type 47 for EAP-PSK, Type EAP-PSK
   for the first EAP-PSK message as well as any other EAP-PSK message
   MUST be 47.

   The first EAP-PSK message consists of:

   o  A 1-byte Flags field

   o  A 16-byte random number: RAND_S

   o  A variable length field that conveys the server's NAI: ID_S. The
      length of this field is deduced from the EAP length field.  The
      length of this NAI must not exceed 966 bytes.  This restriction
      aims at avoiding fragmentation issues (see <a href="#section-8.11">Section 8.11</a>).

   The Flags field has the format presented in Figure 12.






<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   0
   0 1 2 3 4 5 6 7 8
   +-+-+-+-+-+-+-+-+
   | T | Reserved  |
   +-+-+-+-+-+-+-+-+

                      Figure 12: EAP-PSK Flags Field

   The Flags field is comprised of two subfields:

   o  A 2-bit T subfield, which indicates the type of EAP-PSK message:

      *  T=0 for the first EAP-PSK message presented in <a href="#section-5.1">Section 5.1</a>.

      *  T=1 for the second EAP-PSK message presented in <a href="#section-5.2">Section 5.2</a>.

      *  T=2 for the third EAP-PSK message presented in <a href="#section-5.3">Section 5.3</a>.

      *  T=3 for the fourth EAP-PSK message presented in <a href="#section-5.4">Section 5.4</a> and
         the subsequent EAP-PSK messages that may be exchanged during
         extended authentication.

   o  A 6-bit Reserved subfield that is set to zero on transmission and
      ignored on reception.

   The PCHANNEL Nonce field N (see <a href="#section-5.3">Section 5.3</a>) is used to distinguish
   between the different EAP-PSK messages that may be exchanged during
   extended authentication that all have T set to 3, i.e., the fourth
   EAP-PSK message and possibly the next ones.






















<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  EAP-PSK Second Message</span>

   The second EAP-PSK message is sent by the peer to the server.  It has
   the format presented in Figure 13.

   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 13: EAP-PSK Second Message








<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   It consists of:

   o  A 1-byte Flags field

   o  The 16-byte random number sent by the server in the first EAP-PSK
      message (RAND_S) that serves as a session identifier

   o  A 16-byte random number: RAND_P

   o  A 16-byte MAC: MAC_P

   o  A variable length field that conveys the peer's NAI: ID_P.  The
      length of this field is deduced from the EAP length field.  The
      length of this NAI must not exceed 966 bytes.  This restriction
      aims at avoiding fragmentation issues (see <a href="#section-8.11">Section 8.11</a>).

   The Flags field format is presented in Figure 12.


































<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  EAP-PSK Third Message</span>

   The third EAP-PSK message is sent by the server to the peer.  It has
   the format presented in Figure 14.

   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 14: EAP-PSK Third Message

   It consists of:

   o  A 1-byte Flags field

   o  The 16-byte random number sent by the server in the first EAP-PSK
      message (RAND_S) that is used as a session identifier

   o  A 16-byte MAC: MAC_S

   o  A variable length field that constitutes the protected channel:
      PCHANNEL



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   The Flags field format is presented in Figure 12.

   If there is no extension, i.e., if the authentication is standard,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see <a href="#section-3.3">Section 3.3</a>).

   o  A 16-byte Tag (see <a href="#section-3.3">Section 3.3</a>).

   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 0.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.

   R, E, and Reserved are sent encrypted by the protected channel (see
   <a href="#section-3.3">Section 3.3</a>).

   If there is no extension, PCHANNEL has the format presented in
   Figure 15 (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 15: The PCHANNEL Field with E=0

   If there is an extension, i.e., if the authentication is extended,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see <a href="#section-3.3">Section 3.3</a>).

   o  A 16-byte Tag (see <a href="#section-3.3">Section 3.3</a>).




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 1.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.

   o  A variable length EXT field.

   R, E, Reserved, and EXT are sent encrypted by the protected channel
   (see <a href="#section-3.3">Section 3.3</a>).

   If there is an extension, PCHANNEL has the format presented in
   Figure 16 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 16: The PCHANNEL Field with E=1

   This EXT field is split in two subfields:

   o  The EXT_Type subfield, which indicates the type of the extension

   o  The EXT_Payload subfield, which consists of the payload of the
      extension.  The EXT_Payload length is derived from the EAP Length
      field.  EXT_Payload must have a bit length that is a multiple of 8
      bits and must not exceed 960 bytes.  The latter restriction aims




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


      at avoiding fragmentation issues (see <a href="#section-8.11">Section 8.11</a>), whereas the
      former comes from the EAP length being specified in bytes.

   The format of the EXT field is presented in Figure 17.

   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 17: The EXT Field

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  EAP-PSK Fourth Message</span>

   The fourth EAP-PSK message is sent by the peer to the server.  It has
   the format presented in Figure 18.

   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 18: EAP-PSK Fourth Message




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   It consists of:

   o  A 1-byte Flags field

   o  The 16-byte random number sent by the server in the first EAP-PSK
      message (RAND_S) that is used as a session identifier

   o  A variable length field that constitutes the protected channel:
      PCHANNEL

   The Flags field format is presented in Figure 12.

   The PCHANNEL field has the following structure, which was already
   described in <a href="#section-5.3">Section 5.3</a>.

   If there is no extension, i.e., if the authentication is standard,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see <a href="#section-3.3">Section 3.3</a>).

   o  A 16-byte Tag (see <a href="#section-3.3">Section 3.3</a>).

   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 0.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.

   R, E, and Reserved are sent encrypted by the protected channel (see
   <a href="#section-3.3">Section 3.3</a>).

   If there is no extension, PCHANNEL has the format presented in
   Figure 15.

   If there is an extension, i.e., if the authentication is extended,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see <a href="#section-3.3">Section 3.3</a>).

   o  A 16-byte Tag (see <a href="#section-3.3">Section 3.3</a>).

   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 1.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   o  A variable length EXT field.

   R, E, Reserved, and EXT are sent encrypted by the protected channel
   (see <a href="#section-3.3">Section 3.3</a>).

   If there is an extension, PCHANNEL has the format presented in
   Figure 16.

   This EXT field is split in two subfields:

   o  The EXT_Type subfield, which indicates the type of the extension

   o  The EXT_Payload subfield, which consists of the payload of the
      extension.  The EXT_Payload length is derived from the EAP Length
      field.  EXT_Payload must have a bit length that is a multiple of 8
      bits and must not exceed 960 bytes.  The latter restriction aims
      at avoiding fragmentation issues (see <a href="#section-8.11">Section 8.11</a>).

   The format of the EXT field is presented in Figure 17.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Rules of Operation for the EAP-PSK Protected Channel</span>

   In this section, the rules of operation of the EAP-PSK protected
   channel are presented:

   o  How protected result indications are implemented.

   o  How an extended authentication works in details.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Protected Result Indications</span>

   The R flag of the PCHANNEL field in the third and fourth types of
   EAP-PSK messages is used to provide result indications.

   Since this 2-bit flag is communicated over the protected channel, it
   is:

   o  Encrypted so that only the peer and the server can know its value.

   o  Integrity-protected so that it cannot be modified by an attacker
      without the peer or the server detecting this modification.

   o  Protected against replays.

   This 2-bit R flag can take the following values:

   o  01 to mean CONT




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   o  10 to mean DONE_SUCCESS

   o  11 to mean DONE_FAILURE

   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 the case of a standard authentication, the following values of R
   should be exchanged:

   o  Either the server sends a DONE_SUCCESS in the PCHANNEL of the
      third EAP-PSK message, to which the peer replies with a
      DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK message, which
      successfully ends the EAP-PSK dialog.

   o  Or the server sends a DONE_FAILURE in the PCHANNEL of the third
      EAP-PSK message, to which the peer replies with a DONE_FAILURE in
      the PCHANNEL of the fourth EAP-PSK message, which unsuccessfully
      ends the EAP-PSK dialog.

   In the 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 that R may take are detailed
   below.

<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>.  CONT</span>

   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.






<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>.  DONE_SUCCESS</span>

   DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK
   dialog successful and therefore proposes to end this dialog.

   Once the server has sent a DONE_SUCCESS, it must keep sending this
   value for R.

   The peer must first receive a DONE_SUCCESS from the server before it
   is allowed to send a DONE_SUCCESS.

   After the peer has received a DONE_SUCCESS from the server, it may:

   o  Send a CONT to the server if it has not reached success on its
      side.  The server that receives a CONT should continue the EAP-PSK
      dialog (see <a href="#section-8.2">Section 8.2</a> for some discussion on the security
      implications of this).

   o  Send a DONE_SUCCESS to the server, which will end the EAP-PSK
      dialog with success.

   o  Send a DONE_FAILURE to the server, which will end the EAP-PSK
      dialog with failure.

<span class="h4"><a class="selflink" id="section-6.1.3" href="#section-6.1.3">6.1.3</a>.  DONE_FAILURE</span>

   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.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Extended Authentication</span>

   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.




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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 [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>]).

   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:

   o  End

      *  If the peer's policy mandates that it fails in the case of an
         unrecognized extension, it sends a DONE_FAILURE in the fourth
         EAP-PSK message.

      *  If the server has sent a DONE_SUCCESS in the third EAP-PSK
         message, and the peer's policy authorizes it to succeed even if
         the extension is not recognized, the peer sends a DONE_SUCCESS.

   o  Continue for exactly one round-trip; namely, in case the server
      has sent a CONT in the third EAP-PSK message and the peer's policy
      authorizes it to succeed even if the extension is not recognized,
      the peer replies with a CONT in the fourth EAP-PSK message.  The
      server must then, depending on its policy, send either a
      DONE_SUCCESS or a DONE_FAILURE to the peer in the fifth EAP-PSK
      message.  If the server sent a DONE_SUCCESS in the fifth EAP-PSK
      message, the peer must send a DONE_SUCCESS in the sixth EAP-PSK
      message.  All these messages must have the E flag set to 1 with an
      EXT field with the EXT_Type of the extension that was proposed and
      an empty EXT_Payload (this behavior was chosen to simplify
      implementations).

   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



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   flag set to 1 with an EXT field of the EXT_Type of the extension that
   was proposed and a non-empty EXT_Payload.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IANA Considerations</span>

   This section provides guidance to the IANA regarding registration of
   values related to the EAP-PSK protocol, in accordance with [<a href="#ref-6" title="">6</a>].

   The following terms are used here with the meanings defined in [<a href="#ref-6" title="">6</a>]:
   "name space" and "registration".

   The following policies are used here with the meanings defined in
   [<a href="#ref-6" title="">6</a>]: "Expert Review" and "Specification Required".

   This document introduces one new Internet Assigned Numbers Authority
   (IANA) consideration: there is one name space in EAP-PSK that
   requires registration: the EXT_Type values (see <a href="#section-5.3">Section 5.3</a> and
   <a href="#section-5.4">Section 5.4</a>).

   For registration requests where a Designated Expert should be
   consulted, the responsible IETF 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.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Allocation of an EAP-Request/Response Type for EAP-PSK</span>

   IANA allocated a new EAP Type for EAP-PSK.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Allocation of EXT Type Numbers</span>

   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.




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Security Considerations</span>

   [<a id="ref-3">3</a>] 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 [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Mutual Authentication</span>

   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 that inspired EAP-PSK, AKEP2, enjoys a
   security proof in the provable security paradigm; see [<a href="#ref-14" title="&quot;Entity Authentication and Key Distribution&quot;">14</a>].

   The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK,
   CMAC, also enjoys a security proof in the provable security paradigm;
   see [<a href="#ref-29" title="&quot;OMAC: One-Key CBC MAC&quot;">29</a>].  A tag length of 16 bytes for CMAC 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 mutual authentication if it is based on a pairwise
   PSK of sufficient strength.  If the PSK is not pairwise or not
   sufficiently strong, then it does not provide authentication.  In
   this way, EAP-PSK is no different than other authentication protocols
   based on Pre-Shared Keys.









<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Protected Result Indications</span>

   EAP-PSK provides protected result indications thanks to its 2-bit R
   flag (see <a href="#section-6.1">Section 6.1</a>).  This 2-bit R flag is protected because it is
   encrypted and integrity protected by the EAX mode of operation; see
   <a href="#section-3.3">Section 3.3</a>.

   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:

   o  A server sends a DONE_SUCCESS to a peer.

   o  The peer replies with a DONE_SUCCESS.

   In the case that 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., [<a href="#ref-23" title="&quot;Knowledge and common knowledge in a distributed environment&quot;">23</a>]) and in a sense
   unavoidable.  There is a trade-off between efficiency and the "level"
   of information sharing that is attainable.  EAP-PSK specified a
   single round-trip of DONE_SUCCESS because it is believed that:

   o  If there is an adversary capable of disrupting the communication
      channel, it can do so whenever it wants (be it after 1 or 10
      round-trips or even during data communication).

   o  Other layers/applications will generally start by doing a specific
      key exchange and confirmation procedure using the keys derived by
      EAP-PSK.  This is typically done by IEEE 802.11i "four-way
      handshake".  In case the error is not detected by EAP-PSK, it
      should be detected then (please note, however, that it is bad
      practice to rely on an external mechanism to ensure
      synchronization, unless this is an explicit property of the
      external mechanism).




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  Integrity Protection</span>

   EAP-PSK provides integrity protection thanks to the Tag of its
   protected channel (see <a href="#section-3.3">Section 3.3</a>).

   EAP-PSK provides integrity protection if it is based on a pairwise
   PSK of sufficient strength.  If the PSK is not pairwise or not
   sufficiently strong, then it does not provide authentication.  In
   this way, it is no different than other authentication protocols
   based on Pre-Shared Keys.

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  Replay Protection</span>

   EAP-PSK provides replay protection of its mutual authentication part
   thanks to the use of random numbers RAND_S and RAND_P.  Since RAND_S
   is 128 bits long, one expects to have to record 2**64 (i.e.,
   approximately 1.84*10**19) EAP-PSK successful authentications before
   an authentication can be replayed.  Hence, EAP-PSK provides replay
   protection of its mutual authentication part as long as RAND_S and
   RAND_P are chosen at random; randomness is critical for security.

   EAP-PSK provides replay protection during the conversation of the
   protected channel thanks to the Nonce N of its protected channel (see
   <a href="#section-3.3">Section 3.3</a>).  This nonce is initialized to 0 by the server and
   monotonically incremented by one by the party that receives a valid
   EAP-PSK message.  For instance, after receiving from the server a
   valid EAP-PSK message with Nonce set to x, the peer will answer with
   an EAP-PSK message with Nonce set to x+1 and wait for an EAP-PSK
   message with Nonce set to x+2.  A retransmission of the server's
   message with Nonce set to x would cause the peer EAP layer to resend
   the message in which Nonce was set to x+1, which would be transparent
   to the EAP-PSK layer.

   The EAP peer must check that the Nonce is indeed initialized to 0 by
   the server.

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>.  Reflection Attacks</span>

   EAP-PSK provides protection against reflection attacks in case of an
   extended authentication because:

   o  It integrity protects the EAP header (which contains the
      indication Request/Response.

   o  It includes two separate spaces for the Nonces: the EAP server
      only receives messages with odd nonces, whereas the EAP peer only
      receives messages with even nonces.




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>.  Dictionary Attacks</span>

   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 has:

   o  Ergonomic impacts: some people may find it cumbersome to manually
      provision a 16-byte PSK.

   o  Deployment impacts: some people may want to reuse existing
      credential databases that contain passwords and not PSKs.

   Because people will probably not heed the warning not to use
   passwords, guidance to derive a PSK from a password is provided in
   <a href="#appendix-A">Appendix A</a>.  The method proposed in <a href="#appendix-A">Appendix A</a> only tries to make
   dictionary attacks harder.  It does not eliminate them.

   However, it does not cause a fatal error if passwords are used
   instead of PSKs: people rarely use password-derived certificates, so
   why should they do so for shared keys?

<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>.  Key Derivation</span>

   EAP-PSK supports key derivation.

   The key hierarchy is specified in <a href="#section-2.1">Section 2.1</a>.

   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 [<a href="#ref-5" title="&quot;The Security of One-Block-to-Many Modes of Operation&quot;">5</a>] 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 <a href="#section-3.1">Section 3.1</a>).  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.






<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   A second key derivation occurs to derive session keys, namely, the
   TEK, MSK, and EMSK (see <a href="#section-3.2">Section 3.2</a>).  It uses KDK as the key to the
   modified counter mode.

   The protocol design explicitly assumes that neither AK nor KDK are
   shared beyond the two parties utilizing them.  AK loses its efficacy
   to mutually authenticate the peer and server with each other when it
   is shared.  Similarly, the derived TEK, MSK, and EMSK lose their
   value when KDK is shared with a third party.

   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 <a href="#section-2.1">Section 2.1</a>) takes a pre-specified value.

   It was chosen not to prevent this control of the session keys by the
   peer because:

   o  Preventing it would have added some complexity to the protocol
      (typically, the inclusion of a one-way mode of operation of AES in
      the key derivation part).

   o  It is believed that the peer won't try to force the server to use
      some pre-specified value for the session keys.  Such an attack is
      outside the threat model and seems to have little value compared
      to a peer sharing its PSK.

   However, this is not the behavior recommended by EAP in Section 7.10
   of [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

   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.









<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-8.8" href="#section-8.8">8.8</a>.  Denial-of-Service Resistance</span>

   Denial of Service (DoS) resistance 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.
   However, this should not lead to resource exhaustion as this state
   and the associated computation are fairly lightweight.

   Please note that both the peer and the server must commit to their
   RAND_S and RAND_P to protect their partners from flooding attacks.

   It is recommended that EAP-PSK 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 that would delay
   his or her 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).

   For the sake of simplicity and denial-of-service resilience, EAP-PSK
   has chosen not to include any error messages.  Hence, an "invalid"
   EAP-PSK message is silently discarded.  Although this makes
   interoperability testing and debugging harder, this leads to simpler
   implementations and does not open any venue for denial-of-service
   attacks.

<span class="h3"><a class="selflink" id="section-8.9" href="#section-8.9">8.9</a>.  Session Independence</span>

   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) do not enable compromise of subsequent or prior MSKs or EMSKs.




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   The assumption that RAND_P and RAND_S are random is central for the
   security of EAP-PSK in general and session independence in
   particular.

<span class="h3"><a class="selflink" id="section-8.10" href="#section-8.10">8.10</a>.  Exposition of the PSK</span>

   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, whose 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 thumb in cryptography to use different
   keys for different applications.

<span class="h3"><a class="selflink" id="section-8.11" href="#section-8.11">8.11</a>.  Fragmentation</span>

   EAP-PSK does not support fragmentation and reassembly.

   Indeed, the largest EAP-PSK frame is at most 1015 bytes long,
   because:

   o  The maximum length for the peer NAI identity used in EAP-PSK is
      966 bytes (see <a href="#section-5.2">Section 5.2</a>).  This should not be a limitation in
      practice (see Section 2.2 of [<a href="#ref-2" title="&quot;The Network Access Identifier&quot;">2</a>] for more considerations on NAI
      length).

   o  The maximum length for the EXT_Payload field used in EAP-PSK is
      960 bytes (see <a href="#section-5.3">Section 5.3</a> and <a href="#section-5.4">Section 5.4</a>).

   Per Section 3.1 of [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>], 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.



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h3"><a class="selflink" id="section-8.12" href="#section-8.12">8.12</a>.  Channel Binding</span>

   EAP-PSK does not provide channel binding as this feature is still
   very much a work in progress (see [<a href="#ref-13" title="&quot;Authenticated Service Information for the Extensible Authentication Protocol (EAP)&quot;">13</a>]).

   However, it should be easy to add it to EAP-PSK as an extension (see
   <a href="#section-4.2">Section 4.2</a>).

<span class="h3"><a class="selflink" id="section-8.13" href="#section-8.13">8.13</a>.  Fast Reconnect</span>

   EAP-PSK does not provide any fast reconnect capability.

   Indeed, as noted, for instance, in [<a href="#ref-15" title="&quot;Authenticated Key Exchange Secure Against Dictionary attacks&quot;">15</a>], 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).

<span class="h3"><a class="selflink" id="section-8.14" href="#section-8.14">8.14</a>.  Identity Protection</span>

   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 [<a href="#ref-37" title="&quot;SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols&quot;">37</a>].

   Identity protection basically means preventing the disclosure of the
   identities of the communicating parties over the network, which is
   quite contradictory to authentication.  There are two levels of
   identity protection: protection against passive attackers and
   protection against active eavesdroppers.

   As explained in [<a href="#ref-37" title="&quot;SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols&quot;">37</a>], "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)".

   If 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



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   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) to recover his "real-life" identity, i.e., John Doe.  An
   example drawback of this is when a competitor of John Doe's WISP
   wants to win John Doe as a new customer by sending him some special
   targeted advertisement.

   EAP-PSK can very simply thwart this attack, merely by avoiding to
   provide John Doe with an NAI that allows easy recovery of his real-
   life identity.  It is believed that when an NAI that is not
   correlated to a real-life identity is used, no valuable information
   leaks because of the EAP method.

   Indeed, the identity of the WISP used by a peer has to be disclosed
   anyway in the realm portion of its NAI to allow AAA routing.
   Moreover, the Medium Access Control Address of the peer's Network
   Interface Card can generally be used to track the peer as efficiently
   as a fixed NAI.








<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   It is worth noting that the server systematically discloses its
   identity, which may allow probing attacks.  This may not be a problem
   as the identity of the server is not supposed to remain secret.  On
   the contrary, users tend to want to know to whom they will be talking
   in order to choose the right network to attach to.

<span class="h3"><a class="selflink" id="section-8.15" href="#section-8.15">8.15</a>.  Protected Ciphersuite Negotiation</span>

   EAP-PSK does not allow negotiating ciphersuites.  Hence, it is not
   vulnerable to negotiation attacks and does not implement protected
   ciphersuite negotiation.

<span class="h3"><a class="selflink" id="section-8.16" href="#section-8.16">8.16</a>.  Confidentiality</span>

   Although EAP-PSK provides confidentiality in its protected channel,
   it cannot claim to do so as per Section 7.2.1 of [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>]: "A method
   making this claim must support identity protection".

<span class="h3"><a class="selflink" id="section-8.17" href="#section-8.17">8.17</a>.  Cryptographic Binding</span>

   Since EAP-PSK is not intended to be tunneled within another protocol
   that omits peer authentication, it does not implement cryptographic
   binding.

<span class="h3"><a class="selflink" id="section-8.18" href="#section-8.18">8.18</a>.  Implementation of EAP-PSK</span>

   To really provide security, not only must a protocol be well thought-
   out and correctly specified, but its implementation must take special
   care.

   For instance, implementing cryptographic algorithms requires special
   skills since cryptographic software is vulnerable not only to
   classical attacks (e.g., buffer overflow or missing checks) but also
   to some special cryptographic attacks (e.g., side channels attacks
   like timing ones; see [<a href="#ref-36" title="&quot;Timing Attacks on Implementations of Diffie- Hellman, RSA, DSS, and Other Systems&quot;">36</a>]).  In particular, care must be taken to
   avoid such attacks in EAX implementation; please refer to [<a href="#ref-4" title="&quot;The EAX mode of operation&quot;">4</a>] for a
   note on this point.

   An EAP-PSK implementation should use a good source of randomness to
   generate the random numbers required in the protocol.  Please refer
   to [<a href="#ref-20" title="&quot;Randomness Requirements for Security&quot;">20</a>] for more information on generating random numbers for
   security applications.

   Handling sensitive material (namely, keying material such as the PSK,
   AK, KDK, etc.) should be done in a secure way (see, for instance,
   [<a href="#ref-19" title="&quot;National Industrial Security Program Operating Manual&quot;">19</a>] for guidance on secure deletion).





<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   The specification of a repository for the PSK that EAP-PSK uses is
   outside the scope of this document.  In particular, nothing prevents
   one from storing this PSK on a tamper-resistant device such as a
   smart card rather than having it memorized or written down on a sheet
   of paper.  The choice of the PSK repository may have important
   security impacts.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Claims</span>

   This section provides the security claims required by [<a href="#ref-3" title="&quot;Extensible Authentication Protocol (EAP)&quot;">3</a>].

   [<a id="ref-a">a</a>]  Mechanism.  EAP-PSK is based on symmetric cryptography (AES-128)
        and uses a 16-byte Pre-Shared Key (PSK).

   [<a id="ref-b">b</a>]  Security claims.  EAP-PSK provides:

        *  Mutual authentication (see <a href="#section-8.1">Section 8.1</a>)

        *  Integrity protection (see <a href="#section-8.3">Section 8.3</a>)

        *  Replay protection (see <a href="#section-8.4">Section 8.4</a>)

        *  Key derivation (see <a href="#section-8.7">Section 8.7</a>)

        *  Dictionary attack resistance (see <a href="#section-8.6">Section 8.6</a>)

        *  Session independence (see <a href="#section-8.9">Section 8.9</a>)

   [<a id="ref-c">c</a>]  Key strength.  EAP-PSK provides a 16-byte effective key
        strength.

   [<a id="ref-d">d</a>]  Description of key hierarchy.  Please see <a href="#section-2.1">Section 2.1</a>.

   [<a id="ref-e">e</a>]  Indication of vulnerabilities.  EAP-PSK does not provide:

        *  Identity protection (see <a href="#section-8.14">Section 8.14</a>)

        *  Confidentiality (see <a href="#section-8.16">Section 8.16</a>)

        *  Fast reconnect (see <a href="#section-8.13">Section 8.13</a>)

        *  Fragmentation (see <a href="#section-8.11">Section 8.11</a>)

        *  Cryptographic binding (see <a href="#section-8.17">Section 8.17</a>)

        *  Protected ciphersuite negotiation (see <a href="#section-8.15">Section 8.15</a>)

        *  Perfect Forward Secrecy (see <a href="#section-8.10">Section 8.10</a>)



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


        *  Key agreement: the session key is chosen by the peer (see
           <a href="#section-8.7">Section 8.7</a>)

        *  Channel binding (see <a href="#section-8.12">Section 8.12</a>)

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Acknowledgments</span>

   This EAP method has been inspired by EAP-Archie and EAP-SIM.  Many
   thanks to their respective authors: Jesse Walker (extra thanks to
   Jesse Walker for his thorough and challenging expert review of EAP-
   PSK), Russ Housley, Henry Haverinen, and Joseph Salowey.

   Thanks to

   o  Henri Gilbert for some interesting discussions on the
      cryptographic parts of EAP-PSK.

   o  Aurelien Magniez for his valuable feedback on network aspects of
      EAP-PSK, his curiosity and rigor that led to numerous
      improvements, and his help in the first implementation of EAP-PSK
      under Microsoft Windows and Freeradius.

   o  Thomas Otto for his valuable feedback on EAP-PSK and the
      implementation of the first version of EAP-PSK under Xsupplicant.

   o  Nancy Cam-Winget for some exchanges on EAP-PSK.

   o  Jari Arkko and Bernard Aboba, the beloved EAP WG chairs, for the
      work they stimulate.

   Finally, thanks to Vir Z., who has brought a permanent and
   outstanding though discreet contribution to this protocol.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  References</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Normative References</span>

   [<a id="ref-1">1</a>]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-2">2</a>]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
         Access Identifier", <a href="./rfc4282">RFC 4282</a>, December 2005.

   [<a id="ref-3">3</a>]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)",
         <a href="./rfc3748">RFC 3748</a>, June 2004.





<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   [<a id="ref-4">4</a>]   Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of
         operation", FSE 04, Springer-Verlag LNCS 3017, 2004.

   [<a id="ref-5">5</a>]   Gilbert, H., "The Security of One-Block-to-Many Modes of
         Operation", FSE 03, Springer-Verlag LNCS 2287, 2003.

   [<a id="ref-6">6</a>]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>,
         October 1998.

   [<a id="ref-7">7</a>]   National Institute of Standards and Technology, "Specification
         for the Advanced Encryption Standard (AES)", Federal
         Information Processing Standards (FIPS) 197, November 2001.

   [<a id="ref-8">8</a>]   National Institute of Standards and Technology, "Recommendation
         for Block Cipher Modes of Operation: The CMAC Mode for
         Authentication", Special Publication (SP) 800-38B, May 2005.

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Informative References</span>

   [<a id="ref-9">9</a>]   Aboba, B., Simon, D., Eronen, P., and H. Levkowetz,"Extensible
         Authentication Protocol (EAP) Key Management Framework", Work
         in Progress, October 2006.

   [<a id="ref-10">10</a>]  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., Campell, E., Baba, S., and E.
         Jaques, "Criteria for Evaluating AAA Protocols for work
         Access", <a href="./rfc2989">RFC 2989</a>, November 2000.

   [<a id="ref-11">11</a>]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
         <a href="./rfc2716">RFC 2716</a>, October 1999.

   [<a id="ref-12">12</a>]  Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
         Method for 3rd Generation Authentication and Key Agreement
         (EAP-AKA)", <a href="./rfc4187">RFC 4187</a>, January 2006.

   [<a id="ref-13">13</a>]  Arkko, J. and P. Eronen, "Authenticated Service Information for
         the Extensible Authentication Protocol  (EAP)", Work in
         Progress, October 2005.

   [<a id="ref-14">14</a>]  Bellare, M. and P. Rogaway, "Entity Authentication and Key
         Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994.






<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   [<a id="ref-15">15</a>]  Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated
         Key Exchange Secure Against Dictionary attacks", EUROCRYPT 00,
         Springer-Verlag LNCS 1807, 2000.

   [<a id="ref-16">16</a>]  Bersani, F., "EAP shared key methods: a tentative synthesis of
         those proposed so far", Work in Progress, April 2004.

   [<a id="ref-17">17</a>]  Bradner, S., "The Internet Standards Process -- Revision 3",
         <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.

   [<a id="ref-18">18</a>]  Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1
         Authentication Protocol", Work in Progress, July 2001.

   [<a id="ref-19">19</a>]  Department of Defense of the United States, "National
         Industrial Security Program Operating Manual", DoD 5220-22M,
         January 1995.

   [<a id="ref-20">20</a>]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
         Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>, June 2005.

   [<a id="ref-21">21</a>]  Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
         Protocol (EAP-TTLS)", Work in Progress, July 2004.

   [<a id="ref-22">22</a>]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time
         Password System", <a href="./rfc2289">RFC 2289</a>, February 1998.

   [<a id="ref-23">23</a>]  Halpern, J. and Y. Moses, "Knowledge and common knowledge in a
         distributed environment", Journal of the ACM 37:3, 1990.

   [<a id="ref-24">24</a>]  Haverinen, H. and J. Salowey, "Extensible Authentication
         Protocol Method for Global System for Mobile Communications
         (GSM) Subscriber Identity Modules (EAP-SIM)", <a href="./rfc4186">RFC 4186</a>,
         January 2006.

   [<a id="ref-25">25</a>]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
         Standards", <a href="./rfc1796">RFC 1796</a>, April 1995.

   [<a id="ref-26">26</a>]  Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Port-Based Network Access Control",
         IEEE Standard 802.1X, September 2001.

   [<a id="ref-27">27</a>]  Institute of Electrical and Electronics Engineers, "Approved
         Draft Supplement to Standard for Telecommunications and
         Information Exchange Between Systems-LAN/MAN Specific
         Requirements - Part 11: Wireless LAN Medium Access Control
         (MAC) and Physical Layer (PHY) Specifications: Specification
         for Enhanced Security", IEEE 802.11i-2004, 2004.




<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 59]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-60" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   [<a id="ref-28">28</a>]  Institute of Electrical and Electronics Engineers, "Standard
         for Telecommunications and Information Exchange Between Systems
         - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium
         Access Control (MAC) and Physical Layer (PHY) Specifications",
         IEEE Standard 802.11, 1999.

   [<a id="ref-29">29</a>]  Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03,
         Springer-Verlag LNCS 2887, 2003.

   [<a id="ref-30">30</a>]  Jablon, D., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22The+SPEKE+Password-Based+Key+Agreement+Methods%22'>"The SPEKE Password-Based Key Agreement Methods"</a>,
         Work in Progress, November 2002.

   [<a id="ref-31">31</a>]  Josefsson, S., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22The+EAP+SecurID%28r%29+Mechanism%22'>"The EAP SecurID(r) Mechanism"</a>, Work in
         Progress, February 2002.

   [<a id="ref-32">32</a>]  Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected
         EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.

   [<a id="ref-33">33</a>]  Kaliski, B., "PKCS #5: Password-Based Cryptography
         Specification Version 2.0", <a href="./rfc2898">RFC 2898</a>, September 2000.

   [<a id="ref-34">34</a>]  Kamath, V. and A. Palekar, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Microsoft+EAP+CHAP+Extensions%22'>"Microsoft EAP CHAP Extensions"</a>,
         Work in Progress, April 2004.

   [<a id="ref-35">35</a>]  Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>, December 2005

   [<a id="ref-36">36</a>]  Kocher, P., "Timing Attacks on Implementations of Diffie-
         Hellman, RSA, DSS, and Other Systems", CRYPTO 96, Springer-
         Verlag LNCS 1109, 1996.

   [<a id="ref-37">37</a>]  Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
         Authenticated Diffie-Hellman and its Use in the IKE Protocols",
         CRYPTO 03, Springer-Verlag LNCS 2729, June 2003.

   [<a id="ref-38">38</a>]  MacNally, C., "Cisco LEAP protocol description",
         September 2001, available from
         &lt;<a href="http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt">http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt</a>&gt;.

   [<a id="ref-39">39</a>]  Metz, C., "OTP Extended Responses", <a href="./rfc2243">RFC 2243</a>, November 1997.

   [<a id="ref-40">40</a>]  Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of
         Applied Cryptography", CRC Press , 1996.

   [<a id="ref-41">41</a>]  National Institute of Standards and Technology, "Password
         Usage", Federal Information Processing Standards (FIPS) 112,
         May 1985.





<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 60]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-61" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   [<a id="ref-42">42</a>]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
         Flexible Authentication via Secure Tunneling Extensible
         Authentication Protocol Method (EAP-FAST)", Work in Progress,
         October 2006.

   [<a id="ref-43">43</a>]  Schneier, B., Mudge, and D. Wagner, "Cryptanalysis of
         Microsoft's PPTP Authentication Extensions (MS-CHAPv2)",
         CQRE 99, Springer-Verlag LNCS 1740, October 1999.

   [<a id="ref-44">44</a>]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
         <a href="./rfc1661">RFC 1661</a>, July 1994.

   [<a id="ref-45">45</a>]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
         (CHAP)", <a href="./rfc1994">RFC 1994</a>, August 1996.

   [<a id="ref-46">46</a>]  Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and
         F. Bersani, "EAP IKEv2 Method", Work in Progress, October 2006.

   [<a id="ref-47">47</a>]  Walker, J. and R. Housley, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22The+EAP+Archie+Protocol%22'>"The EAP Archie Protocol"</a>, Work in
         Progress, June 2003.

   [<a id="ref-48">48</a>]  Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0",
         April 2003.

   [<a id="ref-49">49</a>]  Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03,
         August 2003.

   [<a id="ref-50">50</a>]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
         Transport Layer Security (TLS)", <a href="./rfc4279">RFC 4279</a>, December 2005.






















<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 61]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-62" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Generation of the PSK from a Password - Discouraged</span>

   It is formally discouraged to use a password to generate the PSK,
   since this opens the door to exhaustive search or dictionary attacks,
   two attacks that would not otherwise be possible.

   EAP-PSK only provides a 16-byte key strength when a 16-byte PSK is
   drawn at random from the set of all possible 16-byte strings.

   However, as people will probably do this anyway, guidance is provided
   hereafter to generate the PSK from a password.

   For some hints on how passwords should be selected, please refer to
   [<a href="#ref-41" title="&quot;Password Usage&quot;">41</a>].

   The technique presented herein is drawn from [<a href="#ref-33" title="&quot;PKCS #5: Password-Based Cryptography Specification Version 2.0&quot;">33</a>].  It is intended to
   try to mitigate the risks associated with password usage in
   cryptography, typically dictionary attacks.

   If the binary representation of the password is strictly fewer than
   16 bytes long (which by the way means that the chosen password is
   probably weak because it is too short), then it is padded to 16 bytes
   with zeroes as its high-order bits.

   If the binary representation of the password is strictly more than 16
   bytes long, then it is hashed down to exactly 16 bytes using the
   Matyas-Meyer-Oseas hash (please refer to [<a href="#ref-40" title="&quot;Handbook of Applied Cryptography&quot;">40</a>] for a description of
   this hash.  Using the notation of Figure 9.3 of [<a href="#ref-40" title="&quot;Handbook of Applied Cryptography&quot;">40</a>], g is the
   identity function and E is AES-128 in our construction.) with
   IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been
   arbitrarily selected).

   We now assume that we have a 16-byte number derived from the initial
   password (that can be the password itself if its binary
   representation is exactly 16 bytes long).  We shall call this number
   P16.

   Following the notations used in [<a href="#ref-33" title="&quot;PKCS #5: Password-Based Cryptography Specification Version 2.0&quot;">33</a>], the PSK is derived thanks to
   PBKDF2 instantiated with:

   o  P16 as P

   o  The first 96 bits of the XOR of the peer and server NAIs as Salt
      (zero-padded in the high-order bits if necessary).

   o  5000 as c

   o  16 as dkLen



<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 62]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-63" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


   Although this gives better protection than nothing, this derivation
   does not stricto sensu protect against dictionary attacks.  It only
   makes dictionary precomputation harder.

Authors' Addresses

   Florent Bersani
   France Telecom R&amp;D
   38, rue du General Leclerc
   Issy-Les-Moulineaux  92794 Cedex 9
   FR

   EMail: bersani_florent@yahoo.fr


   Hannes Tschofenig
   Siemens Networks GmbH &amp; Co KG
   Otto-Hahn-Ring 6
   Munich  81739
   GE

   EMail: Hannes.Tschofenig@siemens.com





























<span class="grey">Bersani &amp; Tschofenig          Experimental                     [Page 63]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-64" ></span>
<span class="grey"><a href="./rfc4764">RFC 4764</a>                        EAP-PSK                     January 2007</span>


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and at www.rfc-editor.org/copyright.html, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Bersani &amp; Tschofenig          Experimental                     [Page 64]
</pre>