draft-ietf-sasl-scram-05.txt   draft-ietf-sasl-scram-06.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: February 27, 2010 Isode Ltd Expires: March 13, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
August 26, 2009 September 9, 2009
Salted Challenge Response (SCRAM) SASL Mechanism Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism
draft-ietf-sasl-scram-05.txt draft-ietf-sasl-scram-06.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 February 27, 2010. This Internet-Draft will expire on March 13, 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 15 skipping to change at page 3, line 15
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 . . . . . . . . . . . . . . . . 10
5. SCRAM Authentication Exchange . . . . . . . . . . . . 11 5. SCRAM Authentication Exchange . . . . . . . . . . . . 11
5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
6. Channel Binding . . . . . . . . . . . . . . . . . . . 15 5.2. Compliance with SASL mechanism requirements . . . . . 15
6.1. Default Channel Binding . . . . . . . . . . . . . . . 16 6. Channel Binding . . . . . . . . . . . . . . . . . . . 16
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 17 6.1. Default Channel Binding . . . . . . . . . . . . . . . 17
8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 18
8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 20 8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 21
8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20 8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 21
8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 21 8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . 22 8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . 25
Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . 27
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 28 Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 28
Appendix C. Internet-Draft Change History . . . . . . . . . . . . 29 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . 31 Appendix C. Internet-Draft Change History . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . 32
12.2. Normative References for GSS-API implementors . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . 32
12.3. Informative References . . . . . . . . . . . . . . . . 32 12.2. Normative References for GSS-API implementors . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . 34 12.3. Informative References . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . 35
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 8, line 7 skipping to change at page 8, line 7
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 Comments regarding this draft may be sent either to the sasl@ietf.org
ietf-sasl@imc.org mailing list or to the authors. 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 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. 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 choose to use the same iteration count for all
accounts.) 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-bare + "," + AuthMessage := client-first-message-bare + "," +
server-first-message + "," + server-first-message + "," +
client-final-message-without-proof client-final-message-without-proof
skipping to change at page 11, line 38 skipping to change at page 11, line 38
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.]]
First, the client sends a message containing: First, the client sends the "client-first-message" containing:
o a GS2 header consisting of a flag indicating whether channel o a GS2 header consisting of a flag indicating whether channel
binding is supported-but-not-used, not supported, or used, and an binding is supported-but-not-used, not supported, or used, and an
optional SASL authorization identity; optional SASL authorization identity;
o SCRAM username and a random, unique nonce attributes. o SCRAM username and a random, unique nonce attributes.
Note that the client's first message will always start with "n", "y" Note that the client's first message will always start with "n", "y"
or "p", otherwise the message is invalid and authentication MUST or "p", otherwise the message is invalid and authentication MUST
fail. This is important, as it allows for GS2 extensibility (e.g., fail. This is important, as it allows for GS2 extensibility (e.g.,
to add support for security layers). to add support for security layers).
In response, the server sends the user's iteration count i, the In response, the server sends a "server-first-message" containing the
user's salt, and appends its own nonce to the client-specified one. user's iteration count i, the user's salt, and appends its own nonce
The client then responds with the same nonce and a ClientProof to the client-specified one.
computed using the selected hash function as explained earlier. The
server verifies the nonce and the proof, verifies that the The client then responds by sending "client-final-message" with the
same nonce and a ClientProof computed using the selected hash
function as explained earlier.
The server verifies the nonce and the proof, verifies that the
authorization identity (if supplied by the client in the first authorization identity (if supplied by the client in the first
message) is authorized to act as the authentication identity, and, message) is authorized to act as the authentication identity, and,
finally, it responds with a ServerSignature, concluding the finally, it responds with a "server-final-message", concluding the
authentication exchange. The client then authenticates the server by authentication exchange.
computing the ServerSignature and comparing it to the value sent by
the server. If the two are different, the client MUST consider the The client then authenticates the server by computing the
authentication exchange to be unsuccessful and it might have to drop ServerSignature and comparing it to the value sent by the server. If
the connection. the two are different, the client MUST consider the authentication
exchange to be unsuccessful and it might have to drop the connection.
5.1. SCRAM Attributes 5.1. SCRAM Attributes
This section describes the permissible attributes, their use, and the This section describes the permissible attributes, their use, and the
format of their values. All attribute names are single US-ASCII format of their values. All attribute names are single US-ASCII
letters and are case-sensitive. letters and are case-sensitive.
Note that the order of attributes in client or server messages is Note that the order of attributes in client or server messages is
fixed, with the exception of extension attributes (described by the fixed, with the exception of extension attributes (described by the
"extensions" ABNF production), which can appear in any order in the "extensions" ABNF production), which can appear in any order in the
skipping to change at page 13, line 17 skipping to change at page 13, line 22
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" used for authentication (a.k.a. "authentication identity"
[RFC4422]). A client MUST include it in its first message to the [RFC4422]). A client MUST include it in its first message to the
server. If the "a" attribute is not specified (which would server. If the "a" attribute is not specified (which would
normally be the case), this username is also the identity which normally be the case), this username is also the identity which
will be associated with the connection subsequent to will be associated with the connection subsequent to
authentication and authorization. authentication and authorization.
Before sending the username to the server, the client MUST Before sending the username to the server, the client SHOULD
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] treating it as a query
the username fails or results in an empty string, the client string (i.e., unassigned Unicode code points are allowed). If
SHOULD abort the authentication exchange (*). the preparation of the username fails or results in an empty
string, the client 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.
Upon receipt of the username by the server, the server SHOULD Upon receipt of the username by the server, the server SHOULD
prepare it using the "SASLPrep" profile [RFC4013] of the prepare it using the "SASLPrep" profile [RFC4013] of the
"stringprep" algorithm [RFC3454]. If the preparation of the "stringprep" algorithm [RFC3454] treating it as a stored string
username fails or results in an empty string, the server SHOULD (i.e., unassigned Unicode code points are forbidden). If the
abort the authentication exchange. preparation of the username fails or results in an empty
string, the server SHOULD abort the authentication exchange.
The characters ',' or '=' in usernames are sent as '=2C' and The characters ',' or '=' in usernames are sent as '=2C' and
'=3D' respectively. If the server receives a username which '=3D' respectively. If the server receives a username which
contains '=' not followed by either '2C' or '3D', then the contains '=' not followed by either '2C' or '3D', then the
server MUST fail the authentication. server MUST fail the authentication.
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.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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.
5.2. Compliance with SASL mechanism requirements
This section describes compliance with SASL mechanism requirements
specified in Section 5 of [RFC4422].
1) "SCRAM-SHA-1" and "SCRAM-SHA-1-PLUS".
2a) SCRAM is a client-first mechanism.
2b) SCRAM sends additional data with success.
3) SCRAM is capable of transferring authorization identities from the
client to the server.
4) SCRAM does not offer any security layers (SCRAM offers channel
binding instead).
5) SCRAM has a hash protecting the authorization identity.
6. Channel Binding 6. Channel Binding
SCRAM supports channel binding to external secure channels, such as SCRAM supports channel binding to external secure channels, such as
TLS. Clients and servers may or may not support channel binding, TLS. Clients and servers may or may not support channel binding,
therefore the use of channel binding is negotiable. SCRAM does not therefore the use of channel binding is negotiable. SCRAM does not
provide security layers, however, therefore it is imperative that provide security layers, however, therefore it is imperative that
SCRAM provide integrity protection for the negotiation of channel SCRAM provide integrity protection for the negotiation of channel
binding. binding.
Use of channel binding is negotiated as follows: Use of channel binding is negotiated as follows:
skipping to change at page 20, line 42 skipping to change at page 21, line 42
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] (see
the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962]. Section 4.2 and sub-sections), using 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 "protocol key" SHALL be derived by using the
significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session least significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API
key" || ClientKey || AuthMessage). session key" || ClientKey || AuthMessage). "Specific keys" are then
derived as usual as described in Section 2 of [RFC4121], [RFC3961]
and [RFC3962].
The terms "protocol key" and "specific key" are Kerberos V5 terms
[RFC3961].
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.
8.3. GSS_Pseudo_random() for SCRAM 8.3. GSS_Pseudo_random() for SCRAM
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
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, then a passive eavesdropper can gain sufficient information to
mount an offline dictionary or brute-force attack which can be used mount an offline dictionary or brute-force attack which can be used
to recover the user's password. The amount of time necessary for to recover the user's password. The amount of time necessary for
this attack depends on the cryptographic hash function selected, the this attack depends on the cryptographic hash function selected, the
strength of the password and the iteration count supplied by the strength of the password and the iteration count supplied by the
server. An external security layer with strong encryption will server. An external security layer with strong encryption will
skipping to change at page 22, line 31 skipping to change at page 23, line 31
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.
If the authentication information is stolen from the authentication If the authentication information is stolen from the authentication
database, then an offline dictionary or brute-force attack can be database, then an offline dictionary or brute-force attack can be
used to recover the user's password. The use of salt mitigates this used to recover the user's password. The use of salt mitigates this
attack somewhat by requiring a separate attack on each password. attack somewhat by requiring a separate attack on each password.
Authentication mechanisms which protect against this attack are Authentication mechanisms which protect against this attack are
available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is
an example of such technology. There are IPR disclosures at an example of such technology. The WG selected not to use EKE like
http://datatracker.ietf.org/ipr/ that mention RFC 2945. mechanisms as basis for SCRAM.
If an attacker obtains the authentication information from the If an attacker obtains the authentication information from the
authentication repository and either eavesdrops on one authentication authentication repository and either eavesdrops on one authentication
exchange or impersonates a server, the attacker gains the ability to exchange or impersonates a server, the attacker gains the ability to
impersonate that user to all servers providing SCRAM access using the impersonate that user to all servers providing SCRAM access using the
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 SASL mechanism negotiation. It is negotiation is left to the SASL mechanism negotiation. It is
skipping to change at page 24, line 17 skipping to change at page 25, line 17
IANA is requested to add the following family of SASL mechanisms to IANA is requested to add the following family of SASL mechanisms to
the SASL Mechanism registry established by [RFC4422]: the SASL Mechanism registry established by [RFC4422]:
To: iana@iana.org To: iana@iana.org
Subject: Registration of a new SASL family SCRAM Subject: Registration of a new SASL family SCRAM
SASL mechanism name (or prefix for the family): SCRAM-* SASL mechanism name (or prefix for the family): SCRAM-*
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 <sasl@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org> Owner/Change controller: IESG <iesg@ietf.org>
Note: Members of this family must be explicitly registered Note: Members of this family must be explicitly registered
using the "IETF Consensus" registration procedure. using the "IETF Review" [RFC5226] registration procedure.
Reviews must be requested on the SASL WG mailing list. Reviews must be requested on the SASL WG mailing list.
"IETF Consensus" registration procedure MUST be used for registering "IETF Review" [RFC5226] registration procedure MUST be used for
new mechanisms in this family. The SASL mailing list registering new mechanisms in this family. The SASL mailing list
<ietf-sasl@imc.org> (or a successor designated by the responsible <sasl@ietf.org> (or a successor designated by the responsible
Security AD) MUST be used for soliciting reviews on such Security AD) MUST be used for soliciting reviews on such
registrations. registrations.
Note to future SCRAM- mechanism designers: each new SCRAM- SASL Note to future SCRAM- mechanism designers: each new SCRAM- SASL
mechanism MUST be explicitly registered with IANA and MUST comply mechanism MUST be explicitly registered with IANA and MUST comply
with SCRAM- mechanism naming convention defined in Section 4 of this with SCRAM- mechanism naming convention defined in Section 4 of this
document. 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:
IETF SASL WG <ietf-sasl@imc.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:
To: iana@iana.org To: iana@iana.org
Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS
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 <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. for SCRAM from the iso.org.dod.internet.security.mechanisms 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 and Jeffrey Hutzelman for their contributions to this Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen and Peter
document. Saint-Andrefor their contributions to this document.
Appendix A. Other Authentication Mechanisms Appendix A. Other Authentication Mechanisms
The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
proved to be too complex to implement and test, and thus has poor proved to be too complex to implement and test, and thus has poor
interoperability. The security layer is often not implemented, and interoperability. The security layer is often not implemented, and
almost never used; everyone uses TLS instead. For a more complete almost never used; everyone uses TLS instead. For a more complete
list of problems with DIGEST-MD5 which lead to the creation of SCRAM list of problems with DIGEST-MD5 which lead to the creation of SCRAM
see [I-D.ietf-sasl-digest-to-historic]. see [I-D.ietf-sasl-digest-to-historic].
skipping to change at page 31, line 51 skipping to change at page 32, line 51
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.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[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.
[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
skipping to change at page 32, line 27 skipping to change at page 33, line 30
[tls-unique] [tls-unique]
Zhu, L., "Registration of TLS unique channel binding Zhu, L., "Registration of TLS unique channel binding
(generic)", IANA http://www.iana.org/assignments/ (generic)", IANA http://www.iana.org/assignments/
channel-binding-types/tls-unique, July 2008. channel-binding-types/tls-unique, July 2008.
12.3. Informative References 12.3. Informative References
[I-D.altman-tls-channel-bindings] [I-D.altman-tls-channel-bindings]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", draft-altman-tls-channel-bindings-05 (work in for TLS", draft-altman-tls-channel-bindings-06 (work in
progress), June 2009. progress), August 2009.
[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.
skipping to change at page 33, line 15 skipping to change at page 34, line 18
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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] [tls-server-end-point]
Zhu, L., "Registration of TLS server end-point channel Zhu, L., "Registration of TLS server end-point channel
bindings", IANA http://www.iana.org/assignments/ bindings", IANA http://www.iana.org/assignments/
channel-binding-types/tls-server-end-point, July 2008. channel-binding-types/tls-server-end-point, July 2008.
Authors' Addresses Authors' Addresses
 End of changes. 28 change blocks. 
64 lines changed or deleted 108 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/