draft-ietf-httpauth-scram-auth-10.txt   draft-ietf-httpauth-scram-auth-11.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track November 19, 2015 Intended status: Standards Track November 25, 2015
Expires: May 22, 2016 Expires: May 28, 2016
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-10.txt draft-ietf-httpauth-scram-auth-11.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 May 22, 2016. This Internet-Draft will expire on May 28, 2016.
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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. One round trip reauthentication . . . . . . . . . . . . . . 10 5.1. One round trip reauthentication . . . . . . . . . . . . . . 10
6. Use of Authentication-Info header field with SCRAM . . . . . 11 6. Use of Authentication-Info header field with SCRAM . . . . . 12
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 14 11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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 4, line 27 skipping to change at page 4, line 27
Note that implementations MUST either implement OpaqueString Note that implementations MUST either implement OpaqueString
profile operations from [RFC7613], or disallow use of non US-ASCII profile operations from [RFC7613], or disallow use of non US-ASCII
Unicode codepoints in "str". The latter is a particular case of Unicode codepoints in "str". The latter is a particular case of
compliance with [RFC7613]. compliance with [RFC7613].
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 32 octets for SHA-256 and 20 octets for SHA-1 (see example, it is 32 octets for SHA-256 and 20 octets for SHA-1 (see
[RFC3174]). [RFC6234]).
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 8, line 50 skipping to change at page 8, line 50
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo= data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo=
S: [...Other header fields and resource body...] S: [...Other header fields and resource body...]
In the above example the first client request contains data attribute In the above example the first client request contains data attribute
which base64 decodes as follows: "n,,n=user,r=rOprNGfwEbeRWgbNEkqO" which base64 decodes as follows: "n,,n=user,r=rOprNGfwEbeRWgbNEkqO"
(with no quotes). Server then responds with data attribute which (with no quotes). Server then responds with data attribute which
base64 decodes as follows: "r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF base64 decodes as follows: "r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF
Ilj)hNlF,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096". The next client request Ilj)hNlF,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096". The next client request
contains data attribute which base64 decodes as follows: "c=biws,r=rO contains data attribute which base64 decodes as follows: "c=biws,r=rO
prNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZapWIk4jUhN+Ute9y prNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZapWIk4jUhN+Ute9y
tag9zjfMHgsqmmiz7AndVQ=". An the final server response contains data tag9zjfMHgsqmmiz7AndVQ=". The final server response contains a data
attribute which base64 decodes as follows: attribute which base64 decodes as follows:
"v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=". "v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=".
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-256" 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-256" authentication scheme and the
skipping to change at page 10, line 15 skipping to change at page 10, line 15
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 [RFC5802]) and contains the server part of the "r" attribute (see s-nonce in
optional "ttl" attribute (which contains the "sr" value validity in [RFC5802]) and optional "ttl" attribute (which contains the "sr"
seconds). value validity in 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 the user from earlier remembers "i" and "s" attributes for the user from earlier
authentication exchanges with the server), it can respond to that authentication exchanges with the server), it can respond to that
with "client-final-message". [[CREF1: Should some counter be added with "client-final-message". When constructing the "client-final-
to make "sr" unique for each reauth?]] message" the client constructs the c-nonce part of the "r" attribute
as on initial authentication and the s-nonce part as follows: s-nonce
is a concatenation of nonce-count and the "sr" attribute (in that
order). The nonce-count is a positive integer that that is equal to
the user's "i" attribute on first reauthentication and is incremented
by 1 on each successful re-authentication.
If the server considers the server part of the nonce (the "r" The purpose of the nonce-count is to allow the server to detect
attribute) to be still valid, it will provide access to the requested request replays by maintaining its own copy of this count - if the
resource (assuming the client hash verifies correctly, of course). same nonce-count value is seen twice, then the request is a
However if the server considers that the server part of the nonce is replay.
stale (for example if the "sr" value is used after the "ttl"
seconds), the server returns "401 Unauthorized" containing the SCRAM If the server considers the s-nonce part of the nonce attribute (the
mechanism name with the following attributes: a new "sr", "r" attribute) to be still valid (i.e. the nonce-count part is as
"stale=true" and an optional "ttl". The "stale" attribute signals to expected (see above) and the "sr" part is still fresh), it will
the client that there is no need to ask user for the password. provide access to the requested resource (assuming the client hash
verifies correctly, of course). 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" seconds), the server returns "401
Unauthorized" containing the SCRAM mechanism name with the following
attributes: a new "sr", "stale=true" and an optional "ttl". The
"stale" attribute signals to the client that there is no need to ask
user for the password.
Formally, the "stale" attribute is defined as follows: A flag, Formally, the "stale" attribute is defined as follows: A flag,
indicating that the previous request from the client was rejected indicating that the previous request from the client was rejected
because the nonce value was stale. If stale is TRUE (case- because the nonce value was stale. If stale is TRUE (case-
insensitive), the client may wish to simply retry the request with insensitive), the client may wish to simply retry the request with
a new encrypted response, without reprompting the user for a new a new encrypted response, without reprompting the user for a new
username and password. The server should only set stale to TRUE username and password. The server should only set stale to TRUE
if it receives a request for which the nonce is invalid but with a if it receives a request for which the nonce is invalid but with a
valid digest for that nonce (indicating that the client knows the valid digest for that nonce (indicating that the client knows the
correct username/password). If stale is FALSE, or anything other correct username/password). If stale is FALSE, or anything other
skipping to change at page 11, line 21 skipping to change at page 11, line 33
Digest realm="realm2@example.com", Digest realm="realm2@example.com",
Digest realm="realm3@example.com", Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com", SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com", sr=%hvYDpWUa2RaTCAfuxFIlj)hNlF SCRAM-SHA-256 realm="testrealm@example.com", sr=%hvYDpWUa2RaTCAfuxFIlj)hNlF
SCRAM-SHA-256 realm="testrealm2@example.com", sr=AAABBBCCCDDD, ttl=120 SCRAM-SHA-256 realm="testrealm2@example.com", sr=AAABBBCCCDDD, ttl=120
S: [...] S: [...]
[Client authenticates as usual to realm "testrealm@example.com"] [Client authenticates as usual to realm "testrealm@example.com"]
[Some time later client decides to reauthenticate. [Some time later client decides to reauthenticate.
It will use the cached "i" (4096) and "s" (W22ZaJ0SNY7soEsUEjb6gQ==) from earlies exchanges. It will use the cached "i" (4096) and "s" (W22ZaJ0SNY7soEsUEjb6gQ==)
It will use the server advertised "sr" value as the server part of the "r".] from earlier exchanges. It will use the nonce-value of 4096 together
with the server advertised "sr" value as the server part of the "r".]
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-256 realm="testrealm@example.com", C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhMlJhVENB
SWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3FtbWl6 ZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOXpqZk1IZ3Nx
N0FuZFZRPQo= bW1pejdBbmRWUT0K
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=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo= data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo=
S: [...Other header fields and resource body...] S: [...Other header fields and resource body...]
6. Use of Authentication-Info header field with SCRAM 6. Use of Authentication-Info header field with SCRAM
When used with SCRAM, the Authentication-Info header field is allowed When used with SCRAM, the Authentication-Info header field is allowed
skipping to change at page 12, line 30 skipping to change at page 13, line 30
data = "data=" base64 data = "data=" base64
;; The data attribute value is base64 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.
reauth-s-nonce = nonce-count s-nonce
nonce-count = posit-number
;; posit-number is defined in RFC 5802.
;; The initial value is taken from the "i"
;; attribute for the user and is incremented
;; by 1 on each successful re-authentication.
sid = "sid=" token sid = "sid=" token
;; See token definition in RFC 7235. ;; See token definition in RFC 7235.
stale = "stale=" ( "true" / "false" ) stale = "stale=" ( "true" / "false" )
realm = "realm=" <as defined in RFC 7235> 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
skipping to change at page 15, line 22 skipping to change at page 16, line 34
[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, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<http://www.rfc-editor.org/info/rfc3174>.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
DOI 10.17487/RFC3454, December 2002, DOI 10.17487/RFC3454, December 2002,
<http://www.rfc-editor.org/info/rfc3454>. <http://www.rfc-editor.org/info/rfc3454>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
skipping to change at page 16, line 15 skipping to change at page 17, line 24
[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, (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010, DOI 10.17487/RFC5802, July 2010,
<http://www.rfc-editor.org/info/rfc5802>. <http://www.rfc-editor.org/info/rfc5802>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<http://www.rfc-editor.org/info/rfc5929>. <http://www.rfc-editor.org/info/rfc5929>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>. <http://www.rfc-editor.org/info/rfc7235>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613, Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015, DOI 10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>. <http://www.rfc-editor.org/info/rfc7613>.
 End of changes. 14 change blocks. 
39 lines changed or deleted 62 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/