HTTP Secure Remote Password (SRP) Authentication Scheme
draft-yusef-httpauth-srp-scheme-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Rifaat Shekh-Yusef , Yaron Sheffer | ||
Last updated | 2015-11-25 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-yusef-httpauth-srp-scheme-01
HTTPAuth R. Shekh-Yusef Internet-Draft Avaya Intended status: Standards Track Y. Sheffer Expires: May 28, 2016 Intuit November 25, 2015 HTTP Secure Remote Password (SRP) Authentication Scheme draft-yusef-httpauth-srp-scheme-01 Abstract 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. Status of This Memo 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 May 28, 2016. Copyright Notice Copyright (c) 2015 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 Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 1] Internet-Draft HTTP SRP Authentication Scheme November 2015 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 ContentsMelnikov & Leiba Expires August 20, 2021 [Page 28] Internet-Draft IMAP4rev2 February 2021 The LOGOUT command informs the server that the client is done with the connection. The server MUST send a BYE untagged response before the (tagged) OK response, and then close the network connection. Example: C: A023 LOGOUT S: * BYE IMAP4rev2 Server logging out S: A023 OK LOGOUT completed (Server and client then close the connection) 6.2. Client Commands - Not Authenticated State In the not authenticated state, the AUTHENTICATE or LOGIN command establishes authentication and enters the authenticated state. The AUTHENTICATE command provides a general mechanism for a variety of authentication techniques, privacy protection, and integrity checking; whereas the LOGIN command uses a traditional user name and plaintext password pair and has no means of establishing privacy protection or integrity checking. The STARTTLS command is an alternative form of establishing session privacy protection and integrity checking, but does not by itself establish authentication or enter the authenticated state. Server implementations MAY allow access to certain mailboxes without establishing authentication. This can be done by means of the ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older convention is a LOGIN command using the userid "anonymous"; in this case, a password is required although the server may choose to accept any password. The restrictions placed on anonymous users are implementation-dependent. Once authenticated (including as anonymous), it is not possible to re-enter not authenticated state. In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in the not authenticated state: STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations (Section 11) for important information about these commands. 6.2.1. STARTTLS Command Arguments: none Responses: no specific response for this command Result: OK - starttls completed, begin TLS negotiation NO - TLS negotiation can't be initiated, due to server configuration error Melnikov & Leiba Expires August 20, 2021 [Page 29] Internet-Draft IMAP4rev2 February 2021 BAD - STARTTLS received after a successful TLS negotiation or arguments invalid Note that STARTTLS command is available only on cleartext ports. The server MUST always respond with tagged BAD response when STARTTLS command is received on Implicit TLS port. A TLS [TLS-1.3] negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete. Some past server implementation incorrectly implemented STARTTLS processing and are known to contain STARTTLS plaintext command injection vulnerability [CERT-555316]. In order to avoid this vulnerability, server implementations MUST do one of the following If any data is received in the same TCP buffer after the CRLF that starts the STARTTLS command: 1. Extra data from the TCP buffer is interpreted as beginning of the TLS handshake. (If the data is in cleartext, this will result in the TLS handshake failing.) 2. Extra data from the TCP buffer is thrown away. Note that the first option is friendlier to clients that pipeline beginning of STARTTLS command with TLS handshake data. After successful TLS negotiation the server remains in the non- authenticated state, even if client credentials are supplied during the TLS negotiation. This does not preclude an authentication mechanism such as EXTERNAL (defined in [SASL]) from using client identity determined by the TLS negotiation. Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities, and in particular SHOULD NOT advertise the STARTTLS capability, after a successful STARTTLS command. Melnikov & Leiba Expires August 20, 2021 [Page 30] Internet-Draft IMAP4rev2 February 2021 Example: C: a001 CAPABILITY S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED S: a001 OK CAPABILITY completed C: a002 STARTTLS S: a002 OK Begin TLS negotiation now <TLS negotiation, further commands are under TLS layer> C: a003 CAPABILITY S: * CAPABILITY IMAP4rev2 AUTH=PLAIN S: a003 OK CAPABILITY completed C: a004 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q= S: a004 OK Success (tls protection) 6.2.2. AUTHENTICATE Command Arguments: SASL authentication mechanism name OPTIONAL initial response Responses: continuation data can be requested Result: OK - authenticate completed, now in authenticated state NO - authenticate failure: unsupported authentication mechanism, credentials rejected BAD - command unknown or arguments invalid, authentication exchange cancelled The AUTHENTICATE command indicates a [SASL] authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the client. It MAY also negotiate an OPTIONAL security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server SHOULD reject the AUTHENTICATE command by sending a tagged NO response. The AUTHENTICATE command supports the optional "initial response" feature defined in Section 5.1 of [SASL]. The client doesn't need to use it. If a SASL mechanism supports "initial response", but it is not specified by the client, the server handles this as specified in Section 3 of [SASL]. The service name specified by this protocol's profile of [SASL] is "imap". The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded (see Section 4 of [RFC4648]) string. The client response Melnikov & Leiba Expires August 20, 2021 [Page 31] Internet-Draft IMAP4rev2 February 2021 consists of a single line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line consisting of a single "*". If the server receives such a response, or if it receives an invalid BASE64 string (e.g. characters outside the BASE64 alphabet, or non-terminal "="), it MUST reject the AUTHENTICATE command by sending a tagged BAD response. As with any other client response, the initial response MUST be encoded as BASE64. It also MUST be transmitted outside of a quoted string or literal. To send a zero-length initial response, the client MUST send a single pad character ("="). This indicates that the response is present, but is a zero-length string. When decoding the BASE64 data in the initial response, decoding errors MUST be treated as in any normal SASL client response, i.e. with a tagged BAD response. In particular, the server should check for any characters not explicitly allowed by the BASE64 alphabet, as well as any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed). If the client uses an initial response with a SASL mechanism that does not support an initial response, the server MUST reject the command with a tagged BAD response. If a security layer is negotiated through the [SASL] authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the tagged OK response for the server. While client and server implementations MUST implement the AUTHENTICATE command itself, it is not required to implement any authentication mechanisms other than the PLAIN mechanism described in [PLAIN]. Also, an authentication mechanism is not required to support any security layers. Note: a server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS command has been negotiated, TLS has been negotiated on an Implicit TLS port, or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping. Client and server implementations SHOULD implement additional [SASL] mechanisms that do not use plaintext passwords, such the GSSAPI mechanism described in [RFC4752], the SCRAM-SHA-256/SCRAM-SHA-256-PLUS [SCRAM-SHA-256] mechanisms and/or EXTERNAL [SASL] mechanism for mutual TLS Melnikov & Leiba Expires August 20, 2021 [Page 32] Internet-Draft IMAP4rev2 February 2021 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Operations Overview . . . . . . . . . . . . . . . . . . . . . 3 3. Initial Request . . . . . . . . . . . . . . . . . . . . . . . 6 4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Username Hashing . . . . . . . . . . . . . . . . . . . . . . 10 8. Internationalization Considerations . . . . . . . . . . . . . 10 9. Integration with Other Protocols . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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 Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 2] Internet-Draft HTTP SRP Authentication Scheme November 2015 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, allowing even weak passphrases to be used safely. 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. 1.1. Terminology 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]. 2. Operations Overview During its setup, the server must choose a large-prime, and as a result the integers from 1 to (large-prime - 1) form a group under multiplication mod large-prime, and a generator for this group is also chosen. 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: derived-private-key = H(username:realm:password:salt) password-verifier = generator ^ derived-private-key Note that all values in this document are computed modulo large- prime. The server then stores the following information in the database: o username o hash-algorithm o salt o password-verifier Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 3] Internet-Draft HTTP SRP Authentication Scheme November 2015 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" | |<-------------------------------------------------------------| | | | | | | | | Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 4] Internet-Draft HTTP SRP Authentication Scheme November 2015 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 authentication scheme. If the client is aware of the realm associated with the protection space it is trying to access, then the client initiates the communication to the server by sending an initial request with an Authorization header with SRP scheme which includes the username parameter associated with that protection space. Otherwise, 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 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 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. Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 5] Internet-Draft HTTP SRP Authentication Scheme November 2015 3. Initial Request The initial request from the client MUST include an Authorization header field with the SRP scheme. If the client is aware of the realm associated with the resource it is trying to access, then the client MUST include the following parameter: username The user's name in a specific realm. Otherwise, the initial 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. 4. Challenge If the initial request received from the client does not have a username parameter, 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. 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. } Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 6] Internet-Draft HTTP SRP Authentication Scheme November 2015 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: server-public-key = H( 3 * password-verifier + generator ^ server- private-key ) 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: large-prime The large prime used to form the finite field GF(n) group, selected by the server during setup, formatted as a decimal integer. generator A finite field GF(n) group generator selected by the server during setup, formatted as a decimal integer. hash-algorithm The hash algorithm used to create the session-key, e.g SHA256. salt A random string used as user's salt. server-public-key The server ephemeral public key associated with the server ephemeral private key. Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 7] Internet-Draft HTTP SRP Authentication Scheme November 2015 5. Response 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: client-public-key = generator ^ client-private-key The client calculates the derived-private-key, random nonce, session- tag, session-key, and client-pop as follows: derived-private-key = H( username:realm:password:salt ) nonce = H( client-public-key : server-public-key ) session-tag = ( server-public-key - 3 * generator ^ derived- private-key) ^ (client-private-key + nonce * derived-private-key ) session-key = H ( session-tag ) client-pop = H( client-public-key : server-public-key : session- tag ) The client is expected to retry the request passing an Authorization header field with SRP scheme. The header field MUST include the following parameters: server-public-key The server ephemeral public key that the client received from the server with the challenge request. client-public-key The client ephemeral public key associated with the client ephemeral private key. client-pop A client proof-of-possession to prove to the server that the client is possession of the session-key. Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 8] Internet-Draft HTTP SRP Authentication Scheme November 2015 6. Confirmation 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: nonce = H( client-public-key : server-public-key ) session-tag = ( client-public-key * password-verifier ^ nonce ) ^ server-private-key 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: expected-client-pop = H( client-public-key : server-public-key : session ) 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: server-pop = H( client-public-key : client-pop : session-tag ) session-key = H ( session-tag ) 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: server-pop A server proof-of-possession to prove to the client that the server is possession of the session-key. Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 9] Internet-Draft HTTP SRP Authentication Scheme November 2015 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. 7. Username Hashing TBD: https://tools.ietf.org/html/draft-ietf-httpauth-digest- 19#section-3.4.4 8. Internationalization Considerations TBD: https://tools.ietf.org/html/draft-ietf-httpauth-digest- 19#section-4 9. Integration with Other Protocols 10. Security Considerations 11. IANA Considerations Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 10] Internet-Draft HTTP SRP Authentication Scheme November 2015 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Authors' Addresses Rifaat Shekh-Yusef Avaya 250 Sidney Street Belleville, Ontario Canada Phone: +1-613-967-5267 EMail: rifaat.ietf@gmail.com Yaron Sheffer Intuit 4 HaHarash St. Hod HaSharon 4524075 Israel EMail: yaronf.ietf@gmail.com Shekh-Yusef & Sheffer Expires May 28, 2016 [Page 11]