draft-ietf-sasl-scram-02.txt   draft-ietf-sasl-scram-03.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: January 9, 2010 Isode Ltd Expires: January 31, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
July 8, 2009 July 30, 2009
Salted Challenge Response (SCRAM) SASL Mechanism Salted Challenge Response (SCRAM) SASL Mechanism
draft-ietf-sasl-scram-02.txt draft-ietf-sasl-scram-03.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 January 9, 2010. This Internet-Draft will expire on January 31, 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 24 skipping to change at page 3, line 24
5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
6. Channel Binding . . . . . . . . . . . . . . . . . . . 15 6. Channel Binding . . . . . . . . . . . . . . . . . . . 15
6.1. Default Channel Binding . . . . . . . . . . . . . . . 16 6.1. Default Channel Binding . . . . . . . . . . . . . . . 16
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 17 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 17
8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20 8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20
8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 20 8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 20
8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20 8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20
8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 21 8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . 26
Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 26 Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 27
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 27 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 28
Appendix C. Internet-Draft Change History . . . . . . . . . . . . 28 Appendix C. Internet-Draft Change History . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . 31
12.2. Normative References for GSS-API implementors . . . . 30 12.2. Normative References for GSS-API implementors . . . . 31
12.3. Informative References . . . . . . . . . . . . . . . . 31 12.3. Informative References . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . 34
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 7, line 17 skipping to change at page 7, line 17
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. When used in
combination with Transport Layer Security (TLS, see [RFC5246]) or an combination with Transport Layer Security (TLS, see [RFC5246]) or an
equivalent security layer, a mechanism from this family could improve equivalent security layer, a mechanism from this family could improve
the status-quo for application protocol authentication and provide a the status-quo for application protocol authentication and provide a
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.
For simplicity, this family of mechanism does not presently include For simplicity, this family of mechanisms does not presently include
negotiation of a security layer. It is intended to be used with an negotiation of a security layer [RFC4422]. It is intended to be used
external security layer such as that provided by TLS or SSH, with with an external security layer such as that provided by TLS or SSH,
optional channel binding [RFC5056] to the external security layer. with optional channel binding [RFC5056] to the external security
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
Programming Interface (GSS-API) called "GS2" [I-D.ietf-sasl-gs2]. Programming Interface (GSS-API) called "GS2" [I-D.ietf-sasl-gs2].
This means that this document defines both, a SASL mechanism and a This means that this document defines both, a SASL mechanism and a
GSS-API mechanism. GSS-API mechanism.
SCRAM provides the following protocol features: SCRAM provides the following protocol features:
skipping to change at page 7, line 43 skipping to change at page 7, line 44
The information is salted to prevent a pre-stored dictionary The information is salted to prevent a pre-stored dictionary
attack if the database is stolen. 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).
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 A standard attribute is defined to enable storage of the
authentication information in LDAPv3 (see [RFC4510]).
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).
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 Comments regarding this draft may be sent either to the
ietf-sasl@imc.org mailing list or to the authors. ietf-sasl@imc.org mailing list or to the authors.
3. SCRAM Algorithm Overview 3. SCRAM Algorithm Overview
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 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. It sends the username to the server, which retrieves the
corresponding authentication information, i.e. a salt, StoredKey, corresponding authentication information, i.e. a salt, StoredKey,
ServerKey and the iteration count i. (Note that a server ServerKey and the iteration count i. (Note that a server
implementation may chose to use the same iteration count for all implementation may chose to use the same iteration count for all
account.) The server sends the salt and the iteration count to the accounts.) The server sends the salt and the iteration count to the
client, which then computes the following values and sends a client, which then computes the following values and sends a
ClientProof to the server: ClientProof to the server:
SaltedPassword := Hi(password, salt) SaltedPassword := Hi(password, salt)
ClientKey := HMAC(SaltedPassword, "Client Key") ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey) StoredKey := H(ClientKey)
AuthMessage := client-first-message + "," + 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)
The server authenticates the client by computing the ClientSignature, The server authenticates the client by computing the ClientSignature,
exclusive-ORing that with the ClientProof to recover the ClientKey exclusive-ORing that with the ClientProof to recover the ClientKey
and verifying the correctness of the ClientKey by applying the hash and verifying the correctness of the ClientKey by applying the hash
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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.
The AuthMessage is computed by concatenating messages from the The AuthMessage is computed by concatenating messages from the
authentication exchange. The format of these messages is defined in authentication exchange. The format of these messages is defined in
Section 7. Section 7.
4. SCRAM Mechanism Names 4. SCRAM Mechanism Names
A SCRAM mechanism name is a string "SCRAM-" followed by the A SCRAM mechanism name is a string "SCRAM-" followed by the
uppercased name of the underlying hashed 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.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
C: n,,n=Chris Newman,r=ClientNonce C: n,,n=Chris Newman,r=ClientNonce
S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
C: c=biwsCg==,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 C: c=biwsCg==,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
S: v=WxPv/siO5l+qxN4 S: v=WxPv/siO5l+qxN4
[[anchor5: Note that the all hashes above are fake and will be fixed [[anchor5: Note that the all hashes above are fake and will be fixed
during AUTH48.]] during AUTH48.]]
With channel-binding data sent by the client this might look like With channel-binding data sent by the client this might look like
this: this (see [tls-server-end-point] for the definition of tls-server-
end-point TLS channel binding):
C: p=tls-server-end-point,,n=Chris Newman,r=ClientNonce C: p=tls-server-end-point,,n=Chris Newman,r=ClientNonce
S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
C: c=cD10bHMtc2VydmVyLWVuZC1wb2ludCwsy1hFtXOnZ+ySrQM6srFp C: c=cD10bHMtc2VydmVyLWVuZC1wb2ludCwsy1hFtXOnZ+ySrQM6srFp
l/77uqvtxrg7nBY1BetEr/g=,r=ClientNonceServerNonce,p=Wx l/77uqvtxrg7nBY1BetEr/g=,r=ClientNonceServerNonce,p=Wx
Pv/siO5l+qxN4 Pv/siO5l+qxN4
S: v=WxPv/siO5l+qxN4 S: v=WxPv/siO5l+qxN4
[[anchor6: Note that all hashes above are fake and will be fixed [[anchor6: Note that all hashes above are fake and will be fixed
during AUTH48.]] during AUTH48.]]
skipping to change at page 12, line 44 skipping to change at page 12, line 45
include it in its first message to the server if it wants to include it in its first message to the server if it wants to
authenticate as one user, but subsequently act as a different authenticate as one user, but subsequently act as a different
user. This is typically used by an administrator to perform some user. This is typically used by an administrator to perform some
management task on behalf of another user, or by a proxy in some management task on behalf of another user, or by a proxy in some
situations. situations.
Upon the receipt of this value the server verifies its Upon the receipt of this value the server verifies its
correctness according to the used SASL protocol profile. correctness according to the used SASL protocol profile.
Failed verification results in failed authentication exchange. Failed verification results in failed authentication exchange.
If this attribute is omitted (as it normally would be), or If this attribute is omitted (as it normally would be), the
specified with an empty value, the authorization identity is authorization identity is assumed to be derived from the
assumed to be derived from the username specified with the username specified with the (required) "n" attribute.
(required) "n" attribute.
The server always authenticates the user specified by the "n" The server always authenticates the user specified by the "n"
attribute. If the "a" attribute specifies a different user, attribute. If the "a" attribute specifies a different user,
the server associates that identity with the connection after the server associates that identity with the connection after
successful authentication and authorization checks. successful authentication and authorization checks.
The syntax of this field is the same as that of the "n" field The syntax of this field is the same as that of the "n" field
with respect to quoting of '=' and ','. with respect to quoting of '=' and ','.
o n: This attribute specifies the name of the user whose password is o n: This attribute specifies the name of the user whose password is
used for authentication (a.k.a. "authentication identity"). A used for authentication (a.k.a. "authentication identity"
client must include it in its first message to the server. If the [RFC4422]). A client MUST include it in its first message to the
"a" attribute is not specified (which would normally be the case), server. If the "a" attribute is not specified (which would
this username is also the identity which will be associated with normally be the case), this username is also the identity which
the connection subsequent to authentication and authorization. will be associated with the connection subsequent to
authentication and authorization.
Before sending the username to the server, the client MUST Before sending the username to the server, the client MUST
prepare the username using the "SASLPrep" profile [RFC4013] of prepare the username using the "SASLPrep" profile [RFC4013] of
the "stringprep" algorithm [RFC3454]. If the preparation of the "stringprep" algorithm [RFC3454]. If the preparation of
the username fails or results in an empty string, the client the username fails or results in an empty string, the client
SHOULD abort the authentication exchange (*). SHOULD abort the authentication exchange (*).
(*) An interactive client can request a repeated entry of the (*) An interactive client can request a repeated entry of the
username value. username value.
skipping to change at page 13, line 45 skipping to change at page 13, line 47
o m: This attribute is reserved for future extensibility. In this o m: This attribute is reserved for future extensibility. In this
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 o r: This attribute specifies a sequence of random printable
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 be value 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. The client MUST verify that
the initial part of the nonce used in subsequent messages is the the initial part of the nonce used in subsequent messages is the
same as the nonce it initially specified. The server MUST verify same as the nonce it initially specified. The server MUST verify
that the nonce sent by the client in the second message is the that the nonce sent by the client in the second message is the
same as the one sent by the server in its first message. same as the one sent by the server in its first message.
o c: This REQUIRED attribute specifies base64-encoded of a header o c: This REQUIRED attribute specifies base64-encoded of a header
and the channel-binding data. It is sent by the client in its and the channel-binding data. It is sent by the client in its
second authentication message. The header consist of: second authentication message. The header consist of:
* the GS2 header from the client's first message (recall: a * the GS2 header from the client's first message (recall: a
channel binding flag and an optional authzid). This header is channel binding flag and an optional authzid). This header is
going to include channel binding type prefix (see [RFC5056], if going to include channel binding type prefix (see [RFC5056]),
and only if the client is using channel binding; 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 SaltedPassword/ClientKey for
later reauthentication to the same service, as it is likely later reauthentication to the same service, as it is likely
that the server is going to advertise the same salt value upon that the server is going to advertise the same salt value upon
reauthentication. This might be useful for mobile clients reauthentication. This might be useful for mobile clients
where CPU usage is a concern. where CPU usage is a concern.
skipping to change at page 15, line 25 skipping to change at page 15, line 25
o Servers SHOULD advertise both non-PLUS (SCRAM-<hash-function>) and o Servers SHOULD advertise both non-PLUS (SCRAM-<hash-function>) and
the PLUS-variant (SCRAM-<hash-function>-PLUS) SASL mechanism the PLUS-variant (SCRAM-<hash-function>-PLUS) SASL mechanism
names. If the server cannot support channel binding, it MAY names. If the server cannot support channel binding, it MAY
advertise only the non-PLUS variant. If the server would never advertise only the non-PLUS variant. If the server would never
succeed authentication of the non-PLUS variant due to policy succeed authentication of the non-PLUS variant due to policy
reasons, it MAY advertise only the PLUS-variant. reasons, it MAY advertise only the PLUS-variant.
o If the client negotiates mechanisms then the client MUST select o If the client negotiates mechanisms then the client MUST select
SCRAM-<hash-function>-PLUS if offered by the server and the client SCRAM-<hash-function>-PLUS if offered by the server and the client
wants to select SCRAM with the given hash function. [[anchor7: Is wants to select SCRAM with the given hash function. Otherwise
the following correct?]] Otherwise, if the client does not (the client does not negotiate mechanisms), if the client has no
negotiate mechanisms then it MUST select only SCRAM-<hash- prior knowledge about mechanisms supported by the server and
function> (not suffixed with "-PLUS"). wasn't explicitly configured to use a particular variant of the
SCRAM mechanism, then it MUST select only SCRAM-<hash-function>
(not suffixed with "-PLUS").
o If the client supports channel binding and the server appears to o If the client supports channel binding and the server appears to
support it (i.e., the client sees SCRAM-<hash-function>-PLUS), or support it (i.e., the client sees SCRAM-<hash-function>-PLUS), or
if the client wishes to use channel binding but the client does if the client wishes to use channel binding but the client does
not negotiate mechanisms, then the client MUST set the GS2 channel not negotiate mechanisms, then the client MUST set the GS2 channel
binding flag to "p" in order to indicate the channel binding type binding flag to "p" in order to indicate the channel binding type
it is using and it MUST include the channel binding data for the it is using and it MUST include the channel binding data for the
external channel in the computation of the "c=" attribute (see external channel in the computation of the "c=" attribute (see
Section 5.1). Section 5.1).
o If the client supports channel binding but the server does not o If the client supports channel binding but the server does not
appear to (i.e., the client did not see SCRAM-<hash-function>- appear to (i.e., the client did not see SCRAM-<hash-function>-
PLUS) then the client MUST either fail authentication or it MUST PLUS) then the client MUST either fail authentication or it MUST
chose the non-PLUS mechanism and set the GS2 channel binding flag choose the non-PLUS mechanism and set the GS2 channel binding flag
to "y" and MUST NOT include channel binding data for the external to "y" and MUST NOT include channel binding data for the external
channel in the computation of the "c=" attribute (see channel in the computation of the "c=" attribute (see
Section 5.1). Section 5.1).
o If the client does not support channel binding then the client o If the client does not support channel binding then the client
MUST set the GS2 channel binding flag to "n" and MUST NOT include MUST set the GS2 channel binding flag to "n" and MUST NOT include
channel binding data for the external channel in the computation channel binding data for the external channel in the computation
of the "c=" attribute (see Section 5.1). of the "c=" attribute (see Section 5.1).
o Upon receipt of the client first message the server checks the GS2 o Upon receipt of the client first message the server checks the GS2
skipping to change at page 17, line 17 skipping to change at page 17, line 17
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3"
and "UTF8-4" non-terminal are defined in [RFC3629]. and "UTF8-4" non-terminal are defined in [RFC3629].
ALPHA = <as defined in RFC 5234 appendix B.1> ALPHA = <as defined in RFC 5234 appendix B.1>
DIGIT = <as defined in RFC 5234 appendix B.1> DIGIT = <as defined in RFC 5234 appendix B.1>
UTF8-2 = <as defined in RFC 3629 (STD 63)> UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <as defined in RFC 3629 (STD 63)> UTF8-3 = <as defined in RFC 3629 (STD 63)>
UTF8-4 = <as defined in RFC 3629 (STD 63)> UTF8-4 = <as defined in RFC 3629 (STD 63)>
generic-message = attr-val *("," attr-val)
;; Generic syntax of any server challenge
;; or client response
attr-val = ALPHA "=" value attr-val = ALPHA "=" value
;; Generic syntax of any attribute sent
;; by server or client
value = 1*value-char value = 1*value-char
value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 / UTF8-3 / UTF8-4
;; UTF8-char except NUL, "=", and ",". ;; UTF8-char except NUL, "=", and ",".
value-char = value-safe-char / "=" value-char = value-safe-char / "="
base64-char = ALPHA / DIGIT / "/" / "+" base64-char = ALPHA / DIGIT / "/" / "+"
skipping to change at page 18, line 50 skipping to change at page 18, line 46
s-nonce = value s-nonce = value
salt = "s=" base64 salt = "s=" base64
verifier = "v=" base64 verifier = "v=" base64
;; base-64 encoded ServerSignature. ;; base-64 encoded ServerSignature.
iteration-count = "i=" posit-number iteration-count = "i=" posit-number
;; A positive number ;; A positive number
client-first-message = client-first-message-bare =
gs2-header [reserved-mext ","] [reserved-mext ","]
username "," nonce ["," extensions] username "," nonce ["," extensions]
client-first-message =
gs2-header client-first-message-bare
server-first-message = server-first-message =
[reserved-mext ","] nonce "," salt "," [reserved-mext ","] nonce "," salt ","
iteration-count ["," extensions] iteration-count ["," extensions]
client-final-message-without-proof = client-final-message-without-proof =
channel-binding "," nonce ["," channel-binding "," nonce [","
extensions] extensions]
client-final-message = client-final-message =
client-final-message-without-proof "," proof client-final-message-without-proof "," proof
skipping to change at page 20, line 41 skipping to change at page 20, line 41
SASLprep as described in Section 5.1. SASLprep as described in Section 5.1.
The query, display and exported name syntax for SCRAM principal names The query, display and exported name syntax for SCRAM principal names
is the same: there is no syntax -- SCRAM principal names are free- is the same: there is no syntax -- SCRAM principal names are free-
form. (The exported name token does, of course, conform to [RFC2743] form. (The exported name token does, of course, conform to [RFC2743]
section 3.2, but the "NAME" part of the token is just a SCRAM user section 3.2, but the "NAME" part of the token is just a SCRAM user
name.) name.)
8.2. GSS-API Per-Message Tokens for SCRAM 8.2. GSS-API Per-Message Tokens for SCRAM
The per-message tokens for SCRAM as a GSS-API mechanism SHALL BE the The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the
same as those for the Kerberos V GSS-API mechanism [RFC4121], using same as those for the Kerberos V GSS-API mechanism [RFC4121], using
the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962]. the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
The 128-bit session key SHALL be derived by using the least The 128-bit session key SHALL be derived by using the least
significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
key" || ClientKey || AuthMessage). key" || ClientKey || AuthMessage).
SCRAM does support PROT_READY, and is PROT_READY on the initiator SCRAM does support PROT_READY, and is PROT_READY on the initiator
side first upon receipt of the server's reply to the initial security side first upon receipt of the server's reply to the initial security
context token. context token.
skipping to change at page 24, line 5 skipping to change at page 23, line 11
normally must list the server mechs twice: once before and once after normally must list the server mechs twice: once before and once after
authentication, the latter using security layers. Since SCRAM does authentication, the latter using security layers. Since SCRAM does
not provide security layers the only ways to protect the mechanism not provide security layers the only ways to protect the mechanism
negotiation are: a) use channel binding to an external channel, or b) negotiation are: a) use channel binding to an external channel, or b)
use an external channel that authenticates a user-provided server use an external channel that authenticates a user-provided server
name. name.
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. on clients by sending a big iteration count value.
See [RFC4086] for more information about generating randomness.
10. IANA Considerations 10. IANA Considerations
IANA is requested to add the following family of SASL mechanisms to
the SASL Mechanism registry established by [RFC4422]:
To: iana@iana.org
Subject: Registration of a new SASL family SCRAM
SASL mechanism name (or prefix for the family): SCRAM-*
Security considerations: Section 7 of [RFCXXXX]
Published specification (optional, recommended): [RFCXXXX]
Person & email address to contact for further information:
IETF SASL WG <ietf-sasl@imc.org>
Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org>
Note: Members of this family must be explicitly registered
using the "IETF Consensus" registration procedure.
Reviews must be requested on the SASL WG mailing list.
"IETF Consensus" registration procedure MUST be used for registering
new mechanisms in this family. The SASL mailing list
<ietf-sasl@imc.org> (or a successor designated by the responsible
Security AD) MUST be used for soliciting reviews on such
registrations.
Note to future SCRAM- mechanism designers: each new SCRAM- SASL
mechanism MUST be explicitly registered with IANA and MUST comply
with SCRAM- mechanism naming convention defined in Section 4 of this
document.
IANA is requested to add the following entries to the SASL Mechanism IANA is requested to add the following entries to the SASL Mechanism
registry established by [RFC4422]: registry established by [RFC4422]:
To: iana@iana.org To: iana@iana.org
Subject: Registration of a new SASL mechanism SCRAM-SHA-1 Subject: Registration of a new SASL mechanism SCRAM-SHA-1
SASL mechanism name (or prefix for the family): SCRAM-SHA-1 SASL mechanism name (or prefix for the family): SCRAM-SHA-1
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:
skipping to change at page 24, line 34 skipping to change at page 25, line 17
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 <ietf-sasl@imc.org> IETF SASL WG <ietf-sasl@imc.org>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org> Owner/Change controller: IESG <iesg@ietf.org>
Note: Note:
Note that even though this document defines a family of SCRAM- This document also requests IANA to assign a GSS-API mechanism OID
mechanisms, it doesn't register a family of SCRAM- mechanisms in the for SCRAM.
SASL Mechanisms registry. IANA is requested to prevent future
registrations of SASL mechanisms starting with SCRAM- without
consulting the SASL mailing list <ietf-sasl@imc.org> first.
Note to future SCRAM- mechanism designers: each new SCRAM- SASL
mechanism MUST be explicitly registered with IANA and MUST comply
with SCRAM- mechanism naming convention defined in Section 4 of this
document.
We hereby request that IANA assign a GSS-API mechanism OID for SCRAM.
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 and Jeffrey Hutzelman for their contributions to this Josefsson and Jeffrey Hutzelman for their contributions to this
document. document.
Appendix A. Other Authentication Mechanisms Appendix A. Other Authentication Mechanisms
skipping to change at page 30, line 41 skipping to change at page 31, line 41
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
12.2. Normative References for GSS-API implementors 12.2. Normative References for GSS-API implementors
[I-D.ietf-sasl-gs2] [I-D.ietf-sasl-gs2]
Josefsson, S. and N. Williams, "Using GSS-API Mechanisms Josefsson, S. and N. Williams, "Using GSS-API Mechanisms
in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-12 in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-12
(work in progress), April 2009. (work in progress), April 2009.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005. Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006. Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
skipping to change at page 31, line 41 skipping to change at page 32, line 38
[I-D.ietf-sasl-crammd5-to-historic] [I-D.ietf-sasl-crammd5-to-historic]
Zeilenga, K., "CRAM-MD5 to Historic", Zeilenga, K., "CRAM-MD5 to Historic",
draft-ietf-sasl-crammd5-to-historic-00 (work in progress), draft-ietf-sasl-crammd5-to-historic-00 (work in progress),
November 2008. November 2008.
[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.ietf-sasl-rfc2831bis]
Melnikov, A., "Using Digest Authentication as a SASL
Mechanism", draft-ietf-sasl-rfc2831bis-12 (work in
progress), March 2007.
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997.
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
SHA-1", RFC 2202, September 1997.
[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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
June 2006. June 2006.
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006. Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[tls-server-end-point]
Zhu, L., "Registration of TLS server end-point channel
bindings", IANA http://www.iana.org/assignments/
channel-binding-types/tls-server-end-point, July 2008.
Authors' Addresses Authors' Addresses
Abhijit Menon-Sen Abhijit Menon-Sen
Oryx Mail Systems GmbH Oryx Mail Systems GmbH
Email: ams@oryx.com Email: ams@oryx.com
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
 End of changes. 32 change blocks. 
82 lines changed or deleted 92 lines changed or added

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