<pre>Internet Engineering Task Force (IETF)                        D. Harkins
Request for Comments: 5931                                Aruba Networks
Category: Informational                                          G. Zorn
ISSN: 2070-1721                                              Network Zen
                                                             August 2010


        <span class="h1">Extensible Authentication Protocol (EAP) Authentication</span>
                         <span class="h1">Using Only a Password</span>

Abstract

   This memo describes an Extensible Authentication Protocol (EAP)
   method, EAP-pwd, which uses a shared password for authentication.
   The password may be a low-entropy one and may be drawn from some set
   of possible passwords, like a dictionary, which is available to an
   attacker.  The underlying key exchange is resistant to active attack,
   passive attack, and dictionary attack.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc5931">http://www.rfc-editor.org/info/rfc5931</a>.

















<span class="grey">Harkins &amp; Zorn                Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
     <a href="#section-1.1">1.1</a>.  Background . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
     <a href="#section-1.2">1.2</a>.  Keyword Definitions  . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
     <a href="#section-1.3">1.3</a>.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
       <a href="#section-1.3.1">1.3.1</a>.  Resistance to Passive Attack . . . . . . . . . . . . .  <a href="#page-4">4</a>
       <a href="#section-1.3.2">1.3.2</a>.  Resistance to Active Attack  . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-1.3.3">1.3.3</a>.  Resistance to Dictionary Attack  . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-1.3.4">1.3.4</a>.  Forward Secrecy  . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
   <a href="#section-2">2</a>.  Specification of EAP-pwd . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-2.1">2.1</a>.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-2.2">2.2</a>.  Discrete Logarithm Cryptography  . . . . . . . . . . . . .  <a href="#page-7">7</a>
       <a href="#section-2.2.1">2.2.1</a>.  Finite Field Cryptography  . . . . . . . . . . . . . .  <a href="#page-7">7</a>
       <a href="#section-2.2.2">2.2.2</a>.  Elliptic Curve Cryptography  . . . . . . . . . . . . .  <a href="#page-8">8</a>
     <a href="#section-2.3">2.3</a>.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-9">9</a>
     <a href="#section-2.4">2.4</a>.  Instantiating the Random Function  . . . . . . . . . . . .  <a href="#page-9">9</a>
     <a href="#section-2.5">2.5</a>.  Key Derivation Function  . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-2.6">2.6</a>.  Random Numbers . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-2.7">2.7</a>.  Representation and Processing of Input Strings . . . . . . <a href="#page-11">11</a>
       <a href="#section-2.7.1">2.7.1</a>.  Identity Strings . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>



<span class="grey">Harkins &amp; Zorn                Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


       <a href="#section-2.7.2">2.7.2</a>.  Passwords  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
     <a href="#section-2.8">2.8</a>.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
       <a href="#section-2.8.1">2.8.1</a>.  Overview . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
       <a href="#section-2.8.2">2.8.2</a>.  Message Flows  . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
       <a href="#section-2.8.3">2.8.3</a>.  Fixing the Password Element  . . . . . . . . . . . . . <a href="#page-14">14</a>
         <a href="#section-2.8.3.1">2.8.3.1</a>.  ECC Operation for PWE  . . . . . . . . . . . . . . <a href="#page-15">15</a>
         <a href="#section-2.8.3.2">2.8.3.2</a>.  FFC Operation for pwe  . . . . . . . . . . . . . . <a href="#page-16">16</a>
       <a href="#section-2.8.4">2.8.4</a>.  Message Construction . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
         <a href="#section-2.8.4.1">2.8.4.1</a>.  ECC Groups . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
         <a href="#section-2.8.4.2">2.8.4.2</a>.  FFC Groups . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
       <a href="#section-2.8.5">2.8.5</a>.  Message Processing . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
         <a href="#section-2.8.5.1">2.8.5.1</a>.  EAP-pwd-ID Exchange  . . . . . . . . . . . . . . . <a href="#page-18">18</a>
         <a href="#section-2.8.5.2">2.8.5.2</a>.  EAP-pwd-Commit Exchange  . . . . . . . . . . . . . <a href="#page-20">20</a>
         <a href="#section-2.8.5.3">2.8.5.3</a>.  EAP-pwd-Confirm Exchange . . . . . . . . . . . . . <a href="#page-21">21</a>
     <a href="#section-2.9">2.9</a>.  Management of EAP-pwd Keys . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
     <a href="#section-2.10">2.10</a>. Mandatory-to-Implement Parameters  . . . . . . . . . . . . <a href="#page-23">23</a>
   <a href="#section-3">3</a>.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
     <a href="#section-3.1">3.1</a>.  EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
     <a href="#section-3.2">3.2</a>.  EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
       <a href="#section-3.2.1">3.2.1</a>.  EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
       <a href="#section-3.2.2">3.2.2</a>.  EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
       <a href="#section-3.2.3">3.2.3</a>.  EAP-pwd-Confirm  . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
     <a href="#section-3.3">3.3</a>.  Representation of Group Elements and Scalars . . . . . . . <a href="#page-27">27</a>
       <a href="#section-3.3.1">3.3.1</a>.  Elements in FFC Groups . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
       <a href="#section-3.3.2">3.3.2</a>.  Elements in ECC Groups . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
       <a href="#section-3.3.3">3.3.3</a>.  Scalars  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
   <a href="#section-4">4</a>.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
   <a href="#section-5">5</a>.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
   <a href="#section-6">6</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . . <a href="#page-31">31</a>
     <a href="#section-6.1">6.1</a>.  Resistance to Passive Attack . . . . . . . . . . . . . . . <a href="#page-31">31</a>
     <a href="#section-6.2">6.2</a>.  Resistance to Active Attack  . . . . . . . . . . . . . . . <a href="#page-31">31</a>
     <a href="#section-6.3">6.3</a>.  Resistance to Dictionary Attack  . . . . . . . . . . . . . <a href="#page-32">32</a>
     <a href="#section-6.4">6.4</a>.  Forward Secrecy  . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
     <a href="#section-6.5">6.5</a>.  Group Strength . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
     <a href="#section-6.6">6.6</a>.  Random Functions . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
   <a href="#section-7">7</a>.  Security Claims  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-35">35</a>
   <a href="#section-8">8</a>.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-37">37</a>
   <a href="#section-9">9</a>.  References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
     <a href="#section-9.1">9.1</a>.  Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
     <a href="#section-9.2">9.2</a>.  Informative References . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>











<span class="grey">Harkins &amp; Zorn                Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</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>.  Background</span>

   The predominant access method for the Internet today is that of a
   human using a username and password to authenticate to a computer
   enforcing access control.  Proof of knowledge of the password
   authenticates the human and computer.

   Typically these passwords are not stored on a user's computer for
   security reasons and must be entered each time the human desires
   network access.  Therefore, the passwords must be ones that can be
   repeatedly entered by a human with a low probability of error.  They
   will likely not possess high-entropy, and it may be assumed that an
   adversary with access to a dictionary will have the ability to guess
   a user's password.  It is therefore desirable to have a robust
   authentication method that is secure even when used with a weak
   password in the presence of a strong adversary.

   EAP-pwd is an EAP method that addresses the problem of password-based
   authenticated key exchange -- using a possibly weak password for
   authentication to derive an authenticated and cryptographically
   strong shared secret.  This problem was first described by Bellovin
   and Merritt in [<a href="#ref-BM92" title="&quot;Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attack&quot;">BM92</a>] and [<a href="#ref-BM93" title="&quot;Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against Dictionary Attacks and Password File Compromise&quot;">BM93</a>].  There have been a number of
   subsequent suggestions ([<a href="#ref-JAB96" title="&quot;Strong Password-Only Authenticated Key Exchange&quot;">JAB96</a>], [<a href="#ref-LUC97" title="&quot;Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys&quot;">LUC97</a>], [<a href="#ref-BMP00" title="&quot;Provably Secure Password Authenticated Key Exchange Using Diffie- Hellman&quot;">BMP00</a>], and others) for
   password-based authenticated key exchanges.

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

   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="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

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

   Any protocol that claims to solve the problem of password-
   authenticated key exchange must be resistant to active, passive, and
   dictionary attack and have the quality of forward secrecy.  These
   characteristics are discussed further in the following sections.

<span class="h4"><a class="selflink" id="section-1.3.1" href="#section-1.3.1">1.3.1</a>.  Resistance to Passive Attack</span>

   A passive, or benign, attacker is one that merely relays messages
   back and forth between the peer and server, faithfully, and without
   modification.  The contents of the messages are available for
   inspection, but that is all.  To achieve resistance to passive
   attack, such an attacker must not be able to obtain any information
   about the password or anything about the resulting shared secret from



<span class="grey">Harkins &amp; Zorn                Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   watching repeated runs of the protocol.  Even if a passive attacker
   is able to learn the password, she will not be able to determine any
   information about the resulting secret shared by the peer and server.

<span class="h4"><a class="selflink" id="section-1.3.2" href="#section-1.3.2">1.3.2</a>.  Resistance to Active Attack</span>

   An active attacker is able to modify, add, delete, and replay
   messages sent between protocol participants.  For this protocol to be
   resistant to active attack, the attacker must not be able to obtain
   any information about the password or the shared secret by using any
   of its capabilities.  In addition, the attacker must not be able to
   fool a protocol participant into thinking that the protocol completed
   successfully.

   It is always possible for an active attacker to deny delivery of a
   message critical in completing the exchange.  This is no different
   than dropping all messages and is not an attack against the protocol.

<span class="h4"><a class="selflink" id="section-1.3.3" href="#section-1.3.3">1.3.3</a>.  Resistance to Dictionary Attack</span>

   For this protocol to be resistant to dictionary attack, any advantage
   an adversary can gain must be directly related to the number of
   interactions she makes with an honest protocol participant and not
   through computation.  The adversary will not be able to obtain any
   information about the password except whether a single guess from a
   single protocol run is correct or incorrect.

<span class="h4"><a class="selflink" id="section-1.3.4" href="#section-1.3.4">1.3.4</a>.  Forward Secrecy</span>

   Compromise of the password must not provide any information about the
   secrets generated by earlier runs of the protocol.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Specification of EAP-pwd</span>

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

   The following notation is used in this memo:

   peer-ID
       The peer's identity, the peer NAI [<a href="./rfc4282" title="&quot;The Network Access Identifier&quot;">RFC4282</a>].

   server-ID
       A string that identifies the server to the peer.

   password
       The password shared between the peer and server.





<span class="grey">Harkins &amp; Zorn                Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   y = H(x)
       The binary string x is given to a function H, which produces a
       fixed-length output y.

   a | b
       The concatenation of string a with string b.

   [a]b
       A string consisting of the single bit "a" repeated "b" times.

   x mod y
       The remainder of division of x by y.  The result will be between
       0 and y.

   g^x mod p
       The multiplication of the value "g" with itself "x" times, modulo
       the value "p".

   inv(Q)
       The inverse of an element, Q, from a finite field.

   len(x)
       The length in bits of the string x.

   chop(x, y)
       The reduction of string x, being at least y bits in length, to y
       bits.

   PRF(x,y)
       A pseudo-random function that takes a key, x, and variable-length
       data, y, and produces a fixed-length output that cannot be
       distinguished (with a significant advantage) from a random
       source.

   LSB(x)
       Returns the least-significant bit of the bitstring "x".

   Ciphersuite
       An encoding of a group to use with EAP-pwd, the definition of
       function H, and a PRF, in that order.

   MK
       The Master Key is generated by EAP-pwd.  This is a high-entropy
       secret whose length depends on the random function used.







<span class="grey">Harkins &amp; Zorn                Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   MSK
       The Master Session Key exported by EAP-pwd.  This is a high-
       entropy secret 512 bits in length.

   EMSK
       The Extended Master Session Key exported by EAP-pwd.  This is a
       high-entropy secret 512 bits in length.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Discrete Logarithm Cryptography</span>

   This protocol uses discrete logarithm cryptography to achieve
   authentication and key agreement (see [<a href="#ref-SP800-56A" title="&quot;Recommendations for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography&quot;">SP800-56A</a>]).  Each party to
   the exchange derives ephemeral keys with respect to a particular set
   of domain parameters (referred to here as a "group").  A group can be
   based on Finite Field Cryptography (FFC) or Elliptic Curve
   Cryptography (ECC).

<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>.  Finite Field Cryptography</span>

   Domain parameters for the FFC groups used by EAP-pwd include:

   o  A prime, p, determining a prime field GF(p), the integers modulo
      p.  The FFC group will be a subgroup of GF(p)*, the multiplicative
      group of non-zero elements in GF(p).  The group operation for FFC
      groups is multiplication modulo p.

   o  An element, G, in GF(p)* which serves as a generator for the FFC
      group.  G is chosen such that its multiplicative order is a
      sufficiently large prime divisor of ((p-1)/2).

   o  A prime, r, which is the multiplicative order of G, and thus also
      the size of the cryptographic subgroup of GF(p)* that is generated
      by G.

   An integer scalar, x, acts on an FFC group element, Y, via
   exponentiation modulo p -- Y^x mod p.

   The inverse function for an FFC group is defined such that the
   product of an element and its inverse modulo the group prime equals
   one (1).  In other words,

       (q * inv(q)) mod p = 1

   EAP-pwd uses an IANA registry for the definition of groups.  Some FFC
   groups in this registry are based on safe primes and the order is not
   included in the domain parameters.  In this case only, the order, r,
   MUST be computed as the prime minus one divided by two -- (p-1)/2.
   If the definition of the group includes an order in its domain



<span class="grey">Harkins &amp; Zorn                Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   parameters, that value MUST be used in this exchange when an order is
   called for.  If an FFC group definition does not have an order in its
   domain parameters and it is not based on a safe prime, it MUST NOT be
   used with EAP-pwd.

<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>.  Elliptic Curve Cryptography</span>

   Domain parameters for the ECC groups used by EAP-pwd include:

   o  A prime, p, determining a prime field GF(p).  The cryptographic
      group will be a subgroup of the full elliptic curve group that
      consists of points on an elliptic curve -- elements from GF(p)
      that satisfy the curve's equation -- together with the "point at
      infinity" that serves as the identity element.  The group
      operation for ECC groups is addition of points on the elliptic
      curve.

   o  Elements a and b from GF(p) that define the curve's equation.  The
      point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only
      if (y^2 - x^3 - a*x - b) mod p equals zero (0).

   o  A point, G, on the elliptic curve, which serves as a generator for
      the ECC group.  G is chosen such that its order, with respect to
      elliptic curve addition, is a sufficiently large prime.

   o  A prime, r, which is the order of G, and thus is also the size of
      the cryptographic subgroup that is generated by G.

   o  A co-factor, f, defined by the requirement that the size of the
      full elliptic curve group (including the "point at infinity") is
      the product of f and r.

   An integer scalar, x, acts on an ECC group element, Y, via repetitive
   addition (Y is added to itself x times), also called point
   multiplication -- x * Y.

   The inverse function for an ECC group is defined such that the sum of
   an element and its inverse is the "point at infinity" (the identity
   for elliptic curve point addition).  In other words,

       Q + inv(Q) = "O"

   Only ECC groups over GF(p) can be used by EAP-pwd.  ECC groups over
   GF(2^m) SHALL NOT be used by EAP-pwd.  While such groups exist in the
   IANA registry used by EAP-pwd, their use in EAP-pwd is not defined.
   In addition, ECC groups with a co-factor greater than one (1) SHALL
   NOT be used by EAP-pwd.  At the time of publication, no such groups
   existed in the IANA registry used by EAP-pwd.



<span class="grey">Harkins &amp; Zorn                Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


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

   In order to see how the protocol addresses the requirements above
   (see <a href="#section-1.3">Section 1.3</a>), it is necessary to state some assumptions under
   which the protocol can be evaluated.  They are:

   1.  Function H maps a binary string of indeterminate length onto a
       fixed binary string that is x bits in length.

           H: {0,1}^* --&gt; {0,1}^x

   2.  Function H is a "random oracle" (see [<a href="#ref-RANDOR" title="&quot;Random Oracles are Practical: A Paradigm for Designing Efficient Protocols&quot;">RANDOR</a>]).  Given knowledge
       of the input to H, an adversary is unable to distinguish the
       output of H from a random data source.

   3.  Function H is a one-way function.  Given the output of H, it is
       computationally infeasible for an adversary to determine the
       input.

   4.  For any given input to function H, each of the 2^x possible
       outputs are equally probable.

   5.  The discrete logarithm problem for the chosen group is hard.
       That is, given g, p, and y = g^x mod p, it is computationally
       infeasible to determine x.  Similarly, for an ECC group given the
       curve definition, a generator G, and Y = x * G, it is
       computationally infeasible to determine x.

   6.  There exists a pool of passwords from which the password shared
       by the peer and server is drawn.  This pool can consist of words
       from a dictionary, for example.  Each password in this pool has
       an equal probability of being the shared password.  All potential
       attackers have access to this pool of passwords.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Instantiating the Random Function</span>

   The protocol described in this memo uses a random function, H.  As
   noted in <a href="#section-2.3">Section 2.3</a>, this is a "random oracle" as defined in
   [<a href="#ref-RANDOR" title="&quot;Random Oracles are Practical: A Paradigm for Designing Efficient Protocols&quot;">RANDOR</a>].  At first glance, one may view this as a hash function.  As
   noted in [<a href="#ref-RANDOR" title="&quot;Random Oracles are Practical: A Paradigm for Designing Efficient Protocols&quot;">RANDOR</a>], though, hash functions are too structured to be
   used directly as a random oracle.  But they can be used to
   instantiate the random oracle.

   The random function, H, in this memo is instantiated by HMAC-SHA256
   (see [<a href="./rfc4634" title="&quot;US Secure Hash Algorithms (SHA and HMAC-SHA)&quot;">RFC4634</a>]) with a key whose length is 32 octets and whose value
   is zero.  In other words,

       H(x) = HMAC-SHA-256([0]32, x)



<span class="grey">Harkins &amp; Zorn                Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


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

   The keys output by this protocol, MSK and EMSK, are each 512 bits in
   length.  The shared secret that results from the successful
   termination of this protocol is only 256 bits.  Therefore, it is
   necessary to stretch the shared secret using a key derivation
   function (KDF).

   The KDF used in this protocol has a counter-mode with feedback
   construction using a generic pseudo-random function (PRF), according
   to [<a href="#ref-SP800-108" title="&quot;Recommendations for Key Derivation Using Pseudorandom Functions&quot;">SP800-108</a>].  The specific value of the PRF is specified along
   with the random function and group when the server sends the first
   EAP-pwd packet to the peer.

   The KDF takes a key to stretch, a label to bind into the key, and an
   indication of the desired length of the output in bits.  It uses two
   internal variables, i and L, each of which is 16 bits in length and
   is represented in network order.  Algorithmically, it is:

                KDF(key, label, length) {
                  i = 1
                  L = length
                  K(1) = PRF(key, i | label | L)
                  res = K(1)
                  while (len(res) &lt; length)
                  do
                    i = i + 1
                    K(i) = PRF(key, K(i-1) | i | label | L)
                    res = res | K(i)
                  done
                  return chop(res, length)
                }

                     Figure 1: Key Derivation Function

<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>.  Random Numbers</span>

   The security of EAP-pwd relies upon each side, the peer and server,
   producing quality secret random numbers.  A poor random number chosen
   by either side in a single exchange can compromise the shared secret
   from that exchange and open up the possibility of dictionary attack.

   Producing quality random numbers without specialized hardware entails
   using a cryptographic mixing function (like a strong hash function)
   to distill entropy from multiple, uncorrelated sources of information
   and events.  A very good discussion of this can be found in
   [<a href="./rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>].




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>.  Representation and Processing of Input Strings</span>

<span class="h4"><a class="selflink" id="section-2.7.1" href="#section-2.7.1">2.7.1</a>.  Identity Strings</span>

   The strings representing the server identity and peer identity MUST
   follow the requirements of [<a href="./rfc4282" title="&quot;The Network Access Identifier&quot;">RFC4282</a>] for Network Access Identifiers.
   This ensures a canonical representation of identities by both ends of
   the conversation prior to their use in EAP-pwd.

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

   EAP-pwd requires passwords be input as binary strings.  For the
   protocol to successfully terminate, each side must produce identical
   binary strings from the password.  This imposes processing
   requirements on a password prior to its use.

   Three techniques for password pre-processing exist for EAP-pwd:

   o   None: The input password string SHALL be treated as an ASCII
       string or a hexadecimal string with no treatment or normalization
       performed.  The output SHALL be the binary representation of the
       input string.

   o   <a href="./rfc2759">RFC 2759</a>: The input password string SHALL be processed to produce
       the output PasswordHashHash, as defined in [<a href="./rfc2759" title="&quot;Microsoft PPP CHAP Extensions, Version 2&quot;">RFC2759</a>], including
       any approved errata to [<a href="./rfc2759" title="&quot;Microsoft PPP CHAP Extensions, Version 2&quot;">RFC2759</a>].  This technique is useful when
       the server does not have access to the plaintext password.

   o   SASLprep: The input password string is processed according to the
       rules of the [<a href="./rfc4013" title="&quot;SASLprep: Stringprep Profile for User Names and Passwords&quot;">RFC4013</a>] profile of [<a href="./rfc3454" title="&quot;Preparation of Internationalized Strings (&quot;">RFC3454</a>].  A password SHALL be
       considered a "stored string" per [<a href="./rfc3454" title="&quot;Preparation of Internationalized Strings (&quot;">RFC3454</a>], and unassigned code
       points are therefore prohibited.  The output SHALL be the binary
       representation of the processed UTF-8 character string.
       Prohibited output and unassigned codepoints encountered in
       SASLprep pre-processing SHALL cause a failure of pre-processing,
       and the output SHALL NOT be used with EAP-pwd.

   Changing a password is out of scope of EAP-pwd, but due to the
   ambiguities in the way internationalized character strings are
   handled, 1) it SHOULD be done using SASLprep to ensure a canonical
   representation of the new password is stored on the server, and 2)
   subsequent invocations of EAP-pwd SHOULD use SASLprep to ensure that
   the client generates an identical binary string from the input
   password.







<span class="grey">Harkins &amp; Zorn                Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


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

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

   EAP is a two-party protocol spoken between an EAP peer and an
   authenticator.  For scaling purposes, the functionality of the
   authenticator that speaks EAP is frequently broken out into a stand-
   alone EAP server.  In this case, the EAP peer communicates with an
   EAP server through the authenticator, with the authenticator merely
   being a passthrough.

   An EAP method defines the specific authentication protocol being used
   by EAP.  This memo defines a particular method and therefore defines
   the messages sent between the EAP server (or the "EAP server"
   functionality in an authenticator if it is not broken out) and the
   EAP peer for the purposes of authentication and key derivation.

<span class="h4"><a class="selflink" id="section-2.8.2" href="#section-2.8.2">2.8.2</a>.  Message Flows</span>

   EAP-pwd defines three message exchanges: an Identity exchange, a
   Commit exchange, and a Confirm exchange.  A successful authentication
   is shown in Figure 2.

   The peer and server use the Identity exchange to discover each
   other's identities and to agree upon a Ciphersuite to use in the
   subsequent exchanges; in addition, the EAP Server uses the EAP-pwd-
   ID/Request message to inform the client of any password pre-
   processing that may be required.  In the Commit exchange, the peer
   and server exchange information to generate a shared key and also to
   bind each other to a particular guess of the password.  In the
   Confirm exchange, the peer and server prove liveness and knowledge of
   the password by generating and verifying verification data.



















<span class="grey">Harkins &amp; Zorn                Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


           +--------+                                     +--------+
           |        |                  EAP-pwd-ID/Request |        |
           |  EAP   |&lt;------------------------------------|  EAP   |
           |  peer  |                                     | server |
           |        | EAP-pwd-ID/Response                 |        |
           |        |------------------------------------&gt;|        |
           |        |                                     |        |
           |        |              EAP-pwd-Commit/Request |        |
           |        |&lt;------------------------------------|        |
           |        |                                     |        |
           |        | EAP-pwd-Commit/Response             |        |
           |        |------------------------------------&gt;|        |
           |        |                                     |        |
           |        |             EAP-pwd-Confirm/Request |        |
           |        |&lt;------------------------------------|        |
           |        |                                     |        |
           |        | EAP-pwd-Confirm/Response            |        |
           |        |------------------------------------&gt;|        |
           |        |                                     |        |
           |        |          EAP-Success                |        |
           |        |&lt;------------------------------------|        |
           +--------+                                     +--------+

                  Figure 2: A Successful EAP-pwd Exchange

   The components of the EAP-pwd-* messages are as follows:

   EAP-pwd-ID/Request
       Ciphersuite, Token, Password Processing Method, Server_ID

   EAP-pwd-ID/Response
       Ciphersuite, Token, Password Processing Method, Peer_ID

   EAP-pwd-Commit/Request
       Scalar_S, Element_S

   EAP-pwd-Commit/Response
       Scalar_P, Element_P

   EAP-pwd-Confirm/Request
       Confirm_S

   EAP-pwd-Confirm/Response
       Confirm_P







<span class="grey">Harkins &amp; Zorn                Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


<span class="h4"><a class="selflink" id="section-2.8.3" href="#section-2.8.3">2.8.3</a>.  Fixing the Password Element</span>

   Once the EAP-pwd-ID exchange is completed, the peer and server use
   each other's identities and the agreed upon ciphersuite to fix an
   element in the negotiated group called the Password Element (PWE or
   pwe, for an element in an ECC group or an FFC group, respectively).
   The resulting element must be selected in a deterministic fashion
   using the password but must result in selection of an element that
   will not leak any information about the password to an attacker.
   From the point of view of an attacker who does not know the password,
   the Password Element will be a random element in the negotiated
   group.

   To properly fix the Password Element, both parties must have a common
   view of the string "password".  Therefore, if a password pre-
   processing algorithm was negotiated during the EAP-pwd-ID exchange,
   the client MUST perform the specified password pre-processing prior
   to fixing the Password Element.

   Fixing the Password Element involves an iterative hunting-and-pecking
   technique using the prime from the negotiated group's domain
   parameter set and an ECC- or FFC-specific operation depending on the
   negotiated group.

   First, an 8-bit counter is set to the value one (1).  Then, the
   agreed-upon random function is used to generate a password seed from
   the identities and the anti-clogging token from the EAP-pwd-ID
   exchange (see <a href="#section-2.8.5.1">Section 2.8.5.1</a>):

      pwd-seed = H(token | peer-ID | server-ID | password | counter)

   Then, the pwd-seed is expanded using the KDF from the agreed-upon
   Ciphersuite out to the length of the prime:

      pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))

   If the pwd-value is greater than or equal to the prime, p, the
   counter is incremented, and a new pwd-seed is generated and the
   hunting-and-pecking continues.  If pwd-value is less than the prime,
   p, it is passed to the group-specific operation which either returns
   the selected Password Element or fails.  If the group-specific
   operation fails, the counter is incremented, a new pwd-seed is
   generated, and the hunting-and-pecking continues.  This process
   continues until the group-specific operation returns the Password
   Element.






<span class="grey">Harkins &amp; Zorn                Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


<span class="h5"><a class="selflink" id="section-2.8.3.1" href="#section-2.8.3.1">2.8.3.1</a>.  ECC Operation for PWE</span>

   The group-specific operation for ECC groups uses pwd-value, pwd-seed,
   and the equation for the curve to produce the Password Element.
   First, pwd-value is used directly as the x-coordinate, x, with the
   equation for the elliptic curve, with parameters a and b from the
   domain parameter set of the curve, to solve for a y-coordinate, y.
   If there is no solution to the quadratic equation, this operation
   fails and the hunting-and-pecking process continues.  If a solution
   is found, then an ambiguity exists as there are technically two
   solutions to the equation and pwd-seed is used to unambiguously
   select one of them.  If the low-order bit of pwd-seed is equal to the
   low-order bit of y, then a candidate PWE is defined as the point
   (x, y); if the low-order bit of pwd-seed differs from the low-order
   bit of y, then a candidate PWE is defined as the point (x, p - y),
   where p is the prime over which the curve is defined.  The candidate
   PWE becomes PWE, and the hunting and pecking terminates successfully.

   Algorithmically, the process looks like this:

      found = 0
      counter = 1
      do {
        pwd-seed = H(token | peer-ID | server-ID | password | counter)
        pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
        if (pwd-value &lt; p)
        then
          x = pwd-value
          if ( (y = sqrt(x^3 + ax + b)) != FAIL)
          then
            if (LSB(y) == LSB(pwd-seed))
            then
              PWE = (x, y)
            else
              PWE = (x, p-y)
            fi
            found = 1
          fi
        fi
        counter = counter + 1
      } while (found == 0)

                    Figure 3: Fixing PWE for ECC Groups








<span class="grey">Harkins &amp; Zorn                Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


<span class="h5"><a class="selflink" id="section-2.8.3.2" href="#section-2.8.3.2">2.8.3.2</a>.  FFC Operation for pwe</span>

   The group-specific operation for FFC groups takes pwd-value, and the
   prime, p, and order, r, from the group's domain parameter set (see
   <a href="#section-2.2.1">Section 2.2.1</a> when the order is not part of the defined domain
   parameter set) to directly produce a candidate Password Element, pwe,
   by exponentiating the pwd-value to the value ((p-1)/r) modulo the
   prime.  If the result is greater than one (1), the candidate pwe
   becomes pwe, and the hunting and pecking terminates successfully.

   Algorithmically, the process looks like this:

      found = 0
      counter = 1
      do {
        pwd-seed = H(token | peer-ID | server-ID | password | counter)
        pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
        if (pwd-value &lt; p)
        then
          pwe = pwd-value ^ ((p-1)/r) mod p
          if (pwe &gt; 1)
          then
            found = 1
          fi
        fi
        counter = counter + 1
      } while (found == 0)

                    Figure 4: Fixing PWE for FFC Groups

<span class="h4"><a class="selflink" id="section-2.8.4" href="#section-2.8.4">2.8.4</a>.  Message Construction</span>

   After the EAP-pwd Identity exchange, the construction of the
   components of subsequent messages depends on the type of group from
   the ciphersuite (ECC or FFC).  This section provides an overview of
   the authenticated key exchange.  For a complete description of
   message generation and processing, see Sections <a href="#section-2.8.5.2">2.8.5.2</a> and <a href="#section-2.8.5.3">2.8.5.3</a>.

<span class="h5"><a class="selflink" id="section-2.8.4.1" href="#section-2.8.4.1">2.8.4.1</a>.  ECC Groups</span>

   Using the mapping function F() defined in <a href="#section-2.2.2">Section 2.2.2</a> and the group
   order r:

   Server: EAP-pwd-Commit/Request
      - choose two random numbers, 1 &lt; s_rand, s_mask &lt; r
      - compute Scalar_S = (s_rand + s_mask) mod r
      - compute Element_S = inv(s_mask * PWE)




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


    Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request

   Peer: EAP-pwd-Commit/Response
      - choose two random numbers, 1 &lt; p_rand, p_mask &lt; r
      - compute Scalar_P = (p_rand + p_mask) mod r
      - compute Element_P = inv(p_mask * PWE)

    Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response

   Server: EAP-pwd-Confirm/Request
      - compute KS = (s_rand * (Scalar_P * PWE + Element_P))
      - compute ks = F(KS)
      - compute Confirm_S = H(ks | Element_S | Scalar_S |
                              Element_P | Scalar_P | Ciphersuite)

    Confirm_S is used to construct EAP-pwd-Confirm/Request

   Peer: EAP-pwd-Confirm/Response
      - compute KP = (p_rand * (Scalar_S * PWE + Element_S)),
      - compute kp = F(KP)
      - compute Confirm_P = H(kp | Element_P | Scalar_P |
                              Element_S | Scalar_S | Ciphersuite)

    Confirm_P is used to construct EAP-pwd-Confirm/Response

   The EAP Server computes the shared secret as:
     MK = H(ks | Confirm_P | Confirm_S)

   The EAP Peer computes the shared secret as:
     MK = H(kp | Confirm_P | Confirm_S)


   The MSK and EMSK are derived from MK per <a href="#section-2.9">Section 2.9</a>.

<span class="h5"><a class="selflink" id="section-2.8.4.2" href="#section-2.8.4.2">2.8.4.2</a>.  FFC Groups</span>

   There is no mapping function, F(), required for an FFC group.  Using
   the order, r, for the group (see <a href="#section-2.2.1">Section 2.2.1</a> when the order is not
   part of the defined domain parameters):

   Server: EAP-pwd-Commit/Request
      - choose two random numbers, 1 &lt; s_rand, s_mask &lt; r
      - compute Scalar_S = (s_rand + s_mask) mod r
      - compute Element_S = inv(pwe^s_mask mod p)

    Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request





<span class="grey">Harkins &amp; Zorn                Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   Peer: EAP-pwd-Commit/Response
      - choose random two numbers, 1 &lt; p_rand, p_mask &lt; r
      - compute Scalar_P = (p_rand + p_mask) mod r
      - compute Element_P = inv(pwe^p_mask mod p)

    Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response

   Server: EAP-pwd-Confirm/Request
      - compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p
      - compute Confirm_S = H(ks | Element_S | Scalar_S |
                              Element_P | Scalar_P | Ciphersuite)

    Confirm_S is used to construct EAP-pwd-Confirm/Request

   Peer: EAP-pwd-Confirm/Response
      - compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p
      - compute Confirm_P = H(kp | Element_P | Scalar_P |
                              Element_S | Scalar_S | Ciphersuite)

    Confirm_P is used to construct EAP-pwd-Confirm/Request

   The EAP Server computes the shared secret as:
     MK = H(ks | Confirm_P | Confirm_S)

   The EAP Peer computes the shared secret as:
     MK = H(kp | Confirm_P | Confirm_S)


   The MSK and EMSK are derived from MK per <a href="#section-2.9">Section 2.9</a>.

<span class="h4"><a class="selflink" id="section-2.8.5" href="#section-2.8.5">2.8.5</a>.  Message Processing</span>

<span class="h5"><a class="selflink" id="section-2.8.5.1" href="#section-2.8.5.1">2.8.5.1</a>.  EAP-pwd-ID Exchange</span>

   Although EAP provides an Identity method to determine the identity of
   the peer, the value in the Identity Response may have been truncated
   or obfuscated to provide privacy or decorated for routing purposes
   [<a href="./rfc3748" title="&quot;Extensible Authentication Protocol (EAP)&quot;">RFC3748</a>], making it inappropriate for usage by the EAP-pwd method.
   Therefore, the EAP-pwd-ID exchange is defined for the purpose of
   exchanging identities between the peer and server.

   The EAP-pwd-ID/Request contains the following quantities:

   o  a ciphersuite

   o  a representation of the server's identity per <a href="#section-2.7.1">Section 2.7.1</a>





<span class="grey">Harkins &amp; Zorn                Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   o  an anti-clogging token

   o  a password pre-processing method

   The ciphersuite specifies the finite cyclic group, random function,
   and PRF selected by the server for use in the subsequent
   authentication exchange.

   The value of the anti-clogging token MUST be unpredictable and SHOULD
   NOT be from a source of random entropy.  The purpose of the anti-
   clogging token is to provide the server an assurance that the peer
   constructing the EAP-pwd-ID/Response is genuine and not part of a
   flooding attack.

   A password pre-processing method is communicated to ensure
   interoperability by producing a canonical representation of the
   password string between the peer and server (see <a href="#section-2.7.2">Section 2.7.2</a>).

   The EAP-pwd-ID/Request is constructed according to <a href="#section-3.2.1">Section 3.2.1</a> and
   is transmitted to the peer.

   Upon receipt of an EAP-pwd-ID/Request, the peer determines whether
   the ciphersuite and pre-processing method are acceptable.  If not,
   the peer MUST respond with an EAP-NAK.  If acceptable, the peer
   responds to the EAP-pwd-ID/Request with an EAP-pwd-ID/Response,
   constructed according to <a href="#section-3.2.1">Section 3.2.1</a>, that acknowledges the
   Ciphersuite, token, and pre-processing method and then adds its
   identity.  After sending the EAP-pwd-ID/Response, the peer has the
   identity of the server (from the Request), its own identity (it
   encoded in the Response), a password pre-processing algorithm, and it
   can compute the Password Element as specified in <a href="#section-2.8.3">Section 2.8.3</a>.  The
   Password Element is stored in state allocated for this exchange.

   The EAP-pwd-ID/Response acknowledges the Ciphersuite from the
   Request, acknowledges the anti-clogging token from the Request
   providing a demonstration of "liveness" on the part of the peer, and
   contains the identity of the peer.  Upon receipt of the Response, the
   server verifies that the Ciphersuite acknowledged by the peer is the
   same as that sent in the Request and that the anti-clogging token
   added by the peer in the Response is the same as that sent in the
   Request.  If Ciphersuites or anti-clogging tokens differ, the server
   MUST respond with an EAP-Failure message.  If the anti-clogging
   tokens are the same, the server knows the peer is an active
   participant in the exchange.  If the Ciphersuites are the same, the
   server now knows its own identity (it encoded in the Request) and the
   peer's identity (from the Response) and can compute the Password





<span class="grey">Harkins &amp; Zorn                Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   Element according to <a href="#section-2.8.3">Section 2.8.3</a>.  The server stores the Password
   Element in state it has allocated for this exchange.  The server then
   initiates an EAP-pwd-Commit exchange.

<span class="h5"><a class="selflink" id="section-2.8.5.2" href="#section-2.8.5.2">2.8.5.2</a>.  EAP-pwd-Commit Exchange</span>

   The server begins the EAP-pwd-Confirm exchange by choosing two random
   numbers, s_rand and s_mask, between 1 and r (where r is described in
   <a href="#section-2.1">Section 2.1</a> according to the group established in <a href="#section-2.8.5.1">Section 2.8.5.1</a>)
   such that their sum modulo r is greater than one (1).  It then
   computes Element_S and Scalar_S as defined in <a href="#section-2.8.4">Section 2.8.4</a> and
   constructs an EAP-pwd-Commit/Request according to <a href="#section-3.2.2">Section 3.2.2</a>.
   Element_S and Scalar_S are added to the state allocated for this
   exchange, and the EAP-pwd-Commit/Request is transmitted to the peer.

   Upon receipt of the EAP-pwd-Commit/Request, the peer validates the
   length of the entire payload based upon the expected lengths of
   Element_S and Scalar_S (which are fixed according to the length of
   the agreed-upon group).  If the length is incorrect, the peer MUST
   terminate the exchange.  If the length is correct, Element_S and
   Scalar_S are extracted from the EAP-pwd-Commit/Request.  Scalar_S is
   then checked to ensure it is between 1 and r, exclusive.  If it is
   not, the peer MUST terminate the exchange.  If it is, Element_S MUST
   be validated depending on the type of group -- Element validation for
   FFC groups is described in <a href="#section-2.8.5.2.1">Section 2.8.5.2.1</a>, and Element validation
   for ECC groups is described in <a href="#section-2.8.5.2.2">Section 2.8.5.2.2</a>.  If validation is
   successful, the peer chooses two random numbers, p_rand and p_mask,
   between 1 and r (where r is described in <a href="#section-2.1">Section 2.1</a> according to the
   group established in <a href="#section-2.8.5.1">Section 2.8.5.1</a>) such that their sum modulo r is
   greater than one (1), and computes Element_P and Scalar_P.  Next, the
   peer computes kp from p_rand, Element_S, Scalar_S, and the Password
   Element according to <a href="#section-2.8.4">Section 2.8.4</a>.  If kp is the "identity element"
   -- the point at infinity for an ECC group or the value one (1) for an
   FFC group -- the peer MUST terminate the exchange.  If not, the peer
   uses Element_P and Scalar_P to construct an EAP-pwd-Commit/Response
   according to <a href="#section-3.2.2">Section 3.2.2</a> and transmits the EAP-pwd-Commit/Response
   to the server.

   Upon receipt of the EAP-pwd-Commit/Response, the server validates the
   length of the entire payload based upon the expected lengths of
   Element_P and Scalar_P (which are fixed according to the agreed-upon
   group).  If the length is incorrect, the server MUST respond with an
   EAP-Failure message, and it MUST terminate the exchange and free up
   any state allocated.  If the length is correct, Scalar_P and
   Element_P are extracted from the EAP-pwd-Commit/Response and compared
   to Scalar_S and Element_S.  If Scalar_P equals Scalar_S and Element_P
   equals Element_S, it indicates a reflection attack and the server
   MUST respond with an EAP-failure and terminate the exchange.  If they



<span class="grey">Harkins &amp; Zorn                Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   differ, Scalar_P is checked to ensure it is between 1 and r,
   exclusive.  If not the server MUST respond with an EAP-failure and
   terminate the exchange.  If it is, Element_P is verified depending on
   the type of group -- Element validation for FFC groups is described
   in <a href="#section-2.8.5.2.1">Section 2.8.5.2.1</a>, and Element validation for ECC groups is
   described in <a href="#section-2.8.5.2.2">Section 2.8.5.2.2</a>.  If validation is successful, the
   server computes ks from s_rand, Element_P, Scalar_P, and the Password
   Element according to <a href="#section-2.8.4">Section 2.8.4</a>.  If ks is the "identity element"
   -- the point at infinity for an ECC group or the value one (1) for an
   FFC group -- the server MUST respond with an EAP-failure and
   terminate the exchange.  Otherwise, the server initiates an EAP-pwd-
   Confirm exchange.

<span class="h6"><a class="selflink" id="section-2.8.5.2.1" href="#section-2.8.5.2.1">2.8.5.2.1</a>.  Element Validation for FFC Groups</span>

   A received FFC Element is valid if: 1) it is between one (1) and the
   prime, p, exclusive; and 2) if modular exponentiation of the Element
   by the group order, r, equals one (1).  If either of these conditions
   are not true the received Element is invalid.

<span class="h6"><a class="selflink" id="section-2.8.5.2.2" href="#section-2.8.5.2.2">2.8.5.2.2</a>.  Element Validation for ECC Groups</span>

   Validating a received ECC Element involves: 1) checking whether the
   two coordinates, x and y, are both greater than zero (0) and less
   than the prime defining the underlying field; and 2) checking whether
   the x- and y-coordinates satisfy the equation of the curve (that is,
   that they produce a valid point on the curve that is not the point at
   infinity).  If either of these conditions are not met, the received
   Element is invalid; otherwise, the Element is valid.

<span class="h5"><a class="selflink" id="section-2.8.5.3" href="#section-2.8.5.3">2.8.5.3</a>.  EAP-pwd-Confirm Exchange</span>

   The server computes Confirm_S according to <a href="#section-2.8.4">Section 2.8.4</a>, constructs
   an EAP-pwd-Confirm/Request according to <a href="#section-3.2.3">Section 3.2.3</a>, and sends it
   to the peer.

   Upon receipt of an EAP-pwd-Confirm/Request, the peer validates the
   length of the entire payload based upon the expected length of
   Confirm_S (whose length is fixed by the agreed-upon random function).
   If the length is incorrect, the peer MUST terminate the exchange and
   free up any state allocated.  If the length is correct, the peer
   verifies that Confirm_S is the value it expects based on the value of
   kp.  If the value of Confirm_S is incorrect, the peer MUST terminate
   the exchange and free up any state allocated.  If the value of
   Confirm_S is correct, the peer computes Confirm_P, constructs an EAP-
   pwd-Confirm/Response according to <a href="#section-3.2.3">Section 3.2.3</a>, and sends it off to
   the server.  The peer then computes MK (according to <a href="#section-2.8.4">Section 2.8.4</a>)
   and the MSK and EMSK (according to <a href="#section-2.9">Section 2.9</a>) and stores these keys



<span class="grey">Harkins &amp; Zorn                Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   in state allocated for this exchange.  The peer SHOULD export the MSK
   and EMSK at this time in anticipation of a secure association
   protocol by the lower layer to create session keys.  Alternatively,
   the peer can wait until an EAP-Success message from the server before
   exporting the MSK and EMSK.

   Upon receipt of an EAP-pwd-Confirm/Response, the server validates the
   length of the entire payload based upon the expected length of
   Confirm_P (whose length is fixed by the agreed-upon random function).
   If the length is incorrect, the server MUST respond with an EAP-
   Failure message, and it MUST terminate the exchange and free up any
   state allocated.  If the length is correct, the server verifies that
   Confirm_P is the value it expects based on the value of ks.  If the
   value of Confirm_P is incorrect, the server MUST respond with an EAP-
   Failure message.  If the value of Confirm_P is correct, the server
   computes MK (according to <a href="#section-2.8.4">Section 2.8.4</a>) and the MSK and EMSK
   (according to <a href="#section-2.9">Section 2.9</a>).  It exports the MSK and EMSK and responds
   with an EAP-Success message.  The server SHOULD free up state
   allocated for this exchange.

<span class="h3"><a class="selflink" id="section-2.9" href="#section-2.9">2.9</a>.  Management of EAP-pwd Keys</span>

   [<a id="ref-RFC5247">RFC5247</a>] recommends each EAP method define how to construct a
   Method-ID and Session-ID to identify a particular EAP session between
   a peer and server.  This information is constructed thusly:

       Method-ID = H(Ciphersuite | Scalar_P | Scalar_S)

       Session-ID = Type-Code | Method-ID

   where Ciphersuite, Scalar_P, and Scalar_S are from the specific
   exchange being identified; H is the random function specified in the
   Ciphersuite; and, Type-Code is the code assigned for EAP-pwd, 52,
   represented as a single octet.

   The authenticated key exchange of EAP-pwd generates a shared and
   authenticated key, MK.  The size of MK is dependent on the random
   function, H, asserted in the Ciphersuite.  EAP-pwd must export two
   512-bit keys, MSK and EMSK.  Regardless of the value of len(MK),
   implementations MUST invoke the KDF defined in <a href="#section-2.5">Section 2.5</a> to
   construct the MSK and EMSK.  The MSK and EMSK are derived thusly:

       MSK | EMSK = KDF(MK, Session-ID, 1024)

   [<a id="ref-RFC4962">RFC4962</a>] mentions the importance of naming keys, particularly when
   key caching is being used.  To facilitate such an important
   optimization, names are assigned thusly:




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   o   EMSK-name = Session-ID | 'E' | 'M'| 'S' | 'K'

   o   MSK-name = Session-ID | 'M'| 'S' | 'K'

   where 'E' is a single octet of value 0x45, 'M' is a single octet of
   value 0x4d, 'S' is a single octet of value 0x53, and 'K' is a single
   octet of value 0x4b.

   This naming scheme allows for key-management applications to quickly
   and accurately identify keys for a particular session or all keys of
   a particular type.

<span class="h3"><a class="selflink" id="section-2.10" href="#section-2.10">2.10</a>.  Mandatory-to-Implement Parameters</span>

   For the purposes of interoperability, compliant EAP-pwd
   implementations SHALL support the following parameters:

   o   Diffie-Hellman Group: group 19 defined in [<a href="./rfc5114" title="&quot;Additional Diffie-Hellman Groups for Use with IETF Standards&quot;">RFC5114</a>]

   o   Random Function: defined in <a href="#section-2.4">Section 2.4</a>

   o   PRF: HMAC-SHA256 defined in [<a href="./rfc4634" title="&quot;US Secure Hash Algorithms (SHA and HMAC-SHA)&quot;">RFC4634</a>]

   o   Password Pre-Processing: none

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Packet Formats</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  EAP-pwd Header</span>

   The EAP-pwd header has the following structure:

        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      |  Identifier   |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |L|M|  PWD-Exch |         Total-Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Data...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5: EAP-pwd Header

   Code

      Either 1 (for Request) or 2 (for Response); see [<a href="./rfc3748" title="&quot;Extensible Authentication Protocol (EAP)&quot;">RFC3748</a>].





<span class="grey">Harkins &amp; Zorn                Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   Identifier

      The Identifier field is one octet and aids in matching responses
      with requests.  The Identifier field MUST be changed on each
      Request packet.

   Length

      The Length field is two octets and indicates the length of the EAP
      packet including the Code, Identifier, Length, Type, and Data
      fields.  Octets outside the range of the Length field should be
      treated as Data Link Layer padding and MUST be ignored on
      reception.

   Type

      52 - EAP-pwd

   L and M bits

      The L bit (Length included) is set to indicate the presence of the
      two-octet Total-Length field, and MUST be set for the first
      fragment of a fragmented EAP-pwd message or set of messages.

      The M bit (more fragments) is set on all but the last fragment.

   PWD-Exch

      The PWD-Exch field identifies the type of EAP-pwd payload
      encapsulated in the Data field.  This document defines the
      following values for the PWD-Exch field:

      *   0x00 : Reserved

      *   0x01 : EAP-pwd-ID exchange

      *   0x02 : EAP-pwd-Commit exchange

      *   0x03 : EAP-pwd-Confirm exchange

      All other values of the PWD-Exch field are unassigned.

   Total-Length

      The Total-Length field is two octets in length, and is present
      only if the L bit is set.  This field provides the total length of
      the EAP-pwd message or set of messages that is being fragmented.




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  EAP-pwd Payloads</span>

   EAP-pwd payloads all contain the EAP-pwd header and encoded
   information.  Encoded information is comprised of sequences of data.
   Payloads in the EAP-pwd-ID exchange also include a ciphersuite
   statement indicating what finite cyclic group to use, what
   cryptographic primitive to use for H, and what PRF to use for
   deriving keys.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  EAP-pwd-ID</span>

   The Group Description, Random Function, and PRF together, and in that
   order, comprise the Ciphersuite included in the calculation of the
   peer's and server's confirm messages.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Group Description       | Random Func'n |      PRF      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Token                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Prep     |                  Identity...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 6: EAP-pwd-ID Payload

   The Group Description field value is taken from the IANA registry for
   "Group Description" created by IKE [<a href="./rfc2409" title="&quot;The Internet Key Exchange (IKE)&quot;">RFC2409</a>].

   This document defines the following value for the Random Function
   field:

   o   0x01 : Function defined in this memo in <a href="#section-2.4">Section 2.4</a>

   The value 0x00 is reserved for private use between mutually
   consenting parties.  All other values of the Random Function field
   are unassigned.

   The PRF field has the following value:

   o   0x01 : HMAC-SHA256 [<a href="./rfc4634" title="&quot;US Secure Hash Algorithms (SHA and HMAC-SHA)&quot;">RFC4634</a>]

   The value 0x00 is reserved for private use between mutually
   consenting parties.  All other values of the PRF field are
   unassigned.





<span class="grey">Harkins &amp; Zorn                Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   The Token field contains an unpredictable value assigned by the
   server in an EAP-pwd-ID/Request and acknowledged by the peer in an
   EAP-pwd-ID/Response (see <a href="#section-2.8.5">Section 2.8.5</a>).

   The Prep field represents the password pre-processing technique (see
   <a href="#section-2.7.2">Section 2.7.2</a>) to be used by the client prior to generating the
   password seed (see <a href="#section-2.8.3">Section 2.8.3</a>).  This document defines the
   following values for the Prep field:

   o   0x00 : None

   o   0x01 : <a href="./rfc2759">RFC2759</a>

   o   0x02 : SASLprep

   All other values of the Prep field are unassigned.

   The Identity field depends on the tuple of PWD-Exch/Code.

   o   EAP-pwd-ID/Request : Server_ID

   o   EAP-pwd-ID/Response : Peer_ID

   The length of the identity is computed from the Length field in the
   EAP header.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  EAP-pwd-Commit</span>

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                           Element                             ~
       |                                                               |
       ~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
       |                                                               |
       ~                            Scalar             +-+-+-+-+-+-+-+-+
       |                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7: EAP-pwd-Commit Payload








<span class="grey">Harkins &amp; Zorn                Informational                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   The Element and Scalar fields depend on the tuple of PWD-Exch/Code.

   o   EAP-pwd-Commit/Request : Element_S, Scalar_S

   o   EAP-pwd-Commit/Response : Element_P, Scalar_P

   The Element is encoded according to <a href="#section-3.3">Section 3.3</a>.  The length of the
   Element is inferred by the finite cyclic group from the agreed-upon
   Ciphersuite.  The length of the scalar can then be computed from the
   Length in the EAP header.

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  EAP-pwd-Confirm</span>

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                            Confirm                            ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 8: EAP-pwd-Confirm Payload

   The Confirm field depends on the tuple of PWD-Exch/Code.

   o   EAP-pwd-Confirm/Request : Confirm_S

   o   EAP-pwd-Confirm/Response : Confirm_P

   The length of the Confirm field computed from the Length in the EAP
   header.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Representation of Group Elements and Scalars</span>

   Payloads in the EAP-pwd-Commit exchange contain elements from the
   agreed-upon finite cyclic cryptographic group (either an FCC group or
   an ECC group).  To ensure interoperability, field elements and
   scalars MUST be represented in payloads in accordance with the
   requirements described below.

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Elements in FFC Groups</span>

   Elements in an FFC group MUST be represented (in binary form) as
   unsigned integers that are strictly less than the prime, p, from the
   group's domain parameter set.  The binary representation of each
   group element MUST have a bit length equal to the bit length of the





<span class="grey">Harkins &amp; Zorn                Informational                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   binary representation of p.  This length requirement is enforced, if
   necessary, by prepending the binary representation of the integer
   with zeros until the required length is achieved.

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Elements in ECC Groups</span>

   Elements in an ECC group are points on the agreed-upon elliptic
   curve.  Each such element MUST be represented by the concatenation of
   two components, an x-coordinate and a y-coordinate.

   Each of the two components, the x-coordinate and the y-coordinate,
   MUST be represented (in binary form) as an unsigned integer that is
   strictly less than the prime, p, from the group's domain parameter
   set.  The binary representation of each component MUST have a bit
   length equal to the bit length of the binary representation of p.
   This length requirement is enforced, if necessary, by prepending the
   binary representation of the integer with zeros until the required
   length is achieved.

   Since the field element is represented in a payload by the
   x-coordinate followed by the y-coordinate, it follows that the length
   of the element in the payload MUST be twice the bit length of p.  In
   other words, "compressed representation" is not used.

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

   Scalars MUST be represented (in binary form) as unsigned integers
   that are strictly less than r, the order of the generator of the
   agreed-upon cryptographic group.  The binary representation of each
   scalar MUST have a bit length equal to the bit length of the binary
   representation of r.  This requirement is enforced, if necessary, by
   prepending the binary representation of the integer with zeros until
   the required length is achieved.

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

   EAP [<a href="./rfc3748" title="&quot;Extensible Authentication Protocol (EAP)&quot;">RFC3748</a>] is a request-response protocol.  The server sends
   requests and the peer responds.  These request and response messages
   are assumed to be limited to at most 1020 bytes.  Messages in EAP-pwd
   can be larger than 1020 bytes and therefore require support for
   fragmentation and reassembly.

   Implementations MUST establish a fragmentation threshold that
   indicates the maximum size of an EAP-pwd payload.  When an
   implementation knows the maximum transmission unit (MTU) of its lower
   layer, it SHOULD calculate the fragmentation threshold from that
   value.  In lieu of knowledge of the lower layer's MTU, the
   fragmentation threshold MUST be set to 1020 bytes.



<span class="grey">Harkins &amp; Zorn                Informational                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   Since EAP is a simple ACK-NAK protocol, fragmentation support can be
   added in a simple manner.  In EAP, fragments that are lost or damaged
   in transit will be retransmitted, and since sequencing information is
   provided by the Identifier field in EAP, there is no need for a
   fragment offset field as is provided in IPv4.

   EAP-pwd fragmentation support is provided through the addition of
   flags within the EAP-Response and EAP-Request packets, as well as a
   Total-Length field of two octets.  Flags include the Length included
   (L) and More fragments (M) bits.  The L flag is set to indicate the
   presence of the two-octet Total-Length field, and MUST be set for the
   first fragment of a fragmented EAP-pwd message or set of messages.
   The M flag is set on all but the last fragment.  The Total-Length
   field is two octets, and provides the total length of the EAP-pwd
   message or set of messages that is being fragmented; this simplifies
   buffer allocation.

   When an EAP-pwd peer receives an EAP-Request packet with the M bit
   set, it MUST respond with an EAP-Response with EAP-Type=EAP-pwd and
   no data.  This serves as a fragment ACK.  The EAP server MUST wait
   until it receives the EAP-Response before sending another fragment.
   In order to prevent errors in processing of fragments, the EAP server
   MUST increment the Identifier field for each fragment contained
   within an EAP-Request, and the peer MUST include this Identifier
   value in the fragment ACK contained within the EAP-Response.
   Retransmitted fragments will contain the same Identifier value.

   Similarly, when the EAP server receives an EAP-Response with the M
   bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-pwd
   and no data.  This serves as a fragment ACK.  The EAP peer MUST wait
   until it receives the EAP-Request before sending another fragment.
   In order to prevent errors in the processing of fragments, the EAP
   server MUST increment the Identifier value for each fragment ACK
   contained within an EAP-Request, and the peer MUST include this
   Identifier value in the subsequent fragment contained within an EAP-
   Response.

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

   This memo contains new numberspaces to be managed by IANA.  The
   policies used to allocate numbers are described in [<a href="./rfc5226" title="">RFC5226</a>].  IANA
   has allocated a new EAP method type for EAP-pwd (52).

   IANA has created new registries for PWD-Exch messages, random
   functions, PRFs, and password pre-processing methods and has added
   the message numbers, random function, PRF, and pre-processing methods
   specified in this memo to those registries, respectively.




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   The following is the initial PWD-Exch message registry layout:

   o   0x00 : Reserved

   o   0x01 : EAP-pwd-ID exchange

   o   0x02 : EAP-pwd-Commit exchange

   o   0x03 : EAP-pwd-Confirm exchange

   The PWD-Exch field is 6 bits long.  The value 0x00 is reserved.  All
   other values are available through assignment by IANA.  IANA is
   instructed to assign values based on "IETF Review" (see [<a href="./rfc5226" title="">RFC5226</a>]).

   The following is the initial Random Function registry layout:

   o   0x00 : Private Use

   o   0x01 : Function defined in this memo, <a href="#section-2.4">Section 2.4</a>

   The Random Function field is 8 bits long.  The value 0x00 is for
   Private Use between mutually consenting parties.  All other values
   are available through assignment by IANA.  IANA is instructed to
   assign values based on "Specification Required" (see [<a href="./rfc5226" title="">RFC5226</a>]).  The
   Designated Expert performing the necessary review MUST ensure the
   random function has been cryptographically vetted.

   The following is the initial PRF registry layout:

   o   0x00 : Private Use

   o   0x01 : HMAC-SHA256 as defined in [<a href="./rfc4634" title="&quot;US Secure Hash Algorithms (SHA and HMAC-SHA)&quot;">RFC4634</a>]

   The PRF field is 8 bits long.  The value 0x00 is for Private Use
   between mutually consenting parties.  All other values are available
   through assignment by IANA.  IANA is instructed to assign values
   based on "IETF Review" (see [<a href="./rfc5226" title="">RFC5226</a>]).

   The following is the initial layout for the password pre-processing
   method registry:

   o   0x00 : None

   o   0x01 : <a href="./rfc2759">RFC2759</a>

   o   0x02 : SASLprep





<span class="grey">Harkins &amp; Zorn                Informational                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   The Prep field is 8 bits long, and all other values are available
   through assignment by IANA.  IANA is instructed to assign values
   based on "Specification Required" (see [<a href="./rfc5226" title="">RFC5226</a>]).

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

   In <a href="#section-1.3">Section 1.3</a>, several security properties were presented that
   motivated the design of this protocol.  This section will address how
   well they are met.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Resistance to Passive Attack</span>

   A passive attacker will see Scalar_P, Element_P, Scalar_S, and
   Element_S.  She can guess at passwords to compute the password
   element but will not know s_rand or p_rand and therefore will not be
   able to compute MK.

   The secret random value of the peer (server) is effectively hidden by
   adding p_mask (s_mask) to p_rand (s_rand) modulo the order of the
   group.  If the order is "r", then there are approximately "r"
   distinct pairs of numbers that will sum to the value Scalar_P
   (Scalar_S).  Attempting to guess the particular pair is just as
   difficult as guessing the secret random value p_rand (s_rand), the
   probability of a guess is 1/(r - i) after "i" guesses.  For a large
   value of r, this exhaustive search technique is computationally
   infeasible.  An attacker would do better by determining the discrete
   logarithm of Element_P (Element_S) using an algorithm like the baby-
   step giant-step algorithm (see [<a href="#ref-APPCRY" title="&quot;Handbook of Applied Cryptography&quot;">APPCRY</a>]), which runs on the order of
   the square root of r group operations (e.g., a group with order 2^160
   would require 2^80 exponentiations or point multiplications).  Based
   on the assumptions made on the finite cyclic group in <a href="#section-2.3">Section 2.3</a>,
   that is also computationally infeasible.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Resistance to Active Attack</span>

   An active attacker can launch her attack after an honest server has
   sent EAP-pwd-Commit/Request to an honest peer.  This would result in
   the peer sending EAP-pwd-Commit/Response.  In this case, the active
   attack has been reduced to that of a passive attacker since p_rand
   and s_rand will remain unknown.  The active attacker could forge a
   value of Confirm_P (Confirm_S) and send it to the EAP server (EAP
   peer) in the hope that it will be accepted, but due to the
   assumptions on H made in <a href="#section-2.3">Section 2.3</a>, that is computationally
   infeasible.

   The active attacker can launch her attack by forging EAP-pwd-Commit/
   Request and sending it to the peer.  This will result in the peer
   responding with EAP-pwd-Commit/Response.  The attacker can then



<span class="grey">Harkins &amp; Zorn                Informational                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   attempt to compute ks, but since she doesn't know the password, this
   is infeasible.  It can be shown that an attack by forging an EAP-pwd-
   Commit/Response is an identical attack with equal infeasibility.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Resistance to Dictionary Attack</span>

   An active attacker can wait until an honest server sends EAP-pwd-
   Commit/Request and then forge EAP-pwd-Commit/Response and send it to
   the server.  The server will respond with EAP-pwd-Confirm/Request.
   Now the attacker can attempt to launch a dictionary attack.  She can
   guess at potential passwords, compute the password element, and
   compute kp using her p_rand, Scalar_S, and Element_S from the EAP-
   pwd-Commit/Request and the candidate password element from her guess.
   She will know if her guess is correct when she is able to verify
   Confirm_S in EAP-pwd-Confirm/Request.

   But the attacker committed to a password guess with her forged EAP-
   pwd-Commit/Response when she computed Element_P.  That value was used
   by the server in his computation of ks that was used when he
   constructed Confirm_S in EAP-pwd-Confirm/Request.  Any guess of the
   password that differs from the one used in the forged EAP-pwd-Commit/
   Response could not be verified as correct since the attacker has no
   way of knowing whether it is correct.  She is able to make one guess
   and one guess only per attack.  This means that any advantage she can
   gain -- guess a password, if it fails exclude it from the pool of
   possible passwords and try again -- is solely through interaction
   with an honest protocol peer.

   The attacker can commit to the guess with the forged EAP-pwd-Commit/
   Response and then run through the dictionary, computing the password
   element and ks using her forged Scalar_P and Element_P.  She will
   know she is correct if she can compute the same value for Confirm_S
   that the server produced in EAP-pwd-Confirm/Request.  But this
   requires the attacker to know s_rand, which we noted above was not
   possible.

   The password element PWE/pwe is chosen using a method described in
   <a href="#section-2.8.3">Section 2.8.3</a>.  Since this is an element in the group, there exists a
   scalar value, q, such that:

       PWE = q * G, for an ECC group

       pwe = g^q mod p, for an FFC group

   Knowledge of q can be used to launch a dictionary attack.  For the
   sake of brevity, the attack will be demonstrated assuming an ECC
   group.  The attack works thusly:




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   The attacker waits until an honest server sends an EAP-pwd-Commit/
   Request.  The attacker then generates a random Scalar_P and a random
   p_mask and computes Element_P = p_mask * G.  The attacker sends the
   bogus Scalar_P and Element_P to the server and obtains Confirm_S in
   return.  Note that the server is unable to detect that Element_P was
   calculated incorrectly.

   The attacker now knows that:

       KS = (Scalar_P * q + p_mask) * s_rand * G

   and

       s_rand * G = Scalar_P * G - ((1/q) mod r * -Element_P)

   Since Scalar_P, p_mask, G, and Element_P are all known, the attacker
   can run through the dictionary, make a password guess, compute PWE
   using the technique in <a href="#section-2.8.3">Section 2.8.3</a>, determine q, and then use the
   equations above to compute KS and see if it can verify Confirm_S. But
   to determine q for a candidate PWE, the attacker needs to perform a
   discrete logarithm that was assumed to be computationally infeasible
   in <a href="#section-2.3">Section 2.3</a>.  Therefore, this attack is also infeasible.

   The best advantage an attacker can gain in a single active attack is
   to determine whether a single guess at the password was correct.
   Therefore, her advantage is solely through interaction and not
   computation, which is the definition for resistance to dictionary
   attack.

   Resistance to dictionary attack means that the attacker must launch
   an active attack to make a single guess at the password.  If the size
   of the dictionary from which the password was extracted was D, and
   each password in the dictionary has an equal probability of being
   chosen, then the probability of success after a single guess is 1/D.
   After X guesses, and removal of failed guesses from the pool of
   possible passwords, the probability becomes 1/(D-X).  As X grows, so
   does the probability of success.  Therefore, it is possible for an
   attacker to determine the password through repeated brute-force,
   active, guessing attacks.  This protocol does not presume to be
   secure against this, and implementations SHOULD ensure the size of D
   is sufficiently large to prevent this attack.  Implementations SHOULD
   also take countermeasures -- for instance, refusing authentication
   attempts for a certain amount of time, after the number of failed
   authentication attempts reaches a certain threshold.  No such
   threshold or amount of time is recommended in this memo.






<span class="grey">Harkins &amp; Zorn                Informational                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Forward Secrecy</span>

   The MSK and EMSK are extracted from MK, which is derived from doing
   group operations with s_rand, p_rand, and the password element.  The
   peer and server choose random values with each run of the protocol.
   So even if an attacker is able to learn the password, she will not
   know the random values used by either the peer or server from an
   earlier run and will therefore be unable to determine MK, or the MSK
   or EMSK.  This is the definition of Forward Secrecy.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Group Strength</span>

   The strength of the shared secret, MK, derived in <a href="#section-2.8.4">Section 2.8.4</a>
   depends on the effort needed to solve the discrete logarithm problem
   in the chosen group.  [<a href="./rfc3766" title="&quot;Determining Strengths For Public Keys Used For Exchanging Symmetric Keys&quot;">RFC3766</a>] has a good discussion on the strength
   estimates of symmetric keys derived from discrete logarithm
   cryptography.

   The mandatory-to-implement group defined in this memo is group 19, a
   group from [<a href="./rfc5114" title="&quot;Additional Diffie-Hellman Groups for Use with IETF Standards&quot;">RFC5114</a>] based on Elliptic Curve Cryptography (see
   <a href="#section-2.2.2">Section 2.2.2</a>) with a prime bit length of 256.  This group was chosen
   because the current best estimate of a symmetric key derived using
   this group is 128 bits, which is the typical length of a key for the
   Advanced Encryption Standard ([<a href="#ref-FIPS-197" title="FIPS Pub 197: Advanced Encryption Standard (AES)">FIPS-197</a>]).  While it is possible to
   obtain a equivalent measure of strength using a group based on Finite
   Field Cryptography (see <a href="#section-2.2.1">Section 2.2.1</a>), it would require a much
   larger prime and be more memory and compute intensive.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Random Functions</span>

   The protocol described in this memo uses a function referred to as a
   "random oracle" (as defined in [<a href="#ref-RANDOR" title="&quot;Random Oracles are Practical: A Paradigm for Designing Efficient Protocols&quot;">RANDOR</a>]).  A significant amount of
   care must be taken to instantiate a random oracle out of handy
   cryptographic primitives.  The random oracle used here is based on
   the notion of a "Randomness Extractor" from [<a href="./rfc5869" title="&quot;HMAC-based Extract-and- Expand Key Derivation Function (HKDF)&quot;">RFC5869</a>].

   This protocol can use any properly instantiated random oracle.  To
   ensure that any new value for H will use a properly instantiated
   random oracle, IANA has been instructed (in <a href="#section-5">Section 5</a>) to only
   allocate values from the Random Function registry after being vetted
   by an expert.

   A few of the defined groups that can be used with this protocol have
   a security estimate (see <a href="#section-6.5">Section 6.5</a>) less than 128 bits, many do not
   though, and to prevent the random function from being the gating
   factor (or a target for attack), any new random function MUST map its
   input to a target of at least 128 bits and SHOULD map its input to a
   target of at least 256 bits.



<span class="grey">Harkins &amp; Zorn                Informational                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


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

   [<a id="ref-RFC3748">RFC3748</a>] requires that documents describing new EAP methods clearly
   articulate the security properties of the method.  In addition, for
   use with wireless LANs, [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>] mandates and recommends several of
   these.  The claims are:

   a.  mechanism: password.

   b.  claims:

       *   mutual authentication: the peer and server both authenticate
           each other by proving possession of a shared password.  This
           is REQUIRED by [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>].

       *   forward secrecy: compromise of the password does not reveal
           the secret keys -- MK, MSK, or EMSK -- from earlier runs of
           the protocol.

       *   replay protection: an attacker is unable to replay messages
           from a previous exchange to either learn the password or a
           key derived by the exchange.  Similarly the attacker is
           unable to induce either the peer or server to believe the
           exchange has successfully completed when it hasn't.
           Reflection attacks are foiled because the server ensures that
           the scalar and element supplied by the peer do not equal its
           own.

       *   key derivation: keys are derived by performing a group
           operation in a finite cyclic group (e.g., exponentiation)
           using secret data contributed by both the peer and server.
           An MSK and EMSK are derived from that shared secret.  This is
           REQUIRED by [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>]

       *   dictionary attack resistance: this protocol is resistant to
           dictionary attack because an attacker can only make one
           password guess per active attack.  The advantage gained by an
           attacker is through interaction not through computation.
           This is REQUIRED by [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>].

       *   session independence: this protocol is resistant to active
           and passive attack and does not enable compromise of
           subsequent or prior MSKs or EMSKs from either passive or
           active attack.

       *   Denial-of-Service Resistance: it is possible for an attacker
           to cause a server to allocate state and consume CPU cycles
           generating Scalar_S and Element_S. Such an attack is gated,



<span class="grey">Harkins &amp; Zorn                Informational                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


           though, by the requirement that the attacker first obtain
           connectivity through a lower-layer protocol (e.g. 802.11
           authentication followed by 802.11 association, or 802.3
           "link-up") and respond to two EAP messages --the EAP-ID/
           Request and the EAP-pwd-ID/Request.  The EAP-pwd-ID exchange
           further includes an anti-clogging token that provides a level
           of assurance to the server that the peer is, at least,
           performing a rudimentary amount of processing and not merely
           spraying packets.  This prevents distributed denial-of-
           service attacks and also requires the attacker to announce,
           and commit to, a lower-layer identity, such as a MAC (Media
           Access Control) address.

       *   Man-in-the-Middle Attack Resistance: this exchange is
           resistant to active attack, which is a requirement for
           launching a man-in-the-middle attack.  This is REQUIRED by
           [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>].

       *   shared state equivalence: upon completion of EAP-pwd, the
           peer and server both agree on MK, MSK, EMSK, Method-ID, and
           Session-ID.  The peer has authenticated the server based on
           the Server-ID, and the server has authenticated the peer
           based on the Peer-ID.  This is due to the fact that Peer-ID,
           Server-ID, and the shared password are all combined to make
           the password element, which must be shared between the peer
           and server for the exchange to complete.  This is REQUIRED by
           [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>].

       *   fragmentation: this protocol defines a technique for
           fragmentation and reassembly in <a href="#section-4">Section 4</a>.

       *   resistance to "Denning-Sacco" attack: learning keys
           distributed from an earlier run of the protocol, such as the
           MSK or EMSK, will not help an adversary learn the password.

   c.  key strength: the strength of the resulting key depends on the
       finite cyclic group chosen.  See <a href="#section-6.5">Section 6.5</a>.  This is REQUIRED
       by [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>].

   d.  key hierarchy: MSKs and EMSKs are derived from the MK using the
       KDF defined in <a href="#section-2.5">Section 2.5</a> as described in <a href="#section-2.8.4">Section 2.8.4</a>.

   e.  vulnerabilities (note that none of these are REQUIRED by
       [<a href="./rfc4017" title="&quot;Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs&quot;">RFC4017</a>]):

       *   protected ciphersuite negotiation: the ciphersuite offer made
           by the server is not protected from tampering by an active
           attacker.  Downgrade attacks are prevented, though, since



<span class="grey">Harkins &amp; Zorn                Informational                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


           this is not a "negotiation" with a list of acceptable
           ciphersuites.  If a Ciphersuite was modified by an active
           attacker it would result in a failure to confirm the message
           sent by the other party, since the Ciphersuite is bound by
           each side into its confirm message, and the protocol would
           fail as a result.

       *   confidentiality: none of the messages sent in this protocol
           are encrypted.

       *   integrity protection: messages in the EAP-pwd-Commit exchange
           are not integrity protected.

       *   channel binding: this protocol does not enable the exchange
           of integrity-protected channel information that can be
           compared with values communicated via out-of-band mechanisms.

       *   fast reconnect: this protocol does not provide a fast-
           reconnect capability.

       *   cryptographic binding: this protocol is not a tunneled EAP
           method and therefore has no cryptographic information to
           bind.

       *   identity protection: the EAP-pwd-ID exchange is not
           protected.  An attacker will see the server's identity in the
           EAP-pwd-ID/Request and see the peer's identity in EAP-pwd-ID/
           Response.

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

   The authors would like to thank Scott Fluhrer for discovering the
   "password as exponent" attack that was possible in the initial
   version of this memo and for his very helpful suggestions on the
   techniques for fixing the PWE/pwe to prevent it.  The authors would
   also like to thank Hideyuki Suzuki for his insight in discovering an
   attack against a previous version of the underlying key exchange
   protocol.  Special thanks to Lily Chen for helpful discussions on
   hashing into an elliptic curve and to Jin-Meng Ho for suggesting the
   countermeasures to protect against a small sub-group attack.  Rich
   Davis suggested the defensive checks to Commit messages, and his
   various comments greatly improved the quality of this memo and the
   underlying key exchange on which it is based.  Scott Kelly suggested
   adding the anti-clogging token to the ID exchange to prevent
   distributed denial-of-service attacks.  Dorothy Stanley provided
   valuable suggestions to improve the quality of this memo.  The
   fragmentation method used was taken from [<a href="./rfc5216" title="&quot;The EAP-TLS Authentication Protocol&quot;">RFC5216</a>].




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


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

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

   [<a id="ref-RFC2119">RFC2119</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-RFC2759">RFC2759</a>]    Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
                <a href="./rfc2759">RFC 2759</a>, January 2000.

   [<a id="ref-RFC3454">RFC3454</a>]    Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", <a href="./rfc3454">RFC 3454</a>,
                December 2002.

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

   [<a id="ref-RFC4013">RFC4013</a>]    Zeilenga, K., "SASLprep: Stringprep Profile for User
                Names and Passwords", <a href="./rfc4013">RFC 4013</a>, February 2005.

   [<a id="ref-RFC4282">RFC4282</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-RFC4634">RFC4634</a>]    Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
                (SHA and HMAC-SHA)", <a href="./rfc4634">RFC 4634</a>, July 2006.

   [<a id="ref-RFC5226">RFC5226</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="./rfc5226">RFC 5226</a>,
                May 2008.

   [<a id="ref-SP800-108">SP800-108</a>]  Chen, L., "Recommendations for Key Derivation Using
                Pseudorandom Functions", NIST Special
                Publication 800-108, April 2008.

   [<a id="ref-SP800-56A">SP800-56A</a>]  Barker, E., Johnson, D., and M. Smid, "Recommendations
                for Pair-Wise Key Establishment Schemes Using Discrete
                Logarithm Cryptography", NIST Special
                Publication 800-56A, March 2007.

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

   [<a id="ref-APPCRY">APPCRY</a>]     Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook
                of Applied Cryptography", CRC Press Series on Discrete
                Mathematics and Its Applications, 1996.






<span class="grey">Harkins &amp; Zorn                Informational                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   [<a id="ref-BM92">BM92</a>]       Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
                Password-Based Protocols Secure Against Dictionary
                Attack", Proceedings of the IEEE Symposium on Security
                and Privacy, Oakland, 1992.

   [<a id="ref-BM93">BM93</a>]       Bellovin, S. and M. Merritt, "Augmented Encrypted Key
                Exchange: A Password-Based Protocol Secure against
                Dictionary Attacks and Password File Compromise",
                Proceedings of the 1st ACM Conference on Computer and
                Communication Security, ACM Press, 1993.

   [<a id="ref-BMP00">BMP00</a>]      Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure
                Password Authenticated Key Exchange Using Diffie-
                Hellman", Proceedings of Eurocrypt 2000, LNCS
                1807 Springer-Verlag, 2000.

   [<a id="ref-FIPS-197">FIPS-197</a>]   National Institute of Standards and Technology, FIPS Pub
                197: Advanced Encryption Standard (AES), November 2001.

   [<a id="ref-JAB96">JAB96</a>]      Jablon, D., "Strong Password-Only Authenticated Key
                Exchange", ACM SIGCOMM Computer Communication
                Review Volume 1, Issue 5, October 1996.

   [<a id="ref-LUC97">LUC97</a>]      Lucks, S., "Open Key Exchange: How to Defeat Dictionary
                Attacks Without Encrypting Public Keys", Proceedings of
                the Security Protocols Workshop, LNCS 1361, Springer-
                Verlag, 1997.

   [<a id="ref-RANDOR">RANDOR</a>]     Bellare, M. and P. Rogaway, "Random Oracles are
                Practical: A Paradigm for Designing Efficient
                Protocols", Proceedings of the 1st ACM Conference on
                Computer and Communication Security, ACM Press, 1993.

   [<a id="ref-RFC2409">RFC2409</a>]    Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.

   [<a id="ref-RFC3766">RFC3766</a>]    Orman, H. and P. Hoffman, "Determining Strengths For
                Public Keys Used For Exchanging Symmetric Keys", <a href="https://www.rfc-editor.org/bcp/bcp86">BCP 86</a>,
                <a href="./rfc3766">RFC 3766</a>, April 2004.

   [<a id="ref-RFC4017">RFC4017</a>]    Stanley, D., Walker, J., and B. Aboba, "Extensible
                Authentication Protocol (EAP) Method Requirements for
                Wireless LANs", <a href="./rfc4017">RFC 4017</a>, March 2005.

   [<a id="ref-RFC4086">RFC4086</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.




<span class="grey">Harkins &amp; Zorn                Informational                    [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc5931">RFC 5931</a>                      EAP Password                   August 2010</span>


   [<a id="ref-RFC4962">RFC4962</a>]    Housley, R. and B. Aboba, "Guidance for Authentication,
                Authorization, and Accounting (AAA) Key Management",
                <a href="https://www.rfc-editor.org/bcp/bcp132">BCP 132</a>, <a href="./rfc4962">RFC 4962</a>, July 2007.

   [<a id="ref-RFC5114">RFC5114</a>]    Lepinski, M. and S. Kent, "Additional Diffie-Hellman
                Groups for Use with IETF Standards", <a href="./rfc5114">RFC 5114</a>,
                January 2008.

   [<a id="ref-RFC5216">RFC5216</a>]    Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
                Authentication Protocol", <a href="./rfc5216">RFC 5216</a>, March 2008.

   [<a id="ref-RFC5247">RFC5247</a>]    Aboba, B., Simon, D., and P. Eronen, "Extensible
                Authentication Protocol (EAP) Key Management Framework",
                <a href="./rfc5247">RFC 5247</a>, August 2008.

   [<a id="ref-RFC5869">RFC5869</a>]    Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-
                Expand Key Derivation Function (HKDF)", <a href="./rfc5869">RFC 5869</a>,
                May 2010.

Authors' Addresses

   Dan Harkins
   Aruba Networks
   1322 Crossman Avenue
   Sunnyvale, CA  94089-1113
   USA

   EMail: dharkins@arubanetworks.com


   Glen Zorn
   Network Zen
   1310 East Thomas Street
   #306
   Seattle, WA  98102
   USA

   Phone: +1 (206) 377-9035
   EMail: gwz@net-zen.net












Harkins &amp; Zorn                Informational                    [Page 40]
</pre>