<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<!DOCTYPE rfc [
]>

<rfc ipr="pre5378Trust200902"
     docName="draft-yusef-httpauth-srp-scheme-02"
     category="std"
     xml:lang="en">


<!-- FRONT -->


<front>

  <title abbrev="HTTP SRP Authentication Scheme">HTTP Secure Remote
    Password (SRP) Authentication Scheme</title>

  <author initials="R." surname="Shekh-Yusef" fullname="Rifaat Shekh-Yusef">
    <organization>Avaya</organization>
    <address>
      <postal>
        <street>250 Sidney Street</street>
        <city>Belleville</city><region>Ontario</region>
        <country>Canada</country>
      </postal>
      <phone>+1-613-967-5267</phone>
      <email>rifaat.ietf@gmail.com</email>
    </address>
  </author>
  <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
    <organization>Intuit</organization>
    <address>
      <postal>
        <street>4 HaHarash St.</street>
        <city>Hod HaSharon  4524075</city>
        <country>Israel</country>
      </postal>
      <email>yaronf.ietf@gmail.com</email>
    </address>
  </author>

  <date year="2016" />
  <area>RAI</area>
  <workgroup>HTTPAuth</workgroup>
  <keyword>HTTP</keyword>
  <keyword>SRP</keyword>
  <keyword>Secure Remote Password</keyword>
  <keyword>Augmented</keyword>
  <keyword>PAKE</keyword>
  <keyword>Authentication</keyword>

  <abstract><t>
    This document defines an HTTP Authentication Scheme that is based on
    the Secure Remote Password (SRP) protocol. The SRP protocol is an
    Augmented Password Authenticated Key Exchange (PAKE) protocol suitable
    for authenticating users and exchanging keys over an untrusted network.
  </t></abstract>

</front>


<!-- MIDDLE -->

<middle>

  <section title="Introduction" anchor="introduction">

    <t>
      Some protocols (e.g. HTTP [HTTP-P7], SIP [RFC3261],
      OAUTH 2.0 [RFC6749], and STUN [RFC5389]) use a general framework for
      access control and authentication, via a set of challenge-response
      authentication schemes, which can be used by a server to challenge a
      client request and by a client to provide authentication information.
    </t>

    <t>
      Many of these systems that use the challenge-response framework rely
      on passwords chosen by users which usually have low entropy and weak
      randomness, and as a result cannot be used as cryptographic keys.
      While cannot be used directly as cryptographic keys, the passwords
      can still be used to derive cryptographic keys.
    </t>

    <t>
      This document defines an HTTP Authentication Scheme that is based on
      the Secure Remote Password (SRP) protocol. The SRP protocol is an
      Augmented Password Authenticated Key Exchange (PAKE) protocol suitable
      for authenticating users and exchanging keys over an untrusted network,
      based on a shared password, without requiring a Public Key Infrastructure
      (PKI) or any trusted third party.
    </t>

    <t>
      The SRP protocol provides many security benefits: it resists dictionary
      attacks mounted by either passive or active network intruders. It also
      offers perfect forward secrecy, which protects past sessions and
      passwords against future compromises. Finally, user passwords are stored
      in a form that is not plaintext-equivalent to the password itself, so
      an attacker who captures the password database cannot use it directly
      to compromise security and gain immediate access to the host.
    </t>


    <section title="Terminology" anchor="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>

      <t><vspace blankLines="1" /></t>

    </section>

  </section> <!-- Introduction -->


  <section title="Operations Overview" anchor="operations.overview">

  <t>
    The SRP protocol relies on finite field GF(large-prime), which means that
    during its setup, the server must choose a large prime number (large-prime),
    for the integers from 1 to (large-prime - 1) to form a group under
    multiplication modulo large-prime. The server must also choose a primitive
    root modulo large-prime (generator) for this group.
  </t>

  <t>
    All values in this document are computed modulo large-prime.
  </t>

  <t>
    When a user account is created, the server selects a hash function and a user
    salt, and uses a realm and the user password to create a password-verifier as follows:
  </t>

  <t><list>

    <t>derived-private-key = H(username:realm:password:salt)</t>
    <t>password-verifier = generator ^ derived-private-key</t>

  </list></t>

  <t><vspace blankLines="1" /></t>

  <t>
    The server then discards the derived-private-key and stores the following
    information in the database: username, hash-algorithm, salt, and password-verifier.
  </t>


  <t><vspace blankLines="99" /></t>

  <t>
    The following flow describes at a high-level the flow of messages
    based on the challenge-response framework:
  </t>


  <figure><artwork>
  <![CDATA[
   Client                                                       Server
   -------------------------------------------------------------------
     |                                                              |
Discovery of the protection space stage (optional)                  |
     |                                                              |
     | Authorization: SRP                                           |
     |------------------------------------------------------------->|
     |                                                              |
     |                                        WWW-Authenticate: SRP |
     |                                          realm="realm"       |
     |<-------------------------------------------------------------|
     |                                                              |
     |                                                              |
Mutual AuthN and establishment of session-key stage                 |
     |                                                              |
     | Authorization: SRP                                           |
     |   username="username"                                        |
     |------------------------------------------------------------->|
     |                                                              |
     |                      WWW-Authenticate: SRP                   |
     |                        large-prime="large-prime"             |
     |                        generator="generator"                 |
     |                        hash-algorithm="hash-algorithm"       |
     |                        salt="salt",                          |
     |                        server-public-key="server-public-key" |
     |<-------------------------------------------------------------|
     |                                                              |
     |  Authorization: SRP                                          |
     |    server-public-key="server-public-key"                     |
     |    client-public-key="client-public-key"                     |
     |    client-pop="client-pop"                                   |
     |------------------------------------------------------------->|
     |                                                              |
     |                                    WWW-Authenticate: SRP     |
     |                                      server-pop="server-pop" |
     |<-------------------------------------------------------------|
     |                                                              |
     |                                                              |
     |                                                              |
     |                                                              |
  ]]>
  </artwork></figure>

  <t><vspace blankLines="99" /></t>

  <t>
    If the client is not aware of the realm associated with the
    resources it is trying to access, then the initial request will include
    the SRP scheme with no parameters. This will allow the server to discover the
    client's capabilities and to challenge the request and provide the client with the
    realm associated with the resource.
    The client is then expected to retry the request with the username parameter.
  </t>

  <t>
    The client then initiates the authentication process with the server by sending
    an initial request with an Authorization header with SRP scheme which includes the
    username parameter associated with that protection space.
  </t>



  <t>
    The server generates its private key and calculates its associated
    public key, then challenges the request and includes the WWW-Authenticate
    with the large-prime, generator, hash-algorithm, salt, and server-public-key.
  </t>

  <t>
    The client calculates the session-key and re-tries the request
    and includes an Authorization header with client-pop to prove to
    the server that it is in possession of the session-key.
  </t>

  <t>
    The server verifies the client-pop and calculates the server-pop
    to prove to the client that it is in possession of the same session-key.
  </t>

  <t>
    At the end of the above process, the client and the server would have
    established a communication channel after completing a mutual
    authentication, and each side would be in possession of the same session-key.
  </t>


  <t><vspace blankLines="1" /></t>
  </section> <!-- Operations Overview -->



  <section title="Protection Space" anchor="protection.space">

  <t>
    The HTTP Authentication Framework [RFC7235] defines "protection space"
    as a combination of the canonical root URI of the server being accessed
    and the "realm" value. The "realm" values allow the partitioning of the
    server resources into a set of protection spaces, each with its own
    authentication scheme and/or authorization database.
  </t>

  <t>
    A protection space determines the scope of protection covered by a set
    of credentials that can be applied automatically. If a prior request has
    been authorized, then the client may reuse the same credentials for all
    other requests within that protection space, for a period of time
    determined by the server.
  </t>
  </section> <!-- Protection Space -->


  <section title="Discovery Request" anchor="discovery.request">

  <t>
  If the client is not aware of the realm associated with the resource it
  needs to access, then the discovery request MUST be sent without any parameters,
  to allow the server to challenge the request and send the realm to the client.
  The client is then expected to retry the request with the username
  associated with the realm of the resource being accessed to initiate the
  authentication process.
  </t>

  <t><vspace blankLines="1" /></t>
  </section> <!-- Discovery Stage -->

  <section title="Initial Request" anchor="initial.request">

  <t>
    The initial request from the client, that starts the authentication
    process, MUST include an Authorization header field with the SRP scheme.
  </t>

  <t>
    The request MUST include the following parameter:
  </t>

  <t><list>

    <t>
    username
    <list><t>
    The user's name in a specific realm.
    </t></list>
    </t>

  </list></t>


  <t><vspace blankLines="1" /></t>
  </section> <!-- Initial Request -->


  <section title="Challenge" anchor="Challenge">

  <t>
    If a discovery request is received from the client, then the server
    MUST challenge the request by responding with 401 and MUST include
    the realm parameter. The client is expected to retry the request and
    include the username parameter to start the authentication process.
  </t>

  <t>
    When the server receives the request with the username parameter, the
    server looks up the hash-algorithm, salt, and password-verifier
    associated with the username provided by the client in the initial request.
  </t>


  <t>
  OPEN ISSUE:
  </t>
  <t>
{
    To prevent an attacker from identifying the usernames in the DB, if a
    username does not exist in the DB, the server should still go through
    the motion of attempting to authenticate the user and fail it only
    during the last step, to prevent the attacker from recognizing the
    username existence by analyzing how fast the server responds to the
    initial request.
}
  </t>


  <t>
    The server generates a random number, [1, large-prime - 1], as a server
    ephemeral private key (server-private-key), and computes the associated
    server ephemeral public key. The server MUST generate a fresh ephemeral
    private key for each authentication session, even if the request is coming
    from the same user.
  </t>

  <t><vspace blankLines="1" /></t>

  <t>
    The server calculates the server-public-key as follows:
  </t>

  <t>
  <list><t>
  server-public-key = H( 3 * password-verifier + generator ^ server-private-key  )
  </t></list>
  </t>

  <t><vspace blankLines="1" /></t>

  <t>
    The server then challenges the initial request from the client by responding
    with a "401 Unauthorized" status code and a WWW-Authenticate header field
    with and SRP scheme. The header field MUST include the following parameters:
  </t>

  <t><list>

    <t>
    large-prime
    <list><t>
    The large prime used to form the finite field GF(n) group, selected by
    the server during setup, formatted as a decimal integer.
    </t></list>
    </t>

    <t>
    generator
    <list><t>
    A finite field GF(n) group generator selected by the server during setup,
    formatted as a decimal integer.
    </t></list>
    </t>

    <t>
    hash-algorithm
    <list><t>
    The hash algorithm used to create the session-key, e.g SHA256.
    </t></list>
    </t>

    <t>
    salt
    <list><t>
    A random string used as user's salt.
    </t></list>
    </t>

    <t>
    server-public-key
    <list><t>
    The server ephemeral public key associated with the server ephemeral
    private key.
    </t></list>
    </t>


  </list></t>

  <t><vspace blankLines="99" /></t>
  </section> <!-- Challenge -->


  <section title="Response" anchor="response">

  <t>
    The client generates a random number, [1, large-prime - 1],
    as a client ephemeral private key (client-private-key), and computes
    the associated client ephemeral public key as follows:
  </t>

  <t>
  <list><t>
  client-public-key = generator ^ client-private-key
  </t></list>
  </t>


  <t>
    The client calculates the derived-private-key, random nonce, session-tag,
    session-key, and client-pop as follows:
  </t>

  <t>
  <list><t>
  derived-private-key = H( username:realm:password:salt )
  </t></list>
  </t>

  <t>
  <list><t>
  nonce = H( client-public-key : server-public-key )
  </t></list>
  </t>

  <t>
  <list><t>
  session-tag = ( server-public-key - 3 * generator ^ derived-private-key) ^ (client-private-key + nonce * derived-private-key )
  </t></list>
  </t>

  <t>
  <list><t>
  session-key = H ( session-tag )
  </t></list>
  </t>

  <t>
  <list><t>
  client-pop = H( client-public-key : server-public-key : session-tag )
  </t></list>
  </t>

  <t><vspace blankLines="1" /></t>

  <t>
    The client is expected to retry the request passing an Authorization
    header field with SRP scheme. The header field MUST include the following
    parameters:
  </t>

  <t><list>

    <t>
    server-public-key
    <list><t>
    The server ephemeral public key that the client received from the server with the challenge request.
    </t></list>
    </t>


    <t>
    client-public-key
    <list><t>
    The client ephemeral public key associated with the client ephemeral
    private key.
    </t></list>
    </t>

    <t>
    client-pop
    <list><t>
    A client proof-of-possession to prove to the server that the client is
    possession of the session-key.
    </t></list>
    </t>

  </list></t>


  <t><vspace blankLines="99" /></t>
  </section> <!-- Response -->

  <section title="Confirmation" anchor="confirmation">

  <t>
    The server MAY use the server-public-key received from the client to correlate
    this request with the previous response it sent to the client. This especially
    important in the case that this request is received on a different connection than
    the one that delivered the initial request.
  </t>


  <t>
    The server calculates a random nonce and the session-tag as follows:
  </t>

  <t>
  <list><t>
  nonce = H( client-public-key : server-public-key )
  </t></list>
  </t>

  <t>
  <list><t>
  session-tag = ( client-public-key * password-verifier ^ nonce ) ^ server-private-key
  </t></list>
  </t>

  <t><vspace blankLines="1" /></t>

  <t>
  At this stage, the server has enough information to verify the client-pop
  by locally calculating the expected-client-pop and comparing it to the one received
  from the client. The server calculates the expected-client-pop as follows:
  </t>

  <t>
  <list><t>
  expected-client-pop = H( client-public-key : server-public-key : session-tag )
  </t></list>
  </t>

  <t>
    The server then compares the expected-client-pop to the client-pop. If they
    are different, then the server MUST fail the request by responding with a
    "401 Unauthorized" status code and follow the same procedure used with the
    initial request.
  </t>

  <t><vspace blankLines="1" /></t>

  <t>
    If the expected-client-pop is the same as the client-pop received from the client,
    the server continues the process and calculates its server-pop and session-key as follows:
  </t>


  <t>
  <list><t>
  server-pop = H( client-public-key : client-pop : session-tag )
  </t></list>
  </t>

  <t>
  <list><t>
  session-key = H ( session-tag )
  </t></list>
  </t>

  <t><vspace blankLines="1" /></t>

  <t>
    The server then confirms the client's request by responding with 200 OK request.
    The 200 OK message MUST include an Authentication-Info header field with
    the SRP scheme. The header field MUST include the following parameter:
  </t>

  <t><list>
    <t>
    server-pop
    <list><t>
    A server proof-of-possession to prove to the client that the server is
    possession of the session-key.
    </t></list>
    </t>
  </list></t>

  <t><vspace blankLines="1" /></t>

  <t>
    When the client receives the confirmation from the server it verifies the
    server-pop by calculating the expected-server-pop and comparing it to the
    server-pop. If these values are different, then the client MUST consider
    the authentication process to have failed; otherwise, the authentication
    process is complete, and both sides would be in possession of the same
    session-key.
  </t>

  <t><vspace blankLines="1" /></t>
  </section> <!-- Confirmation -->


  <section title="Username Hashing" anchor="unsername.hashing">

  <t>
    TBD: https://tools.ietf.org/html/rfc7616#section-3.4.4
  </t>

  <t><vspace blankLines="1" /></t>
  </section> <!-- Username Hashing -->

  <section title="Internationalization Considerations">

  <t>
     TBD: https://tools.ietf.org/html/rfc7616#section-4
  </t>

  <t><vspace blankLines="1" /></t>
  </section> <!-- Internationalization Considerations -->

  <section title="Integration with Other Protocols" anchor="integration.with.other.protocols">
  <t><vspace blankLines="1" /></t>
  </section> <!-- Integration with Other Protocols -->

  <section title="Security Considerations" anchor="security.considerations">
  <t><vspace blankLines="1" /></t>
  </section> <!-- Security Considerations -->

  <section title="IANA Considerations" anchor="iana.considerations">

  <t><vspace blankLines="99" /></t>
  </section> <!-- IANA Considerations -->

</middle>



<!-- BACK -->

<back>

  <references title="Normative References">

    <reference anchor="RFC2119">
      <front>
        <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
        <author initials="S." surname="Bradner" fullname="Scott Bradner" />
        <date month="March" year="1997" />
      </front>
      <seriesInfo name="BCP" value="14" />
      <seriesInfo name="RFC" value="2119" />
    </reference>


    <reference anchor="RFC2945">
      <front>
        <title abbrev="SRP">The SRP Authentication and Key Exchange System</title>
        <author initials="T." surname="Wu" fullname="Thomas Wu" />
        <date month="September" year="2000" />
      </front>
      <seriesInfo name="RFC" value="2945" />
    </reference>

    <reference anchor="SRP6">
      <front>
        <title abbrev="SRP6">SRP-6: Improvements and Refinements to the Secure Remote Password Protocol</title>
        <author initials="T." surname="Wu" fullname="Thomas Wu" />
        <date month="October" year="2002" />
      </front>
      <seriesInfo name="IEEE P1363 Working Group" value="http://srp.stanford.edu/srp6.ps"/>
    </reference>


  </references>

</back>

</rfc>
