draft-ietf-sasl-scram-07.txt   draft-ietf-sasl-scram-08.txt 
NETWORK WORKING GROUP A. Menon-Sen NETWORK WORKING GROUP A. Menon-Sen
Internet-Draft Oryx Mail Systems GmbH Internet-Draft Oryx Mail Systems GmbH
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Melnikov
Expires: March 14, 2010 Isode Ltd Expires: April 5, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
September 10, 2009 October 2, 2009
Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism
draft-ietf-sasl-scram-07.txt draft-ietf-sasl-scram-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 14, 2010. This Internet-Draft will expire on April 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 12 skipping to change at page 3, line 12
suitable choice for a mandatory-to-implement mechanism for future suitable choice for a mandatory-to-implement mechanism for future
application protocol standards. application protocol standards.
Table of Contents Table of Contents
1. Conventions Used in This Document . . . . . . . . . . 4 1. Conventions Used in This Document . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . 7
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . 9 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . 9
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . 10 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . 11
5. SCRAM Authentication Exchange . . . . . . . . . . . . 11 5. SCRAM Authentication Exchange . . . . . . . . . . . . 12
5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 13
5.2. Compliance with SASL mechanism requirements . . . . . 15 5.2. Compliance with SASL mechanism requirements . . . . . 16
6. Channel Binding . . . . . . . . . . . . . . . . . . . 16 6. Channel Binding . . . . . . . . . . . . . . . . . . . 17
6.1. Default Channel Binding . . . . . . . . . . . . . . . 17 6.1. Default Channel Binding . . . . . . . . . . . . . . . 18
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 18 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 19
8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 21 8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 22
8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 21 8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 22
8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 21 8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 22
8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 22 8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . 28
Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 28 Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 29
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 29 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 30
Appendix C. Internet-Draft Change History . . . . . . . . . . . . 30 Appendix C. Internet-Draft Change History . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . 33
12.2. Normative References for GSS-API implementors . . . . 32 12.2. Normative References for GSS-API implementors . . . . 33
12.3. Informative References . . . . . . . . . . . . . . . . 33 12.3. Informative References . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . 36
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 43 skipping to change at page 4, line 43
o Authentication information: Information used to verify an identity o Authentication information: Information used to verify an identity
claimed by a SCRAM client. The authentication information for a claimed by a SCRAM client. The authentication information for a
SCRAM identity consists of salt, iteration count, the "StoredKey" SCRAM identity consists of salt, iteration count, the "StoredKey"
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 is more common. such as PPP or 802.11x, the use of RADIUS [RFC2865] is more
common.
o Base64: An encoding mechanism defined in [RFC4648] which converts o Base64: An encoding mechanism defined in [RFC4648] which converts
an octet string input to a textual output string which can be an octet string input to a textual output string which can be
easily displayed to a human. The use of base64 in SCRAM is easily displayed to a human. The use of base64 in SCRAM is
restricted to the canonical form with no whitespace. 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.
skipping to change at page 5, line 24 skipping to change at page 5, line 26
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 a Unicode normalization algorithm to a UTF-8
[RFC3629] encoded "str". The resulting string is also in UTF-8.
Implementations SHOULD use the SASLPrep profile [RFC4013] of the
"stringprep" algorithm [RFC3454] as the normalization algorithm.
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 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.
skipping to change at page 6, line 4 skipping to change at page 6, line 10
o Hi(str, salt): o Hi(str, salt):
U0 := HMAC(str, salt + INT(1)) U0 := HMAC(str, salt + INT(1))
U1 := HMAC(str, U0) U1 := HMAC(str, U0)
U2 := HMAC(str, U1) U2 := HMAC(str, U1)
... ...
Ui-1 := HMAC(str, Ui-2) Ui-1 := HMAC(str, Ui-2)
Ui := HMAC(str, Ui-1) Ui := HMAC(str, Ui-1)
Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
where "i" is the iteration count, "+" is the string concatenation where "i" is the iteration count, "+" is the string concatenation
operator and INT(g) is a four-octet encoding of the integer g, operator and INT(g) is a four-octet encoding of the integer g,
most significant octet first. most significant octet first.
o This 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().
2. Introduction 2. Introduction
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. When used in response mechanism more widely than past attempts (see Appendix A and
combination with Transport Layer Security (TLS, see [RFC5246]) or an Appendix B). When used in combination with Transport Layer Security
equivalent security layer, a mechanism from this family could improve (TLS, see [RFC5246]) or an equivalent security layer, a mechanism
the status-quo for application protocol authentication and provide a from this family could improve the status-quo for application
suitable choice for a mandatory-to-implement mechanism for future protocol authentication and provide a suitable choice for a
application protocol standards. mandatory-to-implement mechanism for future application protocol
standards.
For simplicity, this family of mechanisms does not presently include For simplicity, this family of mechanisms does not presently include
negotiation of a security layer [RFC4422]. It is intended to be used negotiation of a security layer [RFC4422]. It is intended to be used
with an external security layer such as that provided by TLS or SSH, with an external security layer such as that provided by TLS or SSH,
with optional channel binding [RFC5056] to the external security with optional channel binding [RFC5056] to the external security
layer. layer.
SCRAM is specified herein as a pure Simple Authentication and SCRAM is specified herein as a pure Simple Authentication and
Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
bridge between SASL and the Generic Security Services Application bridge between SASL and the Generic Security Services Application
skipping to change at page 8, line 4 skipping to change at page 8, line 5
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).
o When used as a SASL mechanism, SCRAM is capable of transporting o When used as a SASL mechanism, SCRAM is capable of transporting
authorization identities (see [RFC4422], Section 2) from the authorization identities (see [RFC4422], Section 2) from the
client to the server. client to the server.
A separate document defines a standard LDAPv3 [RFC4510] attribute A separate document defines a standard LDAPv3 [RFC4510] attribute
that enables storage of the SCRAM authentication information in LDAP. that enables storage of the SCRAM authentication information in LDAP.
See [I-D.melnikov-sasl-scram-ldap]. See [I-D.melnikov-sasl-scram-ldap].
For an in-depth discussion of why other challenge response mechanisms For an in-depth discussion of why other challenge response mechanisms
are not considered sufficient, see appendix A. For more information are not considered sufficient, see appendix A. For more information
about the motivations behind the design of this mechanism, see about the motivations behind the design of this mechanism, see
appendix B. appendix B.
Comments regarding this draft may be sent either to the sasl@ietf.org
mailing list or to the authors.
3. SCRAM Algorithm Overview 3. SCRAM Algorithm Overview
The following is a description of a full, uncompressed SASL SCRAM
authentication exchange. Nothing in SCRAM prevents either sending
the client-first message with the SASL authentication request defined
by an application protocol ("initial client response"), nor sending
the server-final message as additional data of the SASL outcome of
authentication exchange defined by an application protocol. See
[RFC4422] for more details.
Note that this section omits some details, such as client and server Note that this section omits some details, such as client and server
nonces. See Section 5 for more details. 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. It sends the username to the server, which retrieves the password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends
corresponding authentication information, i.e. a salt, StoredKey, the username to the server, which retrieves the corresponding
ServerKey and the iteration count i. (Note that a server authentication information, i.e. a salt, StoredKey, ServerKey and the
implementation may choose to use the same iteration count for all iteration count i. (Note that a server implementation may choose to
accounts.) The server sends the salt and the iteration count to the use the same iteration count for all accounts.) The server sends the
client, which then computes the following values and sends a salt and the iteration count to the client, which then computes the
ClientProof to the server: following values and sends a ClientProof to the server:
SaltedPassword := Hi(password, salt) (*) - Note that both the username and the password MUST be encoded in
UTF-8 [RFC3629].
Informative Note: Implementors are encouraged to create test cases
that use both username passwords with non-ASCII characters. In
particular, it's useful to test characters whose "Unicode
Normalization Form C" and "Unicode Normalization Form KC" are
different. Some examples of such characters include Vulgar Fraction
One Half (U+00BD) and Acute Accent (U+00B4).
SaltedPassword := Hi(Normalize(password), salt)
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")
ServerSignature := HMAC(ServerKey, AuthMessage) ServerSignature := HMAC(ServerKey, AuthMessage)
skipping to change at page 10, line 18 skipping to change at page 11, line 18
uppercased name of the underlying hash function taken from the IANA uppercased name of the underlying hash function taken from the IANA
"Hash Function Textual Names" registry (see http://www.iana.org), "Hash Function Textual Names" registry (see http://www.iana.org),
optionally followed by the suffix "-PLUS" (see below). Note that optionally followed by the suffix "-PLUS" (see below). Note that
SASL mechanism names are limited to 20 characters, which means that SASL mechanism names are limited to 20 characters, which means that
only hash function names with lengths shorter or equal to 9 only hash function names with lengths shorter or equal to 9
characters (20-length("SCRAM-")-length("-PLUS") can be used. For characters (20-length("SCRAM-")-length("-PLUS") can be used. For
cases when the underlying hash function name is longer than 9 cases when the underlying hash function name is longer than 9
characters, an alternative 9 character (or shorter) name can be used characters, an alternative 9 character (or shorter) name can be used
to construct the corresponding SCRAM mechanism name, as long as this to construct the corresponding SCRAM mechanism name, as long as this
alternative name doesn't conflict with any other hash function name alternative name doesn't conflict with any other hash function name
from the IANA "Hash Function Textual Names" registry. from the IANA "Hash Function Textual Names" registry. In order to
prevent future conflict, such alternative name SHOULD be registered
in the IANA "Hash Function Textual Names" registry.
For interoperability, all SCRAM clients and servers MUST implement For interoperability, all SCRAM clients and servers MUST implement
the SCRAM-SHA-1 authentication mechanism, i.e. an authentication the SCRAM-SHA-1 authentication mechanism, i.e. an authentication
mechanism from the SCRAM family that uses the SHA-1 hash function as mechanism from the SCRAM family that uses the SHA-1 hash function as
defined in [RFC3174]. defined in [RFC3174].
The "-PLUS" suffix is used only when the server supports channel The "-PLUS" suffix is used only when the server supports channel
binding to the external channel. If the server supports channel binding to the external channel. If the server supports channel
binding, it will advertise both the "bare" and "plus" versions of binding, it will advertise both the "bare" and "plus" versions of
whatever mechanisms it supports (e.g., if the server supports only whatever mechanisms it supports (e.g., if the server supports only
skipping to change at page 14, line 12 skipping to change at page 15, line 12
version of SCRAM, its presence in a client or a server message version of SCRAM, its presence in a client or a server message
MUST cause authentication failure when the attribute is parsed by MUST cause authentication failure when the attribute is parsed by
the other end. the other end.
o r: This attribute specifies a sequence of random printable ASCII o r: This attribute specifies a sequence of random printable ASCII
characters excluding ',' which forms the nonce used as input to characters excluding ',' which forms the nonce used as input to
the hash function. No quoting is applied to this string. As the hash function. No quoting is applied to this string. As
described earlier, the client supplies an initial value in its described earlier, the client supplies an initial value in its
first message, and the server augments that value with its own first message, and the server augments that value with its own
nonce in its first response. It is important that this value be nonce in its first response. It is important that this value be
different for each authentication. The client MUST verify that different for each authentication (see [RFC4086] for more details
the initial part of the nonce used in subsequent messages is the on how to achieve this). The client MUST verify that the initial
same as the nonce it initially specified. The server MUST verify part of the nonce used in subsequent messages is the same as the
that the nonce sent by the client in the second message is the nonce it initially specified. The server MUST verify that the
same as the one sent by the server in its first message. nonce sent by the client in the second message is the same as the
one sent by the server in its first message.
o c: This REQUIRED attribute specifies the base64-encoded GS2 header o c: This REQUIRED attribute specifies the base64-encoded GS2 header
and channel-binding data. It is sent by the client in its second and channel-binding data. It is sent by the client in its second
authentication message. The attribute data consist of: authentication message. The attribute data consist of:
* the GS2 header from the client's first message (recall: a * the GS2 header from the client's first message (recall that the
channel binding flag and an optional authzid). This header is GS2 header contains a channel binding flag and an optional
going to include channel binding type prefix (see [RFC5056]), authzid). This header is going to include channel binding type
if and only if the client is using channel binding; prefix (see [RFC5056]), if and only if the client is using
channel binding;
* followed by the external channel's channel binding data, if and * followed by the external channel's channel binding data, if and
only if the client is using channel binding. only if the client is using channel binding.
o s: This attribute specifies the base64-encoded salt used by the o s: This attribute specifies the base64-encoded salt used by the
server for this user. It is sent by the server in its first server for this user. It is sent by the server in its first
message to the client. message to the client.
o i: This attribute specifies an iteration count for the selected o i: This attribute specifies an iteration count for the selected
hash function and user, and MUST be sent by the server along with hash function and user, and MUST be sent by the server along with
the user's salt. the user's salt.
For SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism servers SHOULD For SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism servers SHOULD
announce a hash iteration-count of at least 4096. Note that a announce a hash iteration-count of at least 4096. Note that a
client implementation MAY cache SaltedPassword/ClientKey for client implementation MAY cache ClientKey&ServerKey (or just
later reauthentication to the same service, as it is likely SaltedPassword) for later reauthentication to the same service,
that the server is going to advertise the same salt value upon as it is likely that the server is going to advertise the same
reauthentication. This might be useful for mobile clients salt value upon reauthentication. This might be useful for
where CPU usage is a concern. mobile clients where CPU usage is a concern.
o p: This attribute specifies a base64-encoded ClientProof. The o p: This attribute specifies a base64-encoded ClientProof. The
client computes this value as described in the overview and sends client computes this value as described in the overview and sends
it to the server. it to the server.
o v: This attribute specifies a base64-encoded ServerSignature. It o v: This attribute specifies a base64-encoded ServerSignature. It
is sent by the server in its final message, and is used by the is sent by the server in its final message, and is used by the
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.
skipping to change at page 21, line 18 skipping to change at page 22, line 18
not referenced elsewhere in this document are INFORMATIONAL for SASL not referenced elsewhere in this document are INFORMATIONAL for SASL
implementors, but they are NORMATIVE for GSS-API implementors. implementors, but they are NORMATIVE for GSS-API implementors.
SCRAM is actually also GSS-API mechanism. The messages are the same, SCRAM is actually also GSS-API mechanism. The messages are the same,
but a) the GS2 header on the client's first message and channel but a) the GS2 header on the client's first message and channel
binding data is excluded when SCRAM is used as a GSS-API mechanism, binding data is excluded when SCRAM is used as a GSS-API mechanism,
and b) the RFC2743 section 3.1 initial context token header is and b) the RFC2743 section 3.1 initial context token header is
prefixed to the client's first authentication message (context prefixed to the client's first authentication message (context
token). token).
The GSS-API mechanism OID for SCRAM is <TBD> (see Section 10). The GSS-API mechanism OID for SCRAM-SHA-1 is <TBD> (see Section 10).
8.1. GSS-API Principal Name Types for SCRAM 8.1. GSS-API Principal Name Types for SCRAM
SCRAM does not name acceptors. Therefore only GSS_C_NO_NAME and SCRAM does not name acceptors. Therefore only GSS_C_NO_NAME and
names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name
input of GSS_Init_sec_context() when using a SCRAM mechanism. input of GSS_Init_sec_context() when using a SCRAM mechanism.
SCRAM supports only a single name type for initiators: SCRAM supports only a single name type for initiators:
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for
SCRAM. SCRAM.
skipping to change at page 23, line 8 skipping to change at page 24, line 8
The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
the Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor- the Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor-
asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random(). GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
The protocol key to be used for the GSS_Pseudo_random() SHALL be the The protocol key to be used for the GSS_Pseudo_random() SHALL be the
same as the key defined in Section 8.2. same as the key defined in Section 8.2.
9. Security Considerations 9. Security Considerations
If the authentication exchange is performed without a strong security If the authentication exchange is performed without a strong security
layer, then a passive eavesdropper can gain sufficient information to layer (such as TLS with data confidentiality), then a passive
mount an offline dictionary or brute-force attack which can be used eavesdropper can gain sufficient information to mount an offline
to recover the user's password. The amount of time necessary for dictionary or brute-force attack which can be used to recover the
this attack depends on the cryptographic hash function selected, the user's password. The amount of time necessary for this attack
strength of the password and the iteration count supplied by the depends on the cryptographic hash function selected, the strength of
server. An external security layer with strong encryption will the password and the iteration count supplied by the server. An
prevent this attack. external security layer with strong encryption will prevent this
attack.
If the external security layer used to protect the SCRAM exchange If the external security layer used to protect the SCRAM exchange
uses an anonymous key exchange, then the SCRAM channel binding uses an anonymous key exchange, then the SCRAM channel binding
mechanism can be used to detect a man-in-the-middle attack on the mechanism can be used to detect a man-in-the-middle attack on the
security layer and cause the authentication to fail as a result. security layer and cause the authentication to fail as a result.
However, the man-in-the-middle attacker will have gained sufficient However, the man-in-the-middle attacker will have gained sufficient
information to mount an offline dictionary or brute-force attack. information to mount an offline dictionary or brute-force attack.
For this reason, SCRAM includes the ability to increase the iteration For this reason, SCRAM includes the ability to increase the iteration
count over time. count over time.
skipping to change at page 26, line 18 skipping to change at page 27, line 18
SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS
Security considerations: Section 7 of [RFCXXXX] Security considerations: Section 7 of [RFCXXXX]
Published specification (optional, recommended): [RFCXXXX] Published specification (optional, recommended): [RFCXXXX]
Person & email address to contact for further information: Person & email address to contact for further information:
IETF SASL WG <sasl@ietf.org> IETF SASL WG <sasl@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org> Owner/Change controller: IESG <iesg@ietf.org>
Note: Note:
This document also requests IANA to assign a GSS-API mechanism OID This document also requests IANA to assign a GSS-API mechanism OID
for SCRAM from the iso.org.dod.internet.security.mechanisms prefix for SCRAM-SHA-1 from the iso.org.dod.internet.security.mechanisms
(see "SMI Security for Mechanism Codes" registry). prefix (see "SMI Security for Mechanism Codes" registry).
11. Acknowledgements 11. Acknowledgements
This document benefited from discussions on the SASL WG mailing list. This document benefited from discussions on the SASL WG mailing list.
The authors would like to specially thank Dave Cridland, Simon The authors would like to specially thank Dave Cridland, Simon
Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen and Peter Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen and Peter
Saint-Andrefor their contributions to this document. Saint-Andrefor their contributions to this document.
Appendix A. Other Authentication Mechanisms Appendix A. Other Authentication Mechanisms
skipping to change at page 30, line 7 skipping to change at page 31, line 7
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 DIGEST-MD5 in both clients and servers. o Easier to implement than DIGEST-MD5 in both clients and servers.
Appendix C. Internet-Draft Change History Appendix C. Internet-Draft Change History
(RFC Editor: Please delete everything after this point) (RFC Editor: Please delete this section and all subsections.)
Changes since -10 Changes since -10
o Converted the source for this I-D to XML. o Converted the source for this I-D to XML.
o Added text to make SCRAM compliant with the new GS2 design. o Added text to make SCRAM compliant with the new GS2 design.
o Added text on channel binding negotiation. o Added text on channel binding negotiation.
o Added text on channel binding, including a reference to RFC5056. o Added text on channel binding, including a reference to RFC5056.
skipping to change at page 33, line 48 skipping to change at page 34, line 48
[I-D.ietf-sasl-digest-to-historic] [I-D.ietf-sasl-digest-to-historic]
Melnikov, A., "Moving DIGEST-MD5 to Historic", Melnikov, A., "Moving DIGEST-MD5 to Historic",
draft-ietf-sasl-digest-to-historic-00 (work in progress), draft-ietf-sasl-digest-to-historic-00 (work in progress),
July 2008. July 2008.
[I-D.melnikov-sasl-scram-ldap] [I-D.melnikov-sasl-scram-ldap]
Melnikov, A., "LDAP schema for storing SCRAM secrets", Melnikov, A., "LDAP schema for storing SCRAM secrets",
draft-melnikov-sasl-scram-ldap-02 (work in progress), draft-melnikov-sasl-scram-ldap-02 (work in progress),
July 2009. July 2009.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 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",
RFC 2945, September 2000. RFC 2945, September 2000.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
 End of changes. 24 change blocks. 
72 lines changed or deleted 103 lines changed or added

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