draft-ietf-httpauth-scram-auth-05.txt   draft-ietf-httpauth-scram-auth-06.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track March 7, 2015 Intended status: Standards Track June 18, 2015
Expires: September 8, 2015 Expires: December 20, 2015
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-05.txt draft-ietf-httpauth-scram-auth-06.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 September 8, 2015. This Internet-Draft will expire on December 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
and "ServerKey" (as defined in the algorithm overview) for each and "ServerKey" (as defined in the algorithm overview) for each
supported cryptographic hash function. supported cryptographic hash function.
o Authentication database: The database used to look up the o Authentication database: The database used to look up the
authentication information associated with a particular identity. authentication information associated with a particular identity.
For application protocols, LDAPv3 (see [RFC4510]) is frequently For application protocols, LDAPv3 (see [RFC4510]) is frequently
used as the authentication database. For network-level protocols used as the authentication database. For network-level protocols
such as PPP or 802.11x, the use of RADIUS [RFC2865] is more such as PPP or 802.11x, the use of RADIUS [RFC2865] is more
common. common.
o Base64: An encoding mechanism defined in [RFC4648] which converts o Base64: An encoding mechanism defined in Section 4 of [RFC4648]
an octet string input to a textual output string which can be which converts an octet string input to a textual output string
easily displayed to a human. The use of base64 in SCRAM is which can be easily displayed to a human. The use of base64 in
restricted to the canonical form with no whitespace. SCRAM is restricted to the canonical form with no whitespace.
o Octet: An 8-bit byte. o Octet: An 8-bit byte.
o Octet string: A sequence of 8-bit bytes. o Octet string: A sequence of 8-bit bytes.
o Salt: A random octet string that is combined with a password o Salt: A random octet string that is combined with a password
before applying a one-way encryption function. This value is used before applying a one-way encryption function. This value is used
to protect passwords that are stored in an authentication to protect passwords that are stored in an authentication
database. database.
skipping to change at page 4, line 32 skipping to change at page 4, line 32
UTF-8. When applying SASLPrep, "str" is treated as a "stored UTF-8. When applying SASLPrep, "str" is treated as a "stored
strings", which means that unassigned Unicode codepoints are strings", which means that unassigned Unicode codepoints are
prohibited (see Section 7 of [RFC3454]). Note that prohibited (see Section 7 of [RFC3454]). Note that
implementations MUST either implement SASLPrep, or disallow use of implementations MUST either implement SASLPrep, or disallow use of
non US-ASCII Unicode codepoints in "str". non US-ASCII Unicode codepoints in "str".
o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
[RFC2104]) using the octet string represented by "key" as the key [RFC2104]) using the octet string represented by "key" as the key
and the octet string "str" as the input string. The size of the and the octet string "str" as the input string. The size of the
result is the hash result size for the hash function in use. For result is the hash result size for the hash function in use. For
example, it is 20 octets for SHA-1 (see [RFC3174]). example, it is 32 octets for SHA-256 and 20 octets for SHA-1 (see
[RFC3174]).
o H(str): Apply the cryptographic hash function to the octet string o H(str): Apply the cryptographic hash function to the octet string
"str", producing an octet string as a result. The size of the "str", producing an octet string as a result. The size of the
result depends on the hash result size for the hash function in result depends on the hash result size for the hash function in
use. use.
o XOR: Apply the exclusive-or operation to combine the octet string o XOR: Apply the exclusive-or operation to combine the octet string
on the left of this operator with the octet string on the right of on the left of this operator with the octet string on the right of
this operator. The length of the output and each of the two this operator. The length of the output and each of the two
inputs will be the same for this use. inputs will be the same for this use.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
exchange. The format of these messages is defined in [RFC5802]. 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-256 authentication mechanism, i.e. an
OPEN ISSUE: Possibly switch to SHA-256 as the mandatory-to- authentication mechanism from the SCRAM family that uses the SHA-256
implement.]] i.e. an authentication mechanism from the SCRAM family hash function as defined in [I-D.hansen-scram-sha256].
that uses the SHA-1 hash function as defined in [RFC3174].
5. SCRAM Authentication Exchange 5. SCRAM Authentication Exchange
HTTP 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. The messages and their attributes value pairs separated by commas. The messages and their attributes
are described below and defined in Section 7. are described below and defined in Section 7.
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-256" / "SCRAM-SHA-1" / other-scram-name
; SCRAM-SHA-1 is registered by this RFC ; SCRAM-SHA-256 and SCRAM-SHA-1 are 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 (no [[CREF1: Replace with SHA-256?]] This is a simple example of a SCRAM-
support for channel bindings, as this feature is not currently SHA-1 authentication exchange (no support for channel bindings, as
supported by HTTP). In the example base64 encoded data is denoted by this feature is not currently supported by HTTP). In the example
'base64(...)' convention. Username 'user' and password 'pencil' are base64 encoded data is denoted by 'base64(...)' convention. Username
used. '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",
skipping to change at page 8, line 48 skipping to change at page 8, line 47
C: [...] C: [...]
S: HTTP/1.1 200 Ok S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD, S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=base64(v=rmF9pqV8S7suAoZWja4dJRkFsKQ=) data=base64(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-256" 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-256" 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 data attribute that contains base64 o The client also includes the data attribute that contains base64
skipping to change at page 9, line 38 skipping to change at page 9, line 36
[RFC5802]. The "server-first-message" contains the user's iteration [RFC5802]. The "server-first-message" contains the user's iteration
count i, the user's salt, and the nonce with a concatenation of the count i, the user's salt, and the nonce with a concatenation of the
client-specified one with a server nonce. [[CREF2: OPEN ISSUE: 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 the "data" received in the previous server response, together with the "data"
attribute containing base64-encoded "client-final-message" data. The attribute containing base64-encoded "client-final-message" data. The
latter has the same nonce and a ClientProof computed using the latter has the same nonce and a ClientProof computed using the
selected hash function (e.g. SHA-1) as explained earlier. selected hash function (e.g. SHA-256) 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 [I-D.ietf-httpbis-auth-info] containing the "data" attribute field [I-D.ietf-httpbis-auth-info] containing the "sid" attribute (as
containing base64-encoded "server-final-message", concluding the received from the client) and the "data" attribute containing
authentication exchange. base64-encoded "server-final-message", concluding the 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:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
When used with SCRAM, the Authentication-Info header field is allowed When used with SCRAM, the Authentication-Info header field is allowed
in the trailer of an HTTP message transferred via chunked transfer- in the trailer of an HTTP message transferred via chunked transfer-
coding. coding.
7. 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>
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-2 = 2base64-char "=="
base64 = *base64-4 [base64-3 / base64-2] base64 = *base64-4 [base64-3 / base64-2]
sr = "sr=" s-nonce sr = "sr=" s-nonce
;; s-nonce is defined in RFC 5802. ;; s-nonce is defined in RFC 5802.
data = "data=" base64 data = "data=" base64
;; The data attribute value is base-64 encoded ;; The data attribute value is base64 encoded
;; SCRAM challenge or response defined in ;; SCRAM challenge or response defined in
;; RFC 5802. ;; RFC 5802.
ttl = "ttl" = 1*DIGIT ttl = "ttl" = 1*DIGIT
;; "sr" value validity in seconds. ;; "sr" value validity in seconds.
;; No leading 0s. ;; No leading 0s.
sid = "sid=" <...> sid = "sid=" token
;; See token definition in RFC 7235.
realm = "realm=" <...as defined in HTTP Authentication...> realm = "realm=" <as defined in RFC 7235>
8. 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
skipping to change at page 14, line 10 skipping to change at page 14, line 11
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-256
Pointer to specification text: [[ this document ]]
Notes (optional): (none)
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)
10. 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. Thank you to Martin Thomson for the idea of adding "ttl" attribute.
Thank you to Julian F. Reschke for corrections regarding use of
Authentication-Info header field.
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.
11. 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
skipping to change at page 15, line 7 skipping to change at page 15, line 15
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.
12. Open Issues 12. Open Issues
Mandatory to implement SCRAM mechanism? Probably will switch to
SHA-256
Should "sid" directive be an attribute or a new HTTP header field Should "sid" directive be an attribute or a new HTTP header field
shared with other HTTP authentication mechanisms? shared with other HTTP authentication mechanisms?
Username/password normalization algorithm needs to be picked. Username/password normalization algorithm needs to be picked, once
Precis WG concludes its work.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.hansen-scram-sha256]
Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL
Mechanisms", draft-hansen-scram-sha256-02 (work in
progress), October 2014.
[I-D.ietf-httpbis-auth-info] [I-D.ietf-httpbis-auth-info]
Reschke, J., "The Hypertext Transfer Protocol (HTTP) Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Authentication-Info and Proxy- Authentication-Info Authentication-Info and Proxy- Authentication-Info
Response Header Fields", draft-ietf-httpbis-auth-info-03 Response Header Fields", draft-ietf-httpbis-auth-info-03
(work in progress), March 2015. (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.
 End of changes. 28 change blocks. 
49 lines changed or deleted 60 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/