draft-ietf-httpauth-scram-auth-07.txt   draft-ietf-httpauth-scram-auth-08.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track July 26, 2015 Intended status: Standards Track October 18, 2015
Expires: January 27, 2016 Expires: April 20, 2016
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-07.txt draft-ietf-httpauth-scram-auth-08.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 January 27, 2016. This Internet-Draft will expire on April 20, 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 4, line 20 skipping to change at page 4, line 20
o ":=": The variable on the left hand side represents the octet o ":=": The variable on the left hand side represents the octet
string resulting from the expression on the right hand side. string resulting from the expression on the right hand side.
o "+": Octet string concatenation. o "+": Octet string concatenation.
o "[ ]": A portion of an expression enclosed in "[" and "]" may not o "[ ]": A portion of an expression enclosed in "[" and "]" may not
be included in the result under some circumstances. See the be included in the result under some circumstances. See the
associated text for a description of those circumstances. associated text for a description of those circumstances.
o Normalize(str): Apply the Preparation and Enforcement steps o Normalize(str): Apply the Preparation and Enforcement steps
according to the OpaqueString profile (see according to the OpaqueString profile (see [RFC7613]) to a UTF-8
[I-D.ietf-precis-saslprepbis]) to a UTF-8 [RFC3629] encoded "str". [RFC3629] encoded "str". The resulting string is also in UTF-8.
The resulting string is also in UTF-8. Note that implementations Note that implementations MUST either implement OpaqueString
MUST either implement OpaqueString profile operations from profile operations from [RFC7613], or disallow use of non US-ASCII
[I-D.ietf-precis-saslprepbis], 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 [I-D.ietf-precis-saslprepbis]. 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]). [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
skipping to change at page 9, line 51 skipping to change at page 9, line 51
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-256) 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 "sid" attribute (as field [RFC7615] containing the "sid" attribute (as received from the
received from the client) and the "data" attribute containing client) and the "data" attribute containing base64-encoded "server-
base64-encoded "server-final-message", concluding the authentication final-message", concluding the authentication exchange.
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 15, line 38 skipping to change at page 15, line 38
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.hansen-scram-sha256] [I-D.hansen-scram-sha256]
Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL
Mechanisms", draft-hansen-scram-sha256-02 (work in Mechanisms", draft-hansen-scram-sha256-02 (work in
progress), October 2014. progress), October 2014.
[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.
[I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-18 (work in progress), May 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, 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>.
skipping to change at page 17, line 14 skipping to change at page 16, line 46
[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>.
[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,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015,
<http://www.rfc-editor.org/info/rfc7615>.
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)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>. <http://www.rfc-editor.org/info/rfc2865>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000, DOI 10.17487/RFC2898, September 2000,
 End of changes. 8 change blocks. 
26 lines changed or deleted 23 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/