draft-ietf-httpauth-scram-auth-14.txt   draft-ietf-httpauth-scram-auth-15.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Experimental December 5, 2015 Intended status: Experimental December 16, 2015
Expires: June 7, 2016 Expires: June 18, 2016
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-14.txt draft-ietf-httpauth-scram-auth-15.txt
Abstract Abstract
This specification describes a family of HTTP authentication This specification describes a family of HTTP authentication
mechanisms called the Salted Challenge Response Authentication mechanisms called the Salted Challenge Response Authentication
Mechanism (SCRAM), which provides a more robust authentication Mechanism (SCRAM), which provides a more robust authentication
mechanism than a plaintext password protected by Transport Layer mechanism than a plaintext password protected by Transport Layer
Security (TLS) and avoids the deployment obstacles presented by Security (TLS) and avoids the deployment obstacles presented by
earlier TLS-protected challenge response authentication mechanisms. earlier TLS-protected challenge response authentication mechanisms.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 June 7, 2016. This Internet-Draft will expire on June 18, 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 21 skipping to change at page 2, line 21
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . 12 6. Use of Authentication-Info header field with SCRAM . . . . . 12
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15 11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The authentication mechanism most widely deployed and used by The authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS). passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism, There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the HTTP authentication mechanism protected by TLS. Unfortunately, the HTTP
Digest challenge response mechanism presently on the standards track Digest challenge response mechanism presently on the standards track
failed widespread deployment, and have had success only in limited failed widespread deployment, and has had success only in limited
use. use.
This specification describes a family of authentication mechanisms This specification describes a family of authentication mechanisms
called the Salted Challenge Response Authentication Mechanism (SCRAM) called the Salted Challenge Response Authentication Mechanism (SCRAM)
which addresses the requirements necessary to deploy a challenge- which addresses the requirements necessary to deploy a challenge-
response mechanism more widely than past attempts (see [RFC5802]). response mechanism more widely than past attempts (see [RFC5802]).
In particular, it addresses some of the issues identified with HTTP In particular, it addresses some of the issues identified with HTTP
Digest [RFC6331], such as complexity of implementing and protection Digest, as described in [RFC6331], such as complexity of implementing
of the whole authentication exchange in order to protect from certain and protection of the whole authentication exchange in order to
man-in-the-middle attacks. protect from certain man-in-the-middle attacks.
HTTP SCRAM is adoptation of [RFC5802] for use in HTTP. (SCRAM data HTTP SCRAM is an adoptation of [RFC5802] for use in HTTP. The SCRAM
exchanged is identical to what is defined in [RFC5802].) It also data exchanged is identical to what is defined in [RFC5802]. This
adds 1 round trip reauthentication mode. document also adds a 1 round trip reauthentication mode.
HTTP SCRAM provides the following protocol features: HTTP SCRAM provides the following protocol features:
o The authentication information stored in the authentication o The authentication information stored in the authentication
database is not sufficient by itself (without a dictionary attack) database is not sufficient by itself (without a dictionary attack)
to impersonate the client. The information is salted to prevent a to impersonate the client. The information is salted to make it
pre-stored dictionary attack if the database is stolen. harder to do a pre-stored dictionary attack if the database is
stolen.
o The server does not gain the ability to impersonate the client to o The server does not gain the ability to impersonate the client to
other servers (with an exception for server-authorized proxies). other servers (with an exception for server-authorized proxies),
unless it performs a dictionary attack.
o The mechanism permits the use of a server-authorized proxy without o The mechanism permits the use of a server-authorized proxy without
requiring that proxy to have super-user rights with the back-end requiring that proxy to have super-user rights with the back-end
server. server.
o Mutual authentication is supported, but only the client is named o Mutual authentication is supported, but only the client is named
(i.e., the server has no name). (i.e., the server has no name).
2. Conventions Used in This Document 2. Conventions Used in This Document
skipping to change at page 4, line 38 skipping to change at page 4, line 40
2.2. Notation 2.2. Notation
The pseudocode description of the algorithm uses the following The pseudocode description of the algorithm uses the following
notations: notations:
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 "]" is
be included in the result under some circumstances. See the optional 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 [RFC7613]) to a UTF-8 according to the OpaqueString profile (see [RFC7613]) to a UTF-8
[RFC3629] encoded "str". The resulting string is also in UTF-8. [RFC3629] encoded "str". The resulting string is also in UTF-8.
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].
skipping to change at page 5, line 43 skipping to change at page 5, line 46
Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
with dkLen == output length of HMAC() == output length of H(). with dkLen == output length of HMAC() == output length of H().
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, both encoded in UTF-8 [RFC3629] (or a ClientKey/ServerKey,
the username to the server, which retrieves the corresponding or SaltedPassword). It sends the username to the server, which
authentication information, i.e. a salt, StoredKey, ServerKey and the retrieves the corresponding authentication information: a salt, a
iteration count i. (Note that a server implementation may choose to StoredKey, a ServerKey and an iteration count ("i"). (Note that a
use the same iteration count for all accounts.) The server sends the server implementation may choose to use the same iteration count for
salt and the iteration count to the client, which then computes the all accounts.) The server sends the salt and the iteration count to
following values and sends a ClientProof to the server: the client, which then computes the following values and sends a
ClientProof to the server:
(*) - Note that both the username and the password MUST be encoded in
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 is useful to test codepoints whose "Unicode particular, it is useful to test codepoints whose "Unicode
Normalization Form C" and "Unicode Normalization Form KC" are Normalization Canonical Composition (NFC)" and "Unicode Normalization
different. Some examples of such codepoints include Vulgar Fraction Form Compatibility Composition (NFKC)" are different. Some examples
One Half (U+00BD) and Acute Accent (U+00B4). of such codepoints include Vulgar Fraction One Half (U+00BD) and
Acute Accent (U+00B4).
SaltedPassword := Hi(Normalize(password), salt, i) SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key") ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey) StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," + AuthMessage := client-first-message-bare + "," +
server-first-message + "," + server-first-message + "," +
client-final-message-without-proof client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage) ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof := ClientKey XOR ClientSignature ClientProof := ClientKey XOR ClientSignature
ServerKey := HMAC(SaltedPassword, "Server Key") ServerKey := HMAC(SaltedPassword, "Server Key")
skipping to change at page 6, line 40 skipping to change at page 6, line 41
is correct, this proves that the client has access to the user's is correct, this proves that the client has access to the user's
password. password.
Similarly, the client authenticates the server by computing the Similarly, the client authenticates the server by computing the
ServerSignature and comparing it to the value sent by the server. If ServerSignature and comparing it to the value sent by the server. If
the two are equal, it proves that the server had access to the user's the two are equal, it proves that the server had access to the user's
ServerKey. ServerKey.
For initial authentication the AuthMessage is computed by For initial authentication the AuthMessage is computed by
concatenating decoded "data" attribute values from the authentication concatenating decoded "data" attribute values from the authentication
exchange. The format of these messages is defined in [RFC5802]. exchange. The format of each of these 3 decoded "data" attributes 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/assignments/hash-function-text-names/) .
For interoperability, all HTTP clients and servers supporting SCRAM For interoperability, all HTTP clients and servers supporting SCRAM
MUST implement the SCRAM-SHA-256 authentication mechanism, i.e. an MUST implement the SCRAM-SHA-256 authentication mechanism, i.e. an
authentication mechanism from the SCRAM family that uses the SHA-256 authentication mechanism from the SCRAM family that uses the SHA-256
hash function as defined in [RFC7677]. hash function as defined in [RFC7677].
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>)
skipping to change at page 14, line 36 skipping to change at page 14, line 36
same hash function, password, iteration count and salt. For this same hash function, password, iteration count and salt. For this
reason, it is important to use randomly-generated salt values. reason, it is important to use randomly-generated salt values.
SCRAM does not negotiate a hash function to use. Hash function SCRAM does not negotiate a hash function to use. Hash function
negotiation is left to the HTTP authentication mechanism negotiation. negotiation is left to the HTTP authentication mechanism negotiation.
It is important that clients be able to sort a locally available list It is important that clients be able to sort a locally available list
of mechanisms by preference so that the client may pick the most of mechanisms by preference so that the client may pick the most
preferred of a server's advertised mechanism list. This preference preferred of a server's advertised mechanism list. This preference
order is not specified here as it is a local matter. The preference order is not specified here as it is a local matter. The preference
order should include objective and subjective notions of mechanism order should include objective and subjective notions of mechanism
cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be cryptographic strength (e.g., SCRAM with SHA-256 should be preferred
preferred over SCRAM with SHA-1). over SCRAM with SHA-1).
This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1
is registered for database compatibility with implementations of RFC
5802 (such as IMAP or XMPP servers) which want to also expose HTTP
access to a related service, but it is not recommended for new
deployments.
A hostile server can perform a computational denial-of-service attack A hostile server can perform a computational denial-of-service attack
on clients by sending a big iteration count value. In order to on clients by sending a big iteration count value. In order to
defend against that, a client implementation can pick a maximum defend against that, a client implementation can pick a maximum
iteration count that it is willing to use, and that it rejects any iteration count that it is willing to use, and that it rejects any
values that exceed that threshold (in such cases the client, of values that exceed that threshold (in such cases the client, of
course, has to fail the authentication). course, has to fail the authentication).
See [RFC4086] for more information about generating randomness. See [RFC4086] for more information about generating randomness.
This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1
is registered for database compatibility with implementations of RFC
5802 (such as IMAP or XMPP servers) which want to also expose HTTP
access to a related service, but it is not recommended for new
deployments.
9. IANA Considerations 9. IANA Considerations
New mechanisms in the SCRAM- family are registered according to the New mechanisms in the SCRAM- family are registered according to the
IANA procedure specified in [RFC5802]. IANA procedure specified in [RFC5802].
Note to future SCRAM- mechanism designers: each new SCRAM- HTTP Note to future SCRAM- mechanism designers: each new SCRAM- HTTP
authentication mechanism MUST be explicitly registered with IANA and authentication mechanism MUST be explicitly registered with IANA and
MUST comply with SCRAM- mechanism naming convention defined in MUST comply with SCRAM- mechanism naming convention defined in
Section 4 of this document. Section 4 of this document.
skipping to change at page 15, line 41 skipping to change at page 15, line 42
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 Thank you to Julian F. Reschke for corrections regarding use of
Authentication-Info header field. 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.
Thank you to Russ Housley, Stephen Farrell, Barry Leiba and Tim Chown
for doing detailed reviews of the document.
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.
bindings.
o The protocol supports mutual authentication. o The protocol supports mutual authentication.
o The authentication information stored in the authentication o The authentication information stored in the authentication
database is not sufficient by itself to impersonate the client. database is not sufficient by itself to impersonate the client.
o The server does not gain the ability to impersonate the client to o The server does not gain the ability to impersonate the client to
other servers (with an exception for server-authorized proxies), other servers (with an exception for server-authorized proxies),
unless such other servers allow SCRAM authentication and use the unless such other servers allow SCRAM authentication and use the
same salt and iteration count for the user. same salt and iteration count for the user.
o The mechanism is extensible, but [hopefully] not overengineered in o The mechanism is extensible, but [hopefully] not overengineered in
this respect. this respect.
o Easier to implement than HTTP Digest in both clients and servers. o Easier to implement than HTTP Digest in both clients and servers.
o The protocol supports 1 round trip reauthentication.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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
skipping to change at page 18, line 19 skipping to change at page 18, line 23
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
DOI 10.17487/RFC4510, June 2006, DOI 10.17487/RFC4510, June 2006,
<http://www.rfc-editor.org/info/rfc4510>. <http://www.rfc-editor.org/info/rfc4510>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, [RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331,
DOI 10.17487/RFC6331, July 2011, DOI 10.17487/RFC6331, July 2011,
<http://www.rfc-editor.org/info/rfc6331>. <http://www.rfc-editor.org/info/rfc6331>.
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. 20 change blocks. 
47 lines changed or deleted 48 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/