draft-ietf-sasl-scram-01.txt   draft-ietf-sasl-scram-02.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: November 27, 2009 Isode Ltd Expires: January 9, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
May 26, 2009 July 8, 2009
Salted Challenge Response (SCRAM) SASL Mechanism Salted Challenge Response (SCRAM) SASL Mechanism
draft-ietf-sasl-scram-01.txt draft-ietf-sasl-scram-02.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 November 27, 2009. This Internet-Draft will expire on January 9, 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 16 skipping to change at page 3, line 16
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 6. Channel Binding . . . . . . . . . . . . . . . . . . . 15
6.1. Channel Binding to TLS Channels . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 25
Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 26 Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 26
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 27 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 27
skipping to change at page 7, line 26 skipping to change at page 7, line 26
For simplicity, this family of mechanism does not presently include For simplicity, this family of mechanism does not presently include
negotiation of a security layer. It is intended to be used with an negotiation of a security layer. It is intended to be used with an
external security layer such as that provided by TLS or SSH, with external security layer such as that provided by TLS or SSH, with
optional channel binding [RFC5056] to the external security layer. 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 SCRAM is actually both, a GSS-API and SASL mechanism. This means that this document defines both, a SASL mechanism and a
GSS-API mechanism.
SCRAM provides the following protocol features: SCRAM provides the following protocol features:
o The authentication information stored in the authentication o The authentication information stored in the authentication
database is not sufficient by itself to impersonate the client. database is not sufficient by itself to impersonate the client.
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).
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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 hashed 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-")-lenght("-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.
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. In this case the server will binding to the external channel. In this case the server will
advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
server will advertise only SCRAM-SHA-1. The "-PLUS" exists to allow server will advertise only SCRAM-SHA-1. The "-PLUS" exists to allow
negotiation of the use of channel binding. See Section 6. negotiation of the use of channel binding. See Section 6.
5. SCRAM Authentication Exchange 5. SCRAM Authentication Exchange
SCRAM is a text protocol where the client and server exchange SCRAM is a SASL mechanism whose client response and server challenge
messages containing one or more attribute-value pairs separated by messages are text-based messages containing one or more attribute-
commas. Each attribute has a one-letter name. The messages and value pairs separated by commas. Each attribute has a one-letter
their attributes are described in Section 5.1, and defined in name. The messages and their attributes are described in
Section 7. Section 5.1, and defined in Section 7.
This is a simple example of a SCRAM-SHA-1 authentication exchange This is a simple example of a SCRAM-SHA-1 authentication exchange
when the client doesn't support channel bindings: when the client doesn't support channel bindings:
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=biwK,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:
C: p,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=cCx0bHMtc2VydmVyLWVuZC1wb2ludDrLWEW1c6dn7JKtAzqysWmX/ C: c=cD10bHMtc2VydmVyLWVuZC1wb2ludCwsy1hFtXOnZ+ySrQM6srFp
vu6q+3GuDucFjUF60Sv+A==,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 a 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
skipping to change at page 13, line 9 skipping to change at page 13, line 9
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 client must include it in its first used for authentication (a.k.a. "authentication identity"). A
message to the server. If the "a" attribute is not specified client must include it in its first message to the server. If the
(which would normally be the case), this username is also the "a" attribute is not specified (which would normally be the case),
identity which will be associated with the connection subsequent this username is also the identity which will be associated with
to authentication and authorization. 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 14, line 8 skipping to change at page 14, line 8
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); channel binding flag and an optional authzid). This header is
going to include channel binding type prefix (see [RFC5056], if
* followed by the external channel's channel binding type prefix and only if the client is using channel binding;
(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
skipping to change at page 15, line 16 skipping to change at page 15, line 16
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:
o The server advertises support for channel binding by advertising o Servers SHOULD advertise both non-PLUS (SCRAM-<hash-function>) and
both, SCRAM-<hash-function> and SCRAM-<hash-function>-PLUS. the PLUS-variant (SCRAM-<hash-function>-PLUS) SASL mechanism
names. If the server cannot support channel binding, it MAY
advertise only the non-PLUS variant. If the server would never
succeed authentication of the non-PLUS variant due to policy
reasons, it MAY advertise only the PLUS-variant.
o If the client negotiates mechanisms then client MUST select SCRAM- o If the client negotiates mechanisms then the client MUST select
<hash-function>-PLUS if offered by the server. Otherwise, if the SCRAM-<hash-function>-PLUS if offered by the server and the client
client does not negotiate mechanisms then it MUST select only wants to select SCRAM with the given hash function. [[anchor7: Is
SCRAM-<hash-function> (not suffixed with "-PLUS"). the following correct?]] Otherwise, if the client does not
negotiate mechanisms then it MUST select only SCRAM-<hash-
function> (not suffixed with "-PLUS").
o If the client and server both support channel binding, or if the o If the client supports channel binding and the server appears to
client wishes to use channel binding but the client does not support it (i.e., the client sees SCRAM-<hash-function>-PLUS), or
negotiate mechanisms, the client MUST set the GS2 channel binding if the client wishes to use channel binding but the client does
flag to "p" and MUST include channel binding data for the external not negotiate mechanisms, then the client MUST set the GS2 channel
channel in the computation of the "c=" attribute (see 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
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
then the client MUST set the GS2 channel binding flag to "y" and appear to (i.e., the client did not see SCRAM-<hash-function>-
MUST NOT include channel binding data for the external channel in PLUS) then the client MUST either fail authentication or it MUST
the computation of the "c=" attribute (see Section 5.1). chose the non-PLUS mechanism and set the GS2 channel binding flag
to "y" and MUST NOT include channel binding data for the external
channel in the computation of the "c=" attribute (see
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 If the server receives a client first message with the GS2 channel o Upon receipt of the client first message the server checks the GS2
binding flag set to "y" and the server supports channel binding channel binding flag (gs2-cb-flag).
the server MUST fail authentication. This is because if the
client sets the GS2 channel binding flag set to "y" then the * If the flag is set to "y" and the server supports channel
client must have believed that the server did not support channel binding the server MUST fail authentication. This is because
binding -- if the server did in fact support channel binding then if the client sets the GS2 channel binding flag set to "y" then
this is an indication that there has been a downgrade attack the client must have believed that the server did not support
(e.g., an attacker changed the server's mechanism list to exclude channel binding -- if the server did in fact support channel
the -PLUS suffixed SCRAM mechanism name(s)). binding then this is an indication that there has been a
downgrade attack (e.g., an attacker changed the server's
mechanism list to exclude the -PLUS suffixed SCRAM mechanism
name(s)).
* If the channel binding flag was "p" and the server does not
support the indicated channel binding type then the server MUST
fail authentication.
The server MUST always validate the client's "c=" field. The server The server MUST always validate the client's "c=" field. The server
does this by constructing the value of the "c=" attribute and then does this by constructing the value of the "c=" attribute and then
checking that it matches the client's c= attribute value. checking that it matches the client's c= attribute value.
6.1. Channel Binding to TLS Channels For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [RFC5056].
If an external TLS channel is to be bound into the authentication, 6.1. Default Channel Binding
and if the channel supports channel bindings of type 'tls-server-end-
point', then those MUST be used, else if the channel supports channel A default channel binding type agreement process for all SASL
bindings of type 'tls-unique' type, then those MUST be used. application protocols that do not provide their own channel binding
type agreement is provided as follows.
Clients and servers MUST implement the "tls-unique" [tls-unique]
channel binding type. Clients and servers SHOULD choose the highest-
layer/innermost end-to-end TLS channel as the channel to bind to.
Clients SHOULD choose the tls-unique channel binding type.
Conversely, clients MAY choose a different channel binding type based
on user input, configuration, or a future, as-yet undefined channel
binding type negotiation protocol. Servers MUST choose the channel
binding type indicated by the client, if they support it.
7. Formal Syntax 7. Formal Syntax
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)>
skipping to change at page 17, line 50 skipping to change at page 17, line 50
posit-number = %x31-39 *DIGIT posit-number = %x31-39 *DIGIT
;; A positive number ;; A positive number
saslname = 1*(value-safe-char / "=2C" / "=3D") saslname = 1*(value-safe-char / "=2C" / "=3D")
;; Conforms to <value> ;; Conforms to <value>
authzid = "a=" saslname authzid = "a=" saslname
;; Protocol specific. ;; Protocol specific.
gs2-cbind-flag = "n" / "y" / "p" cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056 section 7.
;; E.g. "tls-server-end-point" or
;; "tls-unique"
gs2-cbind-flag = "p=" cb-name / "n" / "y"
;; "n" -> client doesn't support channel binding ;; "n" -> client doesn't support channel binding
;; "y" -> client does support channel binding ;; "y" -> client does support channel binding
;; but thinks the server does not. ;; but thinks the server does not.
;; "p" -> client requires channel binding ;; "p" -> client requires channel binding.
;; The selected channel binding follows "p=".
gs2-header = gs2-cbind-flag [ authzid ] "," gs2-header = gs2-cbind-flag "," [ authzid ] ","
;; GS2 header for SCRAM ;; GS2 header for SCRAM
;; (the actual GS2 header includes an optional ;; (the actual GS2 header includes an optional
;; flag to indicate that the GSS mechanism is not ;; flag to indicate that the GSS mechanism is not
;; "standard" but since SCRAM is "standard" we ;; "standard" but since SCRAM is "standard" we
;; don't include that flag). ;; don't include that flag).
username = "n=" saslname username = "n=" saslname
;; Usernames are prepared using SASLPrep. ;; Usernames are prepared using SASLPrep.
reserved-mext = "m=" 1*(value-char) reserved-mext = "m=" 1*(value-char)
skipping to change at page 19, line 23 skipping to change at page 19, line 28
;; The error message is only for the GSS-API ;; The error message is only for the GSS-API
;; form of SCRAM, and it is OPTIONAL to ;; form of SCRAM, and it is OPTIONAL to
;; implement it. ;; implement it.
extensions = attr-val *("," attr-val) extensions = attr-val *("," attr-val)
;; All extensions are optional, ;; All extensions are optional,
;; i.e. unrecognized attributes ;; i.e. unrecognized attributes
;; not defined in this document ;; not defined in this document
;; MUST be ignored. ;; MUST be ignored.
cbind-data = *OCTET cbind-data = 1*OCTET
cbind-type = value
;; e.g. "tls-server-end-point" or
;; "tls-unique"
cbind-input = gs2-header [ cbind-type ":" cbind-data ] cbind-input = gs2-header [ cbind-data ]
;; cbind-data MUST be present for
;; gs2-cbind-flag of "p" and MUST be absent
;; for "y" or "n".
8. SCRAM as a GSS-API Mechanism 8. SCRAM as a GSS-API Mechanism
This section and its sub-sections and all normative references of it This section and its sub-sections and all normative references of it
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,
skipping to change at page 25, line 7 skipping to change at page 25, line 7
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.
We hereby request that IANA assign a GSS-API mechanism OID for SCRAM. We hereby request that IANA assign a GSS-API mechanism OID for SCRAM.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Dave Cridland for his contributions This document benefited from discussions on the SASL WG mailing list.
to this document. The authors would like to specially thank Dave Cridland, Simon
Josefsson and Jeffrey Hutzelman for 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 24 skipping to change at page 31, line 24
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
Kerberos V Generic Security Service Application Program Kerberos V Generic Security Service Application Program
Interface (GSS-API) Mechanism", RFC 4402, February 2006. Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[tls-unique]
Zhu, L., "Registration of TLS unique channel binding
(generic)", IANA http://www.iana.org/assignments/
channel-binding-types/tls-unique, July 2008.
12.3. Informative References 12.3. Informative References
[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),
 End of changes. 28 change blocks. 
65 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/