<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="info" ipr="trust200902"
docName="draft-sheffer-ipsecme-hush-02">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <front>
    <title abbrev="HUSH">HUSH: Using HUmanly memorable SHared secrets with IKEv2</title>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization abbrev="Independent">Independent</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
      <organization abbrev="Cisco">Cisco Systems.</organization>
      <address>
        <postal>
          <street>1414 Massachusetts Ave.</street>
          <city>Boxborough, MA</city>
          <code>01719</code>
          <country>USA</country>
        </postal>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>
    <date year="2011"/>
    <abstract>
      <t>This document defines a new mode for IKEv2, where both peers can authenticate using
      a short, humanly memorable shared secret. This mode is based on the EKE protocol.</t>
    </abstract>
  </front>
  <middle>
    <!-- ************************************************************************************ -->
    <section title="Introduction">
    <t>There is strong interest in a simple method for bootstrapping an IKE
    <xref target="RFC4306"/> security association
    between two peers, requiring neither PKI nor AAA infrastructure. Although IKEv2 supports
    EAP-based authentication in part to provide for this capability, it has been claimed that
    the use of an extra authentication layer/protocol adds little benefit and increases
    complexity.</t>
    <t>This protocol integrates the well known EKE protocol <xref target="BM92"/> into IKEv2,
    to provide password-based authentication. Some of the benefits of this protocol are:</t>
    <t>
    <list style="symbols">
    <t>EKE is a well known protocol, which has had multiple deep cryptographic
    analyses applied to it.</t>
    <t>EKE provides the benefit of a well known, clear IPR status.</t>
    </list>
    </t>
    <t>This protocol is not intended for use in enterprise-scale remote access.
    As a result, only the basic authentication capability is provided.
    Some capabilities
    typically associated with the use of passwords for remote access include: password
    change and expiry, password recovery, and enforcement of password strength policy.</t>
    <t>In this preliminary version of the protocol many issues are not yet covered, such as:</t>
    <t>
    <list style="symbols">
    <t>Integration with other IKE elements, e.g. optional notifications, Session Resumption...</t>
    <t>Error handling.</t>
    <t>Generation of a high-quality PSK, so that the password doesn't need to be used
    for each authentication. Secure signalling of PSK possession.</t>
    <t>Security analysis.</t>
    </list>
    </t>
    </section>
    <!-- ************************************************************************************ -->

    <section title="Terminology">
      <t>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
          <xref target="RFC2119"/>.</t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Overview">
    <t>This protocol attempts to preserve the general structure of IKEv2, minimizing the number
    of new constructs and round trips, while retaining IKE's security guarantees, including
    identity protection. The resulting protocol only adds one round trip to the shared secret
    authentication mode of IKEv2.</t>
    <t>At a high level, the message exchange is as follows:
	<figure>
            <artwork>
              <![CDATA[
        Initiator                           Responder
        ---------                           ---------

HDR, SAi1, KEi, Ni, N(HUSH)

		    <- HDR, SAr1, KEr, Nr, N(HUSH)

HDR, SK{IDi, [IDr,], SAi2, TSi, TSr, Encrypt{Yi}} ->

		    <- HDR, SK{IDr, Encrypt{Yr}, Protect{Nr2}}

HDR, SK{AUTH, Protect{Ni2|Nr2}}

		    <- HDR, SK{AUTH, SAr2, TSi, TSr, Protect{Ni2}}
]]>
            </artwork>
          </figure>
    </t>
    <t>The changes to IKEv2 are summarized in the following list:</t>
    <t>
    <list style="symbols">
    <t>The regular IKE_SA_INIT exchange is followed by a new 2-round trip exchange,
    IKE_HUSH.</t>
    <t>Negotiation of the new mode using notifications in IKE_SA_INIT.</t>
    <t>Negotiation of cryptographic algorithms: the encryption algorithm,
    the integrity protection algorithm and the pseudo-random
    function are the ones
    negotiated for the IKE SA itself, while a new Diffie-Hellman group is selected
    for the HUSH exchange, by extending the SAi1/SAr1 negotiation.</t>
    <t>A new encrypted payload type, denoted Encrypt{},
    for exchanging an ephemeral public key encrypted by
    the password.</t>
    <t>A new encrypted and integrity-protected payload type, denoted Protect{},
    for exchanging nonces encrypted by the EKE shared secret.</t>
    <t>The IKE AUTH payloads provide cryptographic binding of the IKE shared
    secret with the password-based authentication.</t>
    </list>
    </t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Protocol Sequence" anchor="protocol">
    <t>The protocol consists of a slightly extended IKE_SA_INIT exchange, followed by the 4-message
    IKE_HUSH exchange.</t>
	<section title="The IKE_SA_INIT Exchange">
	<t>During this exchange, the initiator sends an empty HUSH_SUPPORTED notification.
	If the responder understands this protocol and wishes to use it, it sends back
	another empty HUSH_SUPPORTED notification.</t>
	<t>In addition, this protocol defines a new transform type for the IKE protocol,
	called "EKE D-H Group". Possible transforms are the EKE groups defined in
	<xref target="dh-groups"/>.
	This transform type is negotiated between the initiator and responder with the usual SAi1,
	SAr1 payloads. If the initiator suspects that the responder does not support
	this protocol, it SHOULD also include a proposal that omits this transform, to allow
	the negotiation to revert to regular IKE. During successful
	negotiation, an EKE D-H Group MUST be negotiated if (and only if)
	the responder indicates support
	for this protocol.</t>
	</section>
	<section title="The IKE_HUSH Exchange">
	<t>This exchange consists of two message pairs, and includes all payloads normally
	contained in the IKE_AUTH exchange. These latter payloads are not described in this
	subsection, in order to focus on the new HUSH payloads.</t>
	<section title="Message #1">
	<t>The initiator computes </t>
	<t>
          <list style="empty">
            <t>Yi = g^x mod N,</t>
          </list>
	</t>
        <t>where x is a randomly chosen number in the range 2 .. N-1, as defined by
	the negotiated Diffie-Hellman group. The randomly chosen number
          is the private key, and the calculated value is the corresponding public key.
          Each of the peers MUST use a
          fresh, random value for x on each run of the protocol.</t>
          <t>Note: If Elliptic Curve Diffie-Hellman is used in a future version of this protocol,
	  the corresponding additive
          group operations are to be understood.</t>
        <t>The initiator generates the Encrypt payload (<xref target="encrypt-payload"/>),</t>
        <t>
          <list style="empty">
            <t>Encrypt(prf+(password, "HUSH Password"), Yi),</t>
          </list>
        </t>
        <t>where the literal string is encoded using ASCII with no zero terminator.
        The prf+ notation is as defined in <xref target="RFC4306"/>.
        When using block ciphers, it may be necessary to pad Yi on the right, to fit
          the encryption algorithm's block size. In such cases, random padding MUST be used, and
          this randomness is critical to the security of the protocol. Randomness recommendations
          can be found in <xref target="RFC4086"/>.</t>
        <t>If the password needs to be stored on the server, it is RECOMMENDED to store the
          randomized password value, i.e. prf+(password, ...), as a password-equivalent, rather than
          the cleartext password.</t>
        <t>
          If the password is non-ASCII, it SHOULD be normalized by the sender before the
          message is constructed. The normalization method is SASLprep, <xref target="RFC4013"/>.
          Note that the password is not null-terminated.
          </t>
	  </section>
	  <section title="Message #2">
	  <t>Similarly to Message #1, the responder picks a random private key, generates an ephemeral
	  public key Yr, encrypts it by the expanded password and includes the resulting Encrypt
	  payload in the message:</t>
        <t>
          <list style="empty">
            <t>Encrypt(prf+(password, "HUSH Password"), Yr),</t>
          </list>
        </t>
        <t>The responder now calculates</t>
        <t>
          <list style="empty">
            <t>EkeSharedSecret = prf(0+, g^(x*y) mod N)</t>
          </list>
        </t>
        <t>where the first argument to "prf" is a string of zero octets whose length
        is the output size of the base hash algorithm,
        e.g. 20 octets for HMAC-SHA1; the result is of the same length.
        This extra
        application of the pseudo-random function is the "extraction step" of
        <xref target="RFC5869"/>.
        </t>
        <t>
        The responder computes the encryption and authentication (integrity protection) keys: </t>
        <t>
          <list style="empty">
            <t>Ke2, Ka2 = prf+(EkeSharedSecret, "HUSH encryption and authentication" | IDi | IDr)</t>
          </list>
        </t>
	<t>Now the responder can generate the Protect payload included in the message:</t>
        <t>
          <list style="empty">
            <t>Protect(Ke2, Ka2, Nr2),</t>
          </list>
        </t>
        <t>where Nr2 is a randomly generated binary string (nonce). Nr2 has length equal to the
          block size of the negotiated encryption algorithm for block ciphers,
          or 32 octets if this algorithm is a stream cipher.
          The responder sends this value as an Encrypt payload.</t>
	</section>
	<section title="Message #3">
	<t>The initiator computes the EkeSharedSecret, Ke2 and Ka2 values as above.</t>
	<t>It then picks a random nonce Ni2, of the same format as Nr2,
	concatenates the two nonces, and generates</t>
        <t>
          <list style="empty">
            <t>Protect(Ke2, Ka2, Ni2 | Nr2),</t>
          </list>
        </t>
	<t>In addition, it computes</t>
        <t>
          <list style="empty">
		<t>
      AUTH = prf(prf(Shared Secret, Ni2 | Nr2 | IDi | IDr), &lt;InitiatorSignedOctets>)
		</t>
	  </list>
        </t>
	<t>where the Shared Secret is the regular IKE shared secret,
	created by the IKE_SA_INIT exchange.</t>
	</section>
	<section title="Message #4">
	<t>The responder verifies Nr2 and the received AUTH payload, and MUST terminate
	the protocol if either of them fails to verify. The responder generates</t>
        <t>
          <list style="empty">
            <t>Protect(Ke2, Ka2, Ni2)</t>
          </list>
        </t>
	<t>and</t>
        <t>
          <list style="empty">
		<t>
      AUTH = prf(prf(Shared Secret, Ni2 | Nr2 | IDi | IDr), &lt;ResponderSignedOctets>)
		</t>
	  </list>
        </t>
	<t>The initiator MUST verify the Ni2 and AUTH values when receiving Message #4.</t>
	</section>
    </section>
    </section>

    <!-- ************************************************************************************ -->
<section title="Protocol Formats">
	<section anchor="encrypt-payload" title="Encrypt Payload">
	<t>This payload contains encrypted, but non-integrity protected, data.
	Unfortunately the simpler term "Encrypted Payload" is used by IKEv2 for a payload
	that contains encrypted and integrity-protected data.</t>
	<t>Compared to the IKE Encrypted Payload, this payload does not contain other
	embedded payloads. The payload is denoted Encrypt(key, data), and defined thus:</t>
        <t>
          <figure title="The Encrypt Payload">
            <artwork>
              <![CDATA[
                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |         (length is block size for encryption algorithm)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Length            |                               ~
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  Encrypted Data               ~
   ~                                                               ~
   ~               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               |                                               ~
   +-+-+-+-+-+-+-+-+      Random Padding (0-255 octets)            ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
            </artwork>
          </figure>
        </t>
	<t>
	<list style="symbols">
	<t>Data Length is a 2 octet length of the encrypted data, exclusive of padding.
	This field itself
	is unencrypted.</t>
	<t>Random Padding MUST indeed be random and unpredictable if it is included.
	This randomness is critical to the security of the protocol.</t>
	</list>
	</t>
	</section>

	<section anchor="protect-payload" title="Protect Payload">
	<t>This payload contains encrypted and integrity protected data.
	</t>
	<t>This payload is identical to the Encrypt Payload (<xref target="encrypt-payload"/>)
	with the addition of an integrity-protection ICV field.
	The payload is denoted by Protect(enc-key, integ-key, data) and defined as follows:</t>
        <t>
          <figure title="The Protect Payload">
            <artwork>
              <![CDATA[
                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |         (length is block size for encryption algorithm)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Data Length            |                               ~
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|  Encrypted Data               ~
   ~                                                               ~
   ~               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               |                                               ~
   +-+-+-+-+-+-+-+-+      Random Padding (0-255 octets)            ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Integrity Check Value (ICV)                  |
   |              (length depends on integrity algorithm)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ]]>
            </artwork>
          </figure>
        </t>
	<t>
	<list style="symbols">
	<t>The Integrity Check Value is computed over the Initialization Vector,
	Data Length, Encrypted Data and
	Random Padding (if any). The length of the field is determined by the negotiated
	integrity algorithm.</t>
	</list>
	</t>
	</section>
</section>

    <!-- ************************************************************************************ -->
<section title="Cryptographic Details">
    <section anchor="dh-groups" title="Diffie-Hellman Groups">
      <t>
Many of the commonly used Diffie Hellman groups are inappropriate for use in EKE.
Most of these groups use a generator which is not a primitive element of the group.
As a result, an attacker running a dictionary attack would be able to learn at least
1 bit of information for each decrypted password guess.
      </t>
      <t>
      Any MODP Diffie Hellman group defined for use in this protocol MUST have the following properties,
      to ensure that it does not leak a usable amount of information about the password:
      <list style="numbers">
      <t>The generator is a primitive element of the group.</t>
      <t>The most significant 64 bits of the prime number are 1.</t>
      <t>The group's order p is a "safe prime", i.e. (p-1)/2 is also prime.
      </t>
      </list>
      </t>
      <t>
      The last requirement is related to the strength of the Diffie Hellman algorithm,
      rather than the password encryption. It also makes it easy to verify that the
      generator is primitive.
      </t>
      <t>
      We have defined the following groups. The Value column is used when negotiating the group.
      Additional groups may be defined through IANA allocation. Future non-MODP groups require
      a document to define their interaction with this protocol.
      </t>
      <texttable>
      <ttcol>Name</ttcol>
      <ttcol>Length</ttcol>
      <ttcol>Value</ttcol>
      <ttcol>Description</ttcol>
      <c>Reserved</c>
      <c></c>
      <c>0</c>
      <c></c>
      <c>DHGROUP_EKE_2</c>
      <c>1024</c>
      <c>1</c>
      <c>The prime number of Group 2 <xref target="RFC4306"/>, with the generator 5 (decimal)</c>
      <c>DHGROUP_EKE_5</c>
      <c>1536</c>
      <c>2</c>
      <c>The prime number of Group 5 <xref target="RFC3526"/>, g=31</c>
      <c>DHGROUP_EKE_14</c>
      <c>2048</c>
      <c>3</c>
      <c>The prime number of Group 14 <xref target="RFC3526"/>, g=11</c>
      <c>DHGROUP_EKE_15</c>
      <c>3072</c>
      <c>4</c>
      <c>The prime number of Group 15 <xref target="RFC3526"/>, g=5</c>
      <c>DHGROUP_EKE_16</c>
      <c>4096</c>
      <c>5</c>
      <c>The prime number of Group 16 <xref target="RFC3526"/>, g=5</c>
      <c>Available for allocation via IANA</c>
      <c></c>
      <c>6-127</c>
      <c></c>
      <c>Reserved for private use</c>
      <c></c>
      <c>128-255</c>
      <c></c>
      </texttable>
      </section>
    </section>
    <!-- ************************************************************************************ -->
    <section title="IANA Considerations" anchor="iana">
	<t>TBD: one notification, one transform type, two payloads, a new exchange.
	Also a new DH group registry.</t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Security Considerations" anchor="security">
	<t>Will be added.</t>
    </section>
    <!-- ************************************************************************************ -->

    <section title="Acknowledgements">
    <t>Much of this protocol is derived from <xref target="I-D.sheffer-emu-eap-eke"/>, and authors
    (and reviewers) of that draft are acknowledged.</t>
    </section>
    <!-- ************************************************************************************ -->
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml"?>
    <?rfc include="reference.RFC.3526.xml"?>
    <?rfc include="reference.RFC.4306.xml"?>
    </references>
    <references title="Informative References">
    <?rfc include="reference.RFC.4013.xml"?>
    <?rfc include="reference.RFC.4086.xml"?>
    <?rfc include="reference.RFC.5869.xml"?>
    <?rfc include="reference.I-D.sheffer-emu-eap-eke.xml"?>
      <reference anchor="BM92">
        <front>
          <title>Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks</title>
          <author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
            <organization/>
          </author>
          <author initials="M." surname="Merritt" fullname="Michael Merritt">
            <organization/>
          </author>
          <date month="May" year="1992"/>
        </front>
        <seriesInfo name="Proc. IEEE Symp. on Research in Security and Privacy" value=""/>
      </reference>
      <reference anchor="BM93">
        <front>
          <title>Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against
            Dictionary Attacks and Password File Compromise</title>
          <author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
            <organization/>
          </author>
          <author initials="M." surname="Merritt" fullname="Michael Merritt">
            <organization/>
          </author>
          <date year="1993"/>
        </front>
        <seriesInfo name="Proc. 1st ACM Conference on Computer and Communication Security" value=""
        />
      </reference>
      <reference anchor="BMP00">
        <front>
          <title>Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman</title>
          <author initials="V." surname="Boyko" fullname="Victor Boyko">
            <organization/>
          </author>
          <author initials="P." surname="MacKenzie" fullname="Philip MacKenzie">
            <organization/>
          </author>
          <author initials="S." surname="Patel" fullname="Sarvar Patel">
            <organization/>
          </author>
          <date year="2000"/>
        </front>
        <seriesInfo name="Advances in Cryptology, EUROCRYPT 2000"
          value=""/>
      </reference>
      <reference anchor="PA97">
        <front>
          <title>Number Theoretic Attacks On Secure Password Schemes</title>
          <author initials="S." surname="Patel" fullname="Sarvar Patel">
            <organization/>
          </author>
          <date year="1997"/>
        </front>
        <seriesInfo name="Proceedings of the 1997 IEEE Symposium on Security and Privacy"
          value=""/>
      </reference>
    </references>
    <!-- ************************************************************************************ -->
    <section title="Change Log">
    <t>Note to RFC Editor: please remove this section before publication.</t>
      <section title="-01">
        <t>Reissued, changed the derivation of the payload encryption and authentication keys.</t>
      </section>
      <section title="-00">
        <t>Initial version, a very rough draft.</t>
      </section>
    </section>
  </back>
</rfc>
