draft-ietf-httpauth-scram-auth-04.txt   draft-ietf-httpauth-scram-auth-05.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track November 10, 2014 Intended status: Standards Track March 7, 2015
Expires: May 14, 2015 Expires: September 8, 2015
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-04.txt draft-ietf-httpauth-scram-auth-05.txt
Abstract Abstract
The secure authentication mechanism most widely deployed and used by The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS). passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism, There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the HTTP authentication mechanism protected by TLS. Unfortunately, the HTTP
Digest challenge response mechanism presently on the standards track Digest challenge response mechanism presently on the standards track
failed widespread deployment, and have had success only in limited failed widespread deployment, and have had success only in limited
use. use.
This specification describes a family of HTTP authentication This specification describes a family of HTTP authentication
mechanisms called the Salted Challenge Response Authentication mechanisms called the Salted Challenge Response Authentication
Mechanism (SCRAM), which addresses the security concerns and meets Mechanism (SCRAM), which addresses security concerns with HTTP Digest
the deployability requirements. When used in combination with TLS or and meets the deployability requirements. When used in combination
an equivalent security layer, a mechanism from this family could with TLS or an equivalent security layer, a mechanism from this
improve the status-quo for application protocol authentication. family could improve the status-quo for HTTP authentication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2015. This Internet-Draft will expire on September 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . 2 1. Conventions Used in This Document . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. One round trip reauthentication . . . . . . . . . . . . . . 10 5.1. One round trip reauthentication . . . . . . . . . . . . . . 10
5.2. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 11 6. Use of Authentication-Info header field with SCRAM . . . . . 11
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 19 11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 14
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. Internet-Draft Change History . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Conventions Used in This Document 1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Formal syntax is defined by [RFC5234] including the core rules Formal syntax is defined by [RFC5234] including the core rules
defined in Appendix B of [RFC5234]. defined in Appendix B of [RFC5234].
skipping to change at page 5, line 28 skipping to change at page 5, line 28
with dkLen == output length of HMAC() == output length of H(). with dkLen == output length of HMAC() == output length of H().
2. Introduction 2. Introduction
This specification describes a family of authentication mechanisms This specification describes a family of authentication mechanisms
called the Salted Challenge Response Authentication Mechanism (SCRAM) called the Salted Challenge Response Authentication Mechanism (SCRAM)
which addresses the requirements necessary to deploy a challenge- which addresses the requirements necessary to deploy a challenge-
response mechanism more widely than past attempts (see [RFC5802]). response mechanism more widely than past attempts (see [RFC5802]).
When used in combination with Transport Layer Security (TLS, see When used in combination with Transport Layer Security (TLS, see
[RFC5246]) or an equivalent security layer, a mechanism from this [RFC5246]) or an equivalent security layer, a mechanism from this
family could improve the status-quo for application protocol family could improve the status-quo for HTTP authentication.
authentication.
SCRAM provides the following protocol features: HTTP SCRAM is adoptation of [RFC5802] for use in HTTP. (SCRAM data
exchanged is identical to what is defined in [RFC5802].) It also
adds 1 round trip reauthentication mode.
HTTP SCRAM provides the following protocol features:
o The authentication information stored in the authentication o The authentication information stored in the authentication
database is not sufficient by itself (without a dictionary attack) database is not sufficient by itself (without a dictionary attack)
to impersonate the client. The information is salted to prevent a to impersonate the client. The information is salted to prevent a
pre-stored dictionary attack if the database is stolen. pre-stored dictionary attack if the database is stolen.
o The server does not gain the ability to impersonate the client to o The server does not gain the ability to impersonate the client to
other servers (with an exception for server-authorized proxies). other servers (with an exception for server-authorized proxies).
o The mechanism permits the use of a server-authorized proxy without o The mechanism permits the use of a server-authorized proxy without
skipping to change at page 7, line 6 skipping to change at page 7, line 6
and verifying the correctness of the ClientKey by applying the hash and verifying the correctness of the ClientKey by applying the hash
function and comparing the result to the StoredKey. If the ClientKey function and comparing the result to the StoredKey. If the ClientKey
is correct, this proves that the client has access to the user's is correct, this proves that the client has access to the user's
password. password.
Similarly, the client authenticates the server by computing the Similarly, the client authenticates the server by computing the
ServerSignature and comparing it to the value sent by the server. If ServerSignature and comparing it to the value sent by the server. If
the two are equal, it proves that the server had access to the user's the two are equal, it proves that the server had access to the user's
ServerKey. ServerKey.
The AuthMessage is computed by concatenating messages from the For initial authentication the AuthMessage is computed by
authentication exchange. The format of these messages is defined in concatenating decoded "data" attribute values from the authentication
Section 6. exchange. The format of these messages is defined in [RFC5802].
4. SCRAM Mechanism Names 4. SCRAM Mechanism Names
A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" A SCRAM mechanism name (authentication scheme) is a string "SCRAM-"
followed by the uppercased name of the underlying hash function taken followed by the uppercased name of the underlying hash function taken
from the IANA "Hash Function Textual Names" registry (see from the IANA "Hash Function Textual Names" registry (see
http://www.iana.org) . http://www.iana.org) .
For interoperability, all HTTP clients and servers supporting SCRAM For interoperability, all HTTP clients and servers supporting SCRAM
MUST implement the SCRAM-SHA-1 authentication mechanism, [[CREF1: MUST implement the SCRAM-SHA-1 authentication mechanism, [[CREF1:
OPEN ISSUE: Possibly switch to SHA-256 as the mandatory-to- OPEN ISSUE: Possibly switch to SHA-256 as the mandatory-to-
implement.]] i.e. an authentication mechanism from the SCRAM family implement.]] i.e. an authentication mechanism from the SCRAM family
that uses the SHA-1 hash function as defined in [RFC3174]. that uses the SHA-1 hash function as defined in [RFC3174].
5. SCRAM Authentication Exchange 5. SCRAM Authentication Exchange
SCRAM is a HTTP Authentication mechanism whose client response HTTP SCRAM is a HTTP Authentication mechanism whose client response
(<credentials-scram>) and server challenge (<challenge-scram>) (<credentials-scram>) and server challenge (<challenge-scram>)
messages are text-based messages containing one or more attribute- messages are text-based messages containing one or more attribute-
value pairs separated by commas. Each attribute has a one-letter value pairs separated by commas. The messages and their attributes
name, with the exception of a couple of attributes which are generic are described below and defined in Section 7.
to HTTP authentication, such as "realm" (and "sid"). The messages
and their attributes are described in Section 5.2, and defined in
Section 6.
challenge-scram = scram-name [1*SP 1#auth-param] challenge-scram = scram-name [1*SP 1#auth-param]
; Complies with <challenge> ABNF from RFC 7235. ; Complies with <challenge> ABNF from RFC 7235.
; Included in the WWW-Authenticate header field. ; Included in the WWW-Authenticate header field.
credentials-scram = scram-name [1*SP 1#auth-param] credentials-scram = scram-name [1*SP 1#auth-param]
; Complies with <credentials> from RFC 7235. ; Complies with <credentials> from RFC 7235.
; Included in the Authorization header field. ; Included in the Authorization header field.
scram-name = "SCRAM-SHA-1" / other-scram-name scram-name = "SCRAM-SHA-1" / other-scram-name
; SCRAM-SHA-1 is registered by this RFC ; SCRAM-SHA-1 is registered by this RFC
other-scram-name = "SCRAM-" hash-name other-scram-name = "SCRAM-" hash-name
; hash-name is a capitalized form of names from IANA ; hash-name is a capitalized form of names from IANA
; "Hash Function Textual Names" registry. ; "Hash Function Textual Names" registry.
; Additional SCRAM names must be registered in both ; Additional SCRAM names must be registered in both
; the IANA "SASL mechanisms" registry ; the IANA "SASL mechanisms" registry
; and the IANA "authentication scheme" registry. ; and the IANA "authentication scheme" registry.
This is a simple example of a SCRAM-SHA-1 authentication exchange This is a simple example of a SCRAM-SHA-1 authentication exchange (no
when the client doesn't support channel bindings (username 'user' and support for channel bindings, as this feature is not currently
password 'pencil' are used): supported by HTTP). In the example base64 encoded data is denoted by
'base64(...)' convention. Username 'user' and password 'pencil' are
used.
C: GET /resource HTTP/1.1 C: GET /resource HTTP/1.1
C: Host: server.example.com C: Host: server.example.com
C: [...] C: [...]
S: HTTP/1.1 401 Unauthorized S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@host.com", S: WWW-Authenticate: Digest realm="realm1@host.com",
Digest realm="realm2@host.com", Digest realm="realm2@host.com",
Digest realm="realm3@host.com", Digest realm="realm3@host.com",
SCRAM-SHA-1 realm="realm3@host.com", SCRAM-SHA-1 realm="realm3@host.com",
SCRAM-SHA-1 realm="testrealm@host.com" SCRAM-SHA-1 realm="testrealm@host.com"
S: [...] S: [...]
C: GET /resource HTTP/1.1 C: GET /resource HTTP/1.1
C: Host: server.example.com C: Host: server.example.com
C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com",
g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL data=base64(n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL)
C: [...] C: [...]
S: HTTP/1.1 401 Unauthorized S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: SCRAM-SHA-1 S: WWW-Authenticate: SCRAM-SHA-1
sid=AAAABBBBCCCCDDDD,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, sid=AAAABBBBCCCCDDDD,
s=QSXCR+Q6sek8bf92,i=4096 data=base64(r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
s=QSXCR+Q6sek8bf92,i=4096)
S: [...] S: [...]
C: GET /resource HTTP/1.1 C: GET /resource HTTP/1.1
C: Host: server.example.com C: Host: server.example.com
C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD,
c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, data=base64(c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=)
C: [...] C: [...]
S: HTTP/1.1 200 Ok S: HTTP/1.1 200 Ok
S: Authentication-Info: SCRAM-SHA-1 S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
sid=AAAABBBBCCCCDDDD, data=base64(v=rmF9pqV8S7suAoZWja4dJRkFsKQ=)
v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
S: [...Other header fields and resource body...] S: [...Other header fields and resource body...]
Note that in the example above the client can also initiate SCRAM Note that in the example above the client can also initiate SCRAM
authentication without first being prompted by the server. authentication without first being prompted by the server.
Initial "SCRAM-SHA-1" authentication starts with sending the Initial "SCRAM-SHA-1" authentication starts with sending the
"Authorization" request header field defined by HTTP/1.1, Part 7 "Authorization" request header field defined by HTTP/1.1, Part 7
[RFC7235] containing "SCRAM-SHA-1" authentication scheme and the [RFC7235] containing "SCRAM-SHA-1" authentication scheme and the
following attributes: following attributes:
o A "realm" attribute MAY be included to indicate the scope of o A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
As specified in [RFC7235], the "realm" attribute MUST NOT appear As specified in [RFC7235], the "realm" attribute MUST NOT appear
more than once. The realm attribute only appears in the first more than once. The realm attribute only appears in the first
SCRAM message to the server and in the first SCRAM response from SCRAM message to the server and in the first SCRAM response from
the server. the server.
o The client also includes the "client-first-message" containing: o The client also includes the data attribute that contains base64
encoded "client-first-message" [RFC5802] containing:
* a header ("g" attribute) consisting of a flag indicating * a header consisting of a flag indicating whether channel
whether channel binding is supported-but-not-used, not binding is supported-but-not-used, not supported, or used .
supported, or used . Note that the "g" attribute always starts Note that the header always starts with "n", "y" or "p",
with "n", "y" or "p", otherwise the message is invalid and otherwise the message is invalid and authentication MUST fail.
authentication MUST fail.
* SCRAM username and a random, unique nonce attributes. * SCRAM username and a random, unique nonce attributes.
In HTTP response, the server sends WWW-Authenticate header field In HTTP response, the server sends WWW-Authenticate header field
containing: a unique session identifier (the "sid" attribute) plus containing: a unique session identifier (the "sid" attribute) plus
the "server-first-message" containing the user's iteration count i, the "data" attribute containing base64-encoded "server-first-message"
the user's salt, and the nonce with a concatenation of the client- [RFC5802]. The "server-first-message" contains the user's iteration
specified one with a server nonce. [[CREF2: OPEN ISSUE: count i, the user's salt, and the nonce with a concatenation of the
client-specified one with a server nonce. [[CREF2: OPEN ISSUE:
Alternatively, the "sid" attribute can be another header field.]] Alternatively, the "sid" attribute can be another header field.]]
The client then responds with another HTTP request with the The client then responds with another HTTP request with the
Authorization header field, which includes the "sid" attribute Authorization header field, which includes the "sid" attribute
received in the previous server response, together with "client- received in the previous server response, together with the "data"
final-message" data. The latter has the same nonce and a ClientProof attribute containing base64-encoded "client-final-message" data. The
computed using the selected hash function (SHA-1) as explained latter has the same nonce and a ClientProof computed using the
earlier. selected hash function (e.g. SHA-1) as explained earlier.
The server verifies the nonce and the proof, and, finally, it The server verifies the nonce and the proof, and, finally, it
responds with a 200 HTTP response with the Authentication-Info header responds with a 200 HTTP response with the Authentication-Info header
field containing "server-final-message", concluding the field [I-D.ietf-httpbis-auth-info] containing the "data" attribute
containing base64-encoded "server-final-message", concluding the
authentication exchange. authentication exchange.
The client then authenticates the server by computing the The client then authenticates the server by computing the
ServerSignature and comparing it to the value sent by the server. If ServerSignature and comparing it to the value sent by the server. If
the two are different, the client MUST consider the authentication the two are different, the client MUST consider the authentication
exchange to be unsuccessful and it might have to drop the connection. exchange to be unsuccessful and it might have to drop the connection.
5.1. One round trip reauthentication 5.1. One round trip reauthentication
If the server supports SCRAM reauthentication, the server sends in If the server supports SCRAM reauthentication, the server sends in
its initial HTTP response a WWW-Authenticate header field containing: its initial HTTP response a WWW-Authenticate header field containing:
the "realm" attribute (as defined earlier), the "sr" attribute that the "realm" attribute (as defined earlier), the "sr" attribute that
contains the server part of the "r" attribute (see Section 5.2 and contains the server part of the "r" attribute (see [RFC5802] and
optional "ttl" attribute (which contains the "sr" value validity in optional "ttl" attribute (which contains the "sr" value validity in
seconds). seconds).
If the client has authenticated to the same realm before (i.e. it If the client has authenticated to the same realm before (i.e. it
remembers "i" and "s" attributes for a user from earlies remembers "i" and "s" attributes for the user from earlies
authentication exchanges with the server), it can respond to that authentication exchanges with the server), it can respond to that
with "client-final-message". with "client-final-message". [[CREF3: Should some counter be added
to make "sr" unique for each reauth?]]
If the server considers the server part of the nonce (the "r" If the server considers the server part of the nonce (the "r"
attribute) to be still valid, it will provide access to the requested attribute) to be still valid, it will provide access to the requested
resource (assuming the client hash verifies correctly, of course). resource (assuming the client hash verifies correctly, of course).
However if the server considers that the server part of the nonce is However if the server considers that the server part of the nonce is
stale (for example if the "sr" value is used after the "ttl" stale (for example if the "sr" value is used after the "ttl"
seconds), the server returns "401 Unauthorized" containing the SCRAM seconds), the server returns "401 Unauthorized" containing the SCRAM
mechanism name with a new "sr" and optional "ttl" attributes. mechanism name with a new "sr" and optional "ttl" attributes.
[[CREF4: Do we also need the "stale" attribute, like the one used by
DIGEST?]]
When constructing AuthMessage Section 3 to be used for calculating
client and server proofs, "client-first-message-bare" and "server-
first-message" are reconstructed from data known to the client and
the server.
Reauthentication can look like this: Reauthentication can look like this:
C: GET /resource HTTP/1.1 C: GET /resource HTTP/1.1
C: Host: server.example.com C: Host: server.example.com
C: [...] C: [...]
S: HTTP/1.1 401 Unauthorized S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@host.com", S: WWW-Authenticate: Digest realm="realm1@host.com",
Digest realm="realm2@host.com", Digest realm="realm2@host.com",
Digest realm="realm3@host.com", Digest realm="realm3@host.com",
SCRAM-SHA-1 realm="realm3@host.com", SCRAM-SHA-1 realm="realm3@host.com",
SCRAM-SHA-1 realm="testrealm@host.com", sr=3rfcNHYJY1ZVvWVs7j SCRAM-SHA-1 realm="testrealm@host.com", sr=3rfcNHYJY1ZVvWVs7j
SCRAM-SHA-1 realm="testrealm2@host.com", sr=AAABBBCCCDDD, ttl=120 SCRAM-SHA-1 realm="testrealm2@host.com", sr=AAABBBCCCDDD, ttl=120
S: [...] S: [...]
[Client authenticates as usual to realm "testrealm@host.com"] [Client authenticates as usual to realm "testrealm@host.com"]
[Some time later client decides to reauthenticate. [Some time later client decides to reauthenticate.
It will use the cached "i" and "s" from earlies exchanges. It will use the cached "i" and "s" from earlies exchanges.
It will use the server advertised "sr" value as the server part of the "r". It will use the server advertised "sr" value as the server part of the "r".]
Should some counter be added to make "sr" unique for each reauth???]
C: GET /resource HTTP/1.1 C: GET /resource HTTP/1.1
C: Host: server.example.com C: Host: server.example.com
C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com",
c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, data=base64(c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=)
C: [...] C: [...]
S: HTTP/1.1 200 Ok S: HTTP/1.1 200 Ok
S: Authentication-Info: SCRAM-SHA-1 S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
sid=AAAABBBBCCCCDDDD, data=base64(v=rmF9pqV8S7suAoZWja4dJRkFsKQ=)
v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
S: [...Other header fields and resource body...] S: [...Other header fields and resource body...]
5.2. SCRAM Attributes 6. Use of Authentication-Info header field with SCRAM
This section describes the permissible attributes, their use, and the
format of their values. All attribute names are single US-ASCII
letters and are case-sensitive.
Note that the order of attributes in client or server messages is
fixed, with the exception of extension attributes (described by the
"extensions" ABNF production), which can appear in any order in the
designated positions. See the ABNF section for authoritative
reference.
o g: This attribute value consist of a flag indicating whether
channel binding is supported-but-not-used, not supported, or used
.
o n: This attribute specifies the name of the user whose password is
used for authentication. A client MUST include it in its first
message to the server.
Before sending the username to the server, the client SHOULD
prepare the username using the "SASLPrep" profile [RFC4013] of
the "stringprep" algorithm [RFC3454] treating it as a query
string (i.e., unassigned Unicode code points are allowed). If
the preparation of the username fails or results in an empty
string, the client SHOULD abort the authentication exchange
(*).
(*) An interactive client can request a repeated entry of the
username value.
Upon receipt of the username by the server, the server MUST
either prepare it using the "SASLPrep" profile [RFC4013] of the
"stringprep" algorithm [RFC3454] treating it as a query string
(i.e., unassigned Unicode codepoints are allowed) or otherwise
be prepared to do SASLprep-aware string comparisons and/or
index lookups. If the preparation of the username fails or
results in an empty string, the server SHOULD abort the
authentication exchange. Whether or not the server prepares
the username using "SASLPrep", it MUST use it as received in
hash calculations.
The characters ',' or '=' in usernames are sent as '=2C' and
'=3D' respectively. If the server receives a username which
contains '=' not followed by either '2C' or '3D', then the
server MUST fail the authentication.
o m: This attribute is reserved for future extensibility. In this
version of SCRAM, its presence in a client or a server message
MUST cause authentication failure when the attribute is parsed by
the other end.
o r: This attribute specifies a sequence of random printable ASCII
characters excluding ',' which forms the nonce used as input to
the hash function. No quoting is applied to this string. As
described earlier, the client supplies an initial value in its
first message, and the server augments that value with its own
nonce in its first response. It is important that this value be
different for each authentication (see [RFC4086] for more details
on how to achieve this). The client MUST verify that the initial
part of the nonce used in subsequent messages is the same as the
nonce it initially specified. The server MUST verify that the
nonce sent by the client in the second message is the same as the
one sent by the server in its first message.
o sr: Server component of the nonce (the "r" attribute) when used
for re-authentication.
o c: This REQUIRED attribute specifies the base64-encoded GS2 header
and channel-binding data. It is sent by the client in its second
authentication message. The attribute data consist of:
* the GS2 header from the client's first message (recall that the
GS2 header contains a channel binding flag ). This header is
going to include channel binding type prefix (see [RFC5056]),
if and only if the client is using channel binding;
* followed by the external channel's channel binding data, if and
only if the client is using channel binding.
o s: This attribute specifies the base64-encoded salt used by the
server for this user. It is sent by the server in its first
message to the client.
o i: This attribute specifies an iteration count for the selected
hash function and user, and MUST be sent by the server along with
the user's salt.
For SCRAM-SHA-1 authentication mechanism servers SHOULD
announce a hash iteration-count of at least 4096. Note that a
client implementation MAY cache ClientKey&ServerKey (or just
SaltedPassword) for later reauthentication to the same service,
as it is likely that the server is going to advertise the same
salt value upon reauthentication. This might be useful for
mobile clients where CPU usage is a concern.
o p: This attribute specifies a base64-encoded ClientProof. The
client computes this value as described in the overview and sends
it to the server.
o v: This attribute specifies a base64-encoded ServerSignature. It When used with SCRAM, the Authentication-Info header field is allowed
is sent by the server in its final message, and is used by the in the trailer of an HTTP message transferred via chunked transfer-
client to verify that the server has access to the user's coding.
authentication information. This value is computed as explained
in the overview.
6. Formal Syntax 7. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3"
and "UTF8-4" non-terminal are defined in [RFC3629]. and "UTF8-4" non-terminal are defined in [RFC3629].
ALPHA = <as defined in RFC 5234 appendix B.1> ALPHA = <as defined in RFC 5234 appendix B.1>
DIGIT = <as defined in RFC 5234 appendix B.1> DIGIT = <as defined in RFC 5234 appendix B.1>
UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <as defined in RFC 3629 (STD 63)>
UTF8-4 = <as defined in RFC 3629 (STD 63)>
attr-val = ALPHA "=" value
;; Generic syntax of any attribute sent
;; by server or client
value = 1*value-char
value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
UTF8-2 / UTF8-3 / UTF8-4
;; UTF8-char except NUL, "=", and ",".
value-char = value-safe-char / "="
printable = %x21-2B / %x2D-7E
;; Printable ASCII except ",".
;; Note that any "printable" is also
;; a valid "value".
base64-char = ALPHA / DIGIT / "/" / "+"
base64-4 = 4base64-char
base64-3 = 3base64-char "="
base64-2 = 2base64-char "=="
base64 = *base64-4 [base64-3 / base64-2]
posit-number = %x31-39 *DIGIT
;; A positive number.
cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056, Section 7.
;; E.g., "tls-server-end-point" or
;; "tls-unique".
gs2-cbind-flag = ("p=" cb-name) / "n" / "y"
;; "n" -> client doesn't support channel binding.
;; "y" -> client does support channel binding
;; but thinks the server does not.
;; "p" -> client requires channel binding.
;; The selected channel binding follows "p=".
gs2-header = gs2-cbind-flag ","
;; GS2 header for SCRAM.
username = "n=" 1*(value-safe-char / "=2C" / "=3D")
;; Conforms to <value>.
;; Usernames are prepared using SASLPrep.
reserved-mext = "m=" 1*(value-char)
;; Reserved for signaling mandatory extensions.
;; The exact syntax will be defined in
;; the future.
channel-binding = "c=" base64
;; base64 encoding of cbind-input.
proof = "p=" base64
nonce = "r=" c-nonce [s-nonce]
;; Second part provided by server.
c-nonce = printable
s-nonce = printable
salt = "s=" base64
verifier = "v=" base64
;; base-64 encoded ServerSignature.
iteration-count = "i=" posit-number
;; A positive number.
client-first-message-bare =
[reserved-mext ","]
username "," nonce ["," extensions]
client-first-message =
"g=" gs2-header client-first-message-bare
;; Note that this doesn't include "realm" and
;; other generic HTTP directives.
server-first-message = base64-char = ALPHA / DIGIT / "/" / "+"
[reserved-mext ","] nonce "," salt ","
iteration-count ["," extensions]
;; Note that this doesn't include "realm", "sid" and
;; other generic HTTP directives.
client-final-message-without-proof = base64-4 = 4base64-char
channel-binding "," nonce [","
extensions]
client-final-message = base64-3 = 3base64-char "="
client-final-message-without-proof "," proof
;; Note that this doesn't include "sid" and
;; other generic HTTP directives.
server-error = "e=" server-error-value base64-2 = 2base64-char "=="
server-error-value = "invalid-encoding" / base64 = *base64-4 [base64-3 / base64-2]
"extensions-not-supported" / ; unrecognized 'm' value
"invalid-proof" /
"channel-bindings-dont-match" /
"server-does-support-channel-binding" /
; server does not support channel binding
"channel-binding-not-supported" /
"unsupported-channel-binding-type" /
"unknown-user" /
"invalid-username-encoding" /
; invalid username encoding (invalid UTF-8 or
; SASLprep failed)
"no-resources" /
"other-error" /
server-error-value-ext
; Unrecognized errors should be treated as "other-error".
; In order to prevent information disclosure, the server
; may substitute the real reason with "other-error".
server-error-value-ext = value sr = "sr=" s-nonce
; Additional error reasons added by extensions ;; s-nonce is defined in RFC 5802.
; to this document.
server-final-message = (server-error / verifier) data = "data=" base64
["," extensions] ;; The data attribute value is base-64 encoded
;; SCRAM challenge or response defined in
;; RFC 5802.
extensions = attr-val *("," attr-val) ttl = "ttl" = 1*DIGIT
;; All extensions are optional, ;; "sr" value validity in seconds.
;; i.e., unrecognized attributes ;; No leading 0s.
;; not defined in this document
;; MUST be ignored.
cbind-data = 1*OCTET sid = "sid=" <...>
cbind-input = gs2-header [ cbind-data ] realm = "realm=" <...as defined in HTTP Authentication...>
;; cbind-data MUST be present for
;; gs2-cbind-flag of "p" and MUST be absent
;; for "y" or "n".
7. Security Considerations 8. Security Considerations
If the authentication exchange is performed without a strong security If the authentication exchange is performed without a strong security
layer (such as TLS with data confidentiality), then a passive layer (such as TLS with data confidentiality), then a passive
eavesdropper can gain sufficient information to mount an offline eavesdropper can gain sufficient information to mount an offline
dictionary or brute-force attack which can be used to recover the dictionary or brute-force attack which can be used to recover the
user's password. The amount of time necessary for this attack user's password. The amount of time necessary for this attack
depends on the cryptographic hash function selected, the strength of depends on the cryptographic hash function selected, the strength of
the password and the iteration count supplied by the server. An the password and the iteration count supplied by the server. An
external security layer with strong encryption will prevent this external security layer with strong encryption will prevent this
attack. attack.
skipping to change at page 18, line 23 skipping to change at page 13, line 46
SCRAM does not protect against downgrade attacks of channel binding SCRAM does not protect against downgrade attacks of channel binding
types. The complexities of negotiation a channel binding type, and types. The complexities of negotiation a channel binding type, and
handling down-grade attacks in that negotiation, was intentionally handling down-grade attacks in that negotiation, was intentionally
left out of scope for this document. left out of scope for this document.
A hostile server can perform a computational denial-of-service attack A hostile server can perform a computational denial-of-service attack
on clients by sending a big iteration count value. on clients by sending a big iteration count value.
See [RFC4086] for more information about generating randomness. See [RFC4086] for more information about generating randomness.
8. IANA Considerations 9. IANA Considerations
New mechanisms in the SCRAM- family are registered according to the New mechanisms in the SCRAM- family are registered according to the
IANA procedure specified in [RFC5802]. IANA procedure specified in [RFC5802].
Note to future SCRAM- mechanism designers: each new SCRAM- HTTP Note to future SCRAM- mechanism designers: each new SCRAM- HTTP
authentication mechanism MUST be explicitly registered with IANA and authentication mechanism MUST be explicitly registered with IANA and
MUST comply with SCRAM- mechanism naming convention defined in MUST comply with SCRAM- mechanism naming convention defined in
Section 4 of this document. Section 4 of this document.
IANA is requested to add the following entry to the Authentication IANA is requested to add the following entry to the Authentication
Scheme Registry defined in HTTP/1.1, Part 7 [RFC7235]: Scheme Registry defined in HTTP/1.1, Part 7 [RFC7235]:
Authentication Scheme Name: SCRAM-SHA-1 Authentication Scheme Name: SCRAM-SHA-1
Pointer to specification text: [[ this document ]] Pointer to specification text: [[ this document ]]
Notes (optional): (none) Notes (optional): (none)
9. Acknowledgements 10. Acknowledgements
This document benefited from discussions on the HTTPAuth, SASL and This document benefited from discussions on the HTTPAuth, SASL and
Kitten WG mailing lists. The authors would like to specially thank Kitten WG mailing lists. The authors would like to specially thank
co-authors of [RFC5802] from which lots of text was copied. co-authors of [RFC5802] from which lots of text was copied.
Thank you to Martin Thomson for the idea of adding "ttl" attribute.
Special thank you to Tony Hansen for doing an early implementation Special thank you to Tony Hansen for doing an early implementation
and providing extensive comments on the draft. and providing extensive comments on the draft.
10. Design Motivations 11. Design Motivations
The following design goals shaped this document. Note that some of The following design goals shaped this document. Note that some of
the goals have changed since the initial version of the document. the goals have changed since the initial version of the document.
o The HTTP authentication mechanism has all modern features: support o The HTTP authentication mechanism has all modern features: support
for internationalized usernames and passwords, support for channel for internationalized usernames and passwords, support for channel
bindings. bindings.
o The protocol supports mutual authentication. o The protocol supports mutual authentication.
skipping to change at page 19, line 29 skipping to change at page 15, line 5
o The server does not gain the ability to impersonate the client to o The server does not gain the ability to impersonate the client to
other servers (with an exception for server-authorized proxies), other servers (with an exception for server-authorized proxies),
unless such other servers allow SCRAM authentication and use the unless such other servers allow SCRAM authentication and use the
same salt and iteration count for the user. same salt and iteration count for the user.
o The mechanism is extensible, but [hopefully] not overengineered in o The mechanism is extensible, but [hopefully] not overengineered in
this respect. this respect.
o Easier to implement than HTTP Digest in both clients and servers. o Easier to implement than HTTP Digest in both clients and servers.
11. Open Issues 12. Open Issues
It should be possible to construct a quick reauthentication version
of the mechanism that uses fewer round-trips (similar to what Digest
has).
12. Internet-Draft Change History
(RFC Editor: Please delete this section and all subsections.) Mandatory to implement SCRAM mechanism? Probably will switch to
SHA-256
Changes since -00 Should "sid" directive be an attribute or a new HTTP header field
shared with other HTTP authentication mechanisms?
o Username/password normalization algorithm needs to be picked.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-httpbis-auth-info]
Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Authentication-Info and Proxy- Authentication-Info
Response Header Fields", draft-ietf-httpbis-auth-info-03
(work in progress), March 2015.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
skipping to change at page 20, line 27 skipping to change at page 16, line 5
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, July 2010.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014. (HTTP/1.1): Authentication", RFC 7235, June 2014.
13.2. Informative References 13.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)", RFC
skipping to change at page 21, line 18 skipping to change at page 16, line 47
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 4949, August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC5803] Melnikov, A., "Lightweight Directory Access Protocol
(LDAP) Schema for Storing Salted Challenge Response
Authentication Mechanism (SCRAM) Secrets", RFC 5803, July
2010.
[tls-server-end-point] [tls-server-end-point]
Zhu, L., , "Registration of TLS server end-point channel Zhu, L., , "Registration of TLS server end-point channel
bindings", IANA http://www.iana.org/assignments/ bindings", IANA http://www.iana.org/assignments/
channel-binding-types/tls-server-end-point, July 2008. channel-binding-types/tls-server-end-point, July 2008.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
 End of changes. 54 change blocks. 
330 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/