| HTTPAuth | R. Shekh-Yusef |
| Internet-Draft | Avaya |
| Intended status: Standards Track | Y. Sheffer |
| Expires: July 21, 2016 | Intuit |
| January 18, 2016 |
HTTP Secure Remote Password (SRP) Authentication Scheme
draft-yusef-httpauth-srp-scheme-02
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.
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.
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.
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.
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.
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 [RFC2119].
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.
All values in this document are computed modulo large-prime.
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:
The server then discards the derived-private-key and stores the following information in the database: username, hash-algorithm, salt, and password-verifier.
The following flow describes at a high-level the flow of messages based on the challenge-response framework:
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" |
|<-------------------------------------------------------------|
| |
| |
| |
| |
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.
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.
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.
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.
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.
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.
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.
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.
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.
The initial request from the client, that starts the authentication process, MUST include an Authorization header field with the SRP scheme.
The request MUST include the following parameter:
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.
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.
OPEN ISSUE:
{ 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. }
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.
The server calculates the server-public-key as follows:
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:
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:
The client calculates the derived-private-key, random nonce, session-tag, session-key, and client-pop as follows:
The client is expected to retry the request passing an Authorization header field with SRP scheme. The header field MUST include the following parameters:
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.
The server calculates a random nonce and the session-tag as follows:
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:
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.
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:
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:
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.
TBD: https://tools.ietf.org/html/rfc7616#section-3.4.4
TBD: https://tools.ietf.org/html/rfc7616#section-4
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2945] | Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. |
| [SRP6] | Wu, T., "SRP-6: Improvements and Refinements to the Secure Remote Password Protocol", IEEE P1363 Working Group http://srp.stanford.edu/srp6.ps, October 2002. |