draft-ietf-httpauth-scram-auth-01.txt   draft-ietf-httpauth-scram-auth-02.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track October 18, 2013 Intended status: Standards Track July 4, 2014
Expires: April 21, 2014 Expires: January 5, 2015
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-01.txt draft-ietf-httpauth-scram-auth-02.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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 April 21, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 9 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 9
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 16 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 17
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. Internet-Draft Change History . . . . . . . . . . . . . . . . 16 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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 46 skipping to change at page 6, line 15
3. SCRAM Algorithm Overview 3. SCRAM Algorithm Overview
The following is a description of a full HTTP SCRAM authentication The following is a description of a full HTTP SCRAM authentication
exchange. Note that this section omits some details, such as client exchange. Note that this section omits some details, such as client
and server nonces. See Section 5 for more details. and server nonces. See Section 5 for more details.
To begin with, the SCRAM client is in possession of a username and To begin with, the SCRAM client is in possession of a username and
password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends
the username to the server, which retrieves the corresponding the username to the server, which retrieves the corresponding
authentication information, i.e. a salt, StoredKey, ServerKey and the authentication information, i.e. a salt, StoredKey, ServerKey and the
iteration count i. (Note that a server implementation may choose to iteration count i. (Note that a server implementation may choose to
use the same iteration count for all accounts.) The server sends the use the same iteration count for all accounts.) The server sends the
salt and the iteration count to the client, which then computes the salt and the iteration count to the client, which then computes the
following values and sends a ClientProof to the server: following values and sends a ClientProof to the server:
(*) - Note that both the username and the password MUST be encoded in (*) - Note that both the username and the password MUST be encoded in
UTF-8 [RFC3629]. UTF-8 [RFC3629].
Informative Note: Implementors are encouraged to create test cases Informative Note: Implementors are encouraged to create test cases
that use both username passwords with non-ASCII codepoints. In that use both username passwords with non-ASCII codepoints. In
particular, it's useful to test codepoints whose "Unicode particular, it's useful to test codepoints whose "Unicode
skipping to change at page 6, line 43 skipping to change at page 7, line 14
ServerKey. ServerKey.
The AuthMessage is computed by concatenating messages from the The AuthMessage is computed by concatenating messages from the
authentication exchange. The format of these messages is defined in authentication exchange. The format of these messages is defined in
Section 6. Section 6.
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 http:// from the IANA "Hash Function Textual Names" registry (see
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, i.e. an MUST implement the SCRAM-SHA-1 authentication mechanism, i.e. an
authentication mechanism from the SCRAM family that uses the SHA-1 authentication mechanism from the SCRAM family that uses the SHA-1
hash function as defined in [RFC3174]. hash function as defined in [RFC3174].
5. SCRAM Authentication Exchange 5. SCRAM Authentication Exchange
SCRAM is a HTTP Authentication mechanism whose client response 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. Each attribute has a one-letter
name, with the exception of a couple of attributes which are generic name, with the exception of a couple of attributes which are generic
to HTTP authentication, such as "realm" (and "sid"). The messages to HTTP authentication, such as "realm" (and "sid"). The messages
and their attributes are described in Section 5.1, and defined in and their attributes are described in Section 5.1, and defined in
Section 6. Section 6.
challenge-scram = "SCRAM-SHA-1" 1*SP 1#auth-param challenge-scram = scram-name [1*SP 1#auth-param]
; Complies with <challenge> ABNF from I-D.ietf-httpbis-p7-auth. ; Complies with <challenge> ABNF from RFC 7235.
; Included in the WWW-Authenticate header field. ; Included in the WWW-Authenticate header field.
credentials-scram = "SCRAM-SHA-1" 1*SP 1#auth-param credentials-scram = scram-name [1*SP 1#auth-param]
; Complies with <credentials> from I-D.ietf-httpbis-p7-auth ; 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-SHA-1 is registered by this RFC
other-scram-name = "SCRAM-" hash-name
; hash-name is a capitalized form of names from IANA
; "Hash Function Textual Names" registry.
; Additional SCRAM names must be registered in both
; the IANA "SASL mechanisms" 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
when the client doesn't support channel bindings (username 'user' and when the client doesn't support channel bindings (username 'user' and
password 'pencil' are used): password 'pencil' are used):
[...The server might have returned 401 Unauthorized first...] C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
C: GET /resource HTTP/1.1 S: HTTP/1.1 401 Unauthorized
C: Host: server.example.com S: WWW-Authenticate: Digest realm="realm1@host.com",
C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", Digest realm="realm2@host.com",
g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL Digest realm="realm3@host.com",
C: [...] SCRAM-SHA-1 realm="realm3@host.com"
SCRAM-SHA-1 realm="testrealm@host.com"
S: [...]
S: HTTP/1.1 401 Unauthorized C: GET /resource HTTP/1.1
S: WWW-Authenticate: SCRAM-SHA-1 C: Host: server.example.com
realm="testrealm@host.com",sid=AAAABBBBCCCCDDDD, C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com",
r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92, g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL
i=4096 C: [...]
S: [...]
C: GET /resource HTTP/1.1 S: HTTP/1.1 401 Unauthorized
C: Host: server.example.com S: WWW-Authenticate: SCRAM-SHA-1
C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, sid=AAAABBBBCCCCDDDD,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, s=QSXCR+Q6sek8bf92,i=4096
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= S: [...]
C: [...]
S: HTTP/1.1 200 Ok C: GET /resource HTTP/1.1
S: Authentication-Info: SCRAM-SHA-1 C: Host: server.example.com
sid=AAAABBBBCCCCDDDD, C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD,
v=rmF9pqV8S7suAoZWja4dJRkFsKQ= c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
S: [...Other header fields and resource body...] p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: SCRAM-SHA-1
sid=AAAABBBBCCCCDDDD,
v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
S: [...Other header fields and resource body...]
Note that in the example above the client can also initiate SCRAM
authentication without first being prompted by the server.
"SCRAM-SHA-1" authentication starts with sending the "Authorization" "SCRAM-SHA-1" authentication starts with sending the "Authorization"
request header field defined by HTTP/1.1, Part 7 request header field defined by HTTP/1.1, Part 7 [RFC7235] containing
[I-D.ietf-httpbis-p7-auth] containing "SCRAM-SHA-1" authentication "SCRAM-SHA-1" authentication scheme and the following attributes:
scheme and the 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 protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
[I-D.ietf-httpbis-p7-auth]. As specified in As specified in [RFC7235], the "realm" attribute MUST NOT appear
[I-D.ietf-httpbis-p7-auth], 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 "client-first-message" containing:
* a header ("g" attribute) consisting of a flag indicating * a header ("g" attribute) consisting of a flag indicating
whether channel binding is supported-but-not-used, not whether channel binding is supported-but-not-used, not
supported, or used . Note that the "g" attribute always starts supported, or used . Note that the "g" attribute always starts
with "n", "y" or "p", otherwise the message is invalid and with "n", "y" or "p", otherwise the message is invalid and
skipping to change at page 11, line 22 skipping to change at page 12, line 11
client to verify that the server has access to the user's client to verify that the server has access to the user's
authentication information. This value is computed as explained authentication information. This value is computed as explained
in the overview. in the overview.
6. Formal Syntax 6. 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-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <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)> UTF8-4 = <as defined in RFC 3629 (STD 63)>
attr-val = ALPHA "=" value attr-val = ALPHA "=" value
;; Generic syntax of any attribute sent ;; Generic syntax of any attribute sent
;; by server or client ;; by server or client
value = 1*value-char value = 1*value-char
value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 / UTF8-3 / UTF8-4
;; UTF8-char except NUL, "=", and ",". ;; UTF8-char except NUL, "=", and ",".
value-char = value-safe-char / "=" value-char = value-safe-char / "="
printable = %x21-2B / %x2D-7E printable = %x21-2B / %x2D-7E
;; Printable ASCII except ",". ;; Printable ASCII except ",".
;; Note that any "printable" is also ;; Note that any "printable" is also
;; a valid "value". ;; a valid "value".
base64-char = ALPHA / DIGIT / "/" / "+" base64-char = ALPHA / DIGIT / "/" / "+"
base64-4 = 4base64-char base64-4 = 4base64-char
base64-3 = 3base64-char "=" base64-3 = 3base64-char "="
base64-2 = 2base64-char "=="
base64 = *base64-4 [base64-3 / base64-2] base64-2 = 2base64-char "=="
posit-number = %x31-39 *DIGIT base64 = *base64-4 [base64-3 / base64-2]
;; A positive number.
cb-name = 1*(ALPHA / DIGIT / "." / "-") posit-number = %x31-39 *DIGIT
;; See RFC 5056, Section 7. ;; A positive number.
;; E.g., "tls-server-end-point" or
;; "tls-unique".
gs2-cbind-flag = ("p=" cb-name) / "n" / "y" cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; "n" -> client doesn't support channel binding. ;; See RFC 5056, Section 7.
;; "y" -> client does support channel binding ;; E.g., "tls-server-end-point" or
;; but thinks the server does not. ;; "tls-unique".
;; "p" -> client requires channel binding.
;; The selected channel binding follows "p=".
gs2-header = gs2-cbind-flag "," gs2-cbind-flag = ("p=" cb-name) / "n" / "y"
;; GS2 header for SCRAM. ;; "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=".
username = "n=" 1*(value-safe-char / "=2C" / "=3D") gs2-header = gs2-cbind-flag ","
;; Conforms to <value>. ;; GS2 header for SCRAM.
;; Usernames are prepared using SASLPrep.
reserved-mext = "m=" 1*(value-char) username = "n=" 1*(value-safe-char / "=2C" / "=3D")
;; Reserved for signaling mandatory extensions. ;; Conforms to <value>.
;; The exact syntax will be defined in ;; Usernames are prepared using SASLPrep.
;; the future.
channel-binding = "c=" base64 reserved-mext = "m=" 1*(value-char)
;; base64 encoding of cbind-input. ;; Reserved for signaling mandatory extensions.
;; The exact syntax will be defined in
;; the future.
proof = "p=" base64 channel-binding = "c=" base64
;; base64 encoding of cbind-input.
nonce = "r=" c-nonce [s-nonce] proof = "p=" base64
;; Second part provided by server.
c-nonce = printable nonce = "r=" c-nonce [s-nonce]
;; Second part provided by server.
s-nonce = printable c-nonce = printable
salt = "s=" base64 s-nonce = printable
verifier = "v=" base64 salt = "s=" base64
;; base-64 encoded ServerSignature.
iteration-count = "i=" posit-number verifier = "v=" base64
;; A positive number. ;; base-64 encoded ServerSignature.
client-first-message-bare = iteration-count = "i=" posit-number
[reserved-mext ","] ;; A positive number.
username "," nonce ["," extensions]
client-first-message = client-first-message-bare =
"g=" gs2-header client-first-message-bare [reserved-mext ","]
;; Note that this doesn't include "realm" and username "," nonce ["," extensions]
;; other generic HTTP directives.
server-first-message = client-first-message =
[reserved-mext ","] nonce "," salt "," "g=" gs2-header client-first-message-bare
iteration-count ["," extensions] ;; Note that this doesn't include "realm" and
;; Note that this doesn't include "realm", "sid" and ;; other generic HTTP directives.
;; other generic HTTP directives.
client-final-message-without-proof = server-first-message =
channel-binding "," nonce ["," [reserved-mext ","] nonce "," salt ","
extensions] iteration-count ["," extensions]
;; Note that this doesn't include "realm", "sid" and
;; other generic HTTP directives.
client-final-message = client-final-message-without-proof =
client-final-message-without-proof "," proof channel-binding "," nonce [","
;; Note that this doesn't include "sid" and extensions]
;; other generic HTTP directives.
server-error = "e=" server-error-value client-final-message =
client-final-message-without-proof "," proof
;; Note that this doesn't include "sid" and
;; other generic HTTP directives.
server-error-value = "invalid-encoding" / server-error = "e=" server-error-value
"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 server-error-value = "invalid-encoding" /
; Additional error reasons added by extensions "extensions-not-supported" / ; unrecognized 'm' value
; to this document. "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-final-message = (server-error / verifier) server-error-value-ext = value
["," extensions] ; Additional error reasons added by extensions
; to this document.
extensions = attr-val *("," attr-val) server-final-message = (server-error / verifier)
;; All extensions are optional, ["," extensions]
;; i.e., unrecognized attributes
;; not defined in this document
;; MUST be ignored.
cbind-data = 1*OCTET extensions = attr-val *("," attr-val)
;; All extensions are optional,
;; i.e., unrecognized attributes
;; not defined in this document
;; MUST be ignored.
cbind-input = gs2-header [ cbind-data ] cbind-data = 1*OCTET
;; cbind-data MUST be present for
;; gs2-cbind-flag of "p" and MUST be absent cbind-input = gs2-header [ cbind-data ]
;; for "y" or "n". ;; cbind-data MUST be present for
;; gs2-cbind-flag of "p" and MUST be absent
;; for "y" or "n".
7. Security Considerations 7. 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
skipping to change at page 15, line 48 skipping to change at page 16, line 34
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 Scheme Registry defined in HTTP/1.1, Part 7 [RFC7235]:
[I-D.ietf-httpbis-p7-auth]:
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 9. Acknowledgements
This document benefited from discussions on the SASL and Kitten WG This document benefited from discussions on the HTTPAuth, SASL and
mailing lists. The authors would like to specially thank co-authors Kitten WG mailing lists. The authors would like to specially thank
of [RFC5802] from which lots of text was copied. co-authors of [RFC5802] from which lots of text was copied.
Special thank you to Tony Hansen for doing an early implementation
and providing extensive comments on the draft.
10. Design Motivations 10. 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.
skipping to change at page 17, line 5 skipping to change at page 17, line 41
It should be possible to construct a quick reauthentication version It should be possible to construct a quick reauthentication version
of the mechanism that uses fewer round-trips (similar to what Digest of the mechanism that uses fewer round-trips (similar to what Digest
has). has).
12. Internet-Draft Change History 12. Internet-Draft Change History
(RFC Editor: Please delete this section and all subsections.) (RFC Editor: Please delete this section and all subsections.)
Changes since -00 Changes since -00
o
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22
(work in progress), March 2012.
[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 17, line 46 skipping to change at page 18, line 30
[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.
[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
(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
2865, June 2000. 2865, June 2000.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
skipping to change at page 18, line 39 skipping to change at page 19, line 28
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC5803] Melnikov, A., "Lightweight Directory Access Protocol [RFC5803] Melnikov, A., "Lightweight Directory Access Protocol
(LDAP) Schema for Storing Salted Challenge Response (LDAP) Schema for Storing Salted Challenge Response
Authentication Mechanism (SCRAM) Secrets", RFC 5803, July Authentication Mechanism (SCRAM) Secrets", RFC 5803, July
2010. 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/channel- bindings", IANA http://www.iana.org/assignments/
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
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 61 change blocks. 
176 lines changed or deleted 199 lines changed or added

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