draft-ietf-sasl-scram-09.txt   draft-ietf-sasl-scram-10.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: April 10, 2010 Isode Ltd Expires: April 16, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
October 7, 2009 October 13, 2009
Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism
draft-ietf-sasl-scram-09.txt draft-ietf-sasl-scram-10.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 April 10, 2010. This Internet-Draft will expire on April 16, 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 19 skipping to change at page 3, line 19
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 . . . . . . . . . . . . . . . . 11 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . 11
5. SCRAM Authentication Exchange . . . . . . . . . . . . 12 5. SCRAM Authentication Exchange . . . . . . . . . . . . 12
5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 13 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 13
5.2. Compliance with SASL mechanism requirements . . . . . 16 5.2. Compliance with SASL mechanism requirements . . . . . 16
6. Channel Binding . . . . . . . . . . . . . . . . . . . 17 6. Channel Binding . . . . . . . . . . . . . . . . . . . 17
6.1. Default Channel Binding . . . . . . . . . . . . . . . 18 6.1. Default Channel Binding . . . . . . . . . . . . . . . 18
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 19 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 19
8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 22 8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 23
8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 22 8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 23
8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 22 8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 23
8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 23 8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . 29
Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 29 Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 30
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 30 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 31
Appendix C. Internet-Draft Change History . . . . . . . . . . . . 31 Appendix C. Internet-Draft Change History . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . 34
12.2. Normative References for GSS-API implementors . . . . 33 12.2. Normative References for GSS-API implementors . . . . 34
12.3. Informative References . . . . . . . . . . . . . . . . 34 12.3. Informative References . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . 37
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 5, line 26 skipping to change at page 5, line 26
o ":=": The variable on the left hand side represents the octet o ":=": The variable on the left hand side represents the octet
string resulting from the expression on the right hand side. string resulting from the expression on the right hand side.
o "+": Octet string concatenation. o "+": Octet string concatenation.
o "[ ]": A portion of an expression enclosed in "[" and "]" may not o "[ ]": A portion of an expression enclosed in "[" and "]" may not
be included in the result under some circumstances. See the be included in the result under some circumstances. See the
associated text for a description of those circumstances. associated text for a description of those circumstances.
o Normalize(str): Apply a Unicode normalization algorithm to a UTF-8 o Normalize(str): Apply the SASLPrep profile [RFC4013] of the
[RFC3629] encoded "str". The resulting string is also in UTF-8. "stringprep" algorithm [RFC3454] as the normalization algorithm to
Implementations SHOULD use the SASLPrep profile [RFC4013] of the a UTF-8 [RFC3629] encoded "str". The resulting string is also in
"stringprep" algorithm [RFC3454] as the normalization algorithm. UTF-8. When applying SASLPrep, "str" is treated as a "stored
When applying SASLPrep, "str" is treated as a "stored strings", strings", which means that unassigned Unicode codepoints are
which means that unassigned Unicode codepoints are prohibited (see prohibited (see Section 7 of [RFC3454]). Note that
Section 7 of [RFC3454]). implementations MUST either implement SASLPrep, or disallow use of
non US-ASCII Unicode codepoints in "str".
o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
[RFC2104]) using the octet string represented by "key" as the key [RFC2104]) using the octet string represented by "key" as the key
and the octet string "str" as the input string. The size of the and the octet string "str" as the input string. The size of the
result is the hash result size for the hash function in use. For result is the hash result size for the hash function in use. For
example, it is 20 octets for SHA-1 (see [RFC3174]). example, it is 20 octets for SHA-1 (see [RFC3174]).
o H(str): Apply the cryptographic hash function to the octet string o H(str): Apply the cryptographic hash function to the octet string
"str", producing an octet string as a result. The size of the "str", producing an octet string as a result. The size of the
result depends on the hash result size for the hash function in result depends on the hash result size for the hash function in
skipping to change at page 9, line 31 skipping to change at page 9, line 31
authentication information, i.e. a salt, StoredKey, ServerKey and the authentication information, i.e. a salt, StoredKey, ServerKey and the
iteration count i. (Note that a server implementation may choose to iteration count i. (Note that a server implementation may choose to
use the same iteration count for all accounts.) The server sends the use the same iteration count for all accounts.) The server sends the
salt and the iteration count to the client, which then computes the salt and the iteration count to the client, which then computes the
following values and sends a ClientProof to the server: following values and sends a ClientProof to the server:
(*) - Note that both the username and the password MUST be encoded in (*) - Note that both the username and the password MUST be encoded in
UTF-8 [RFC3629]. UTF-8 [RFC3629].
Informative Note: Implementors are encouraged to create test cases Informative Note: Implementors are encouraged to create test cases
that use both username passwords with non-ASCII characters. In that use both username passwords with non-ASCII codepoints. In
particular, it's useful to test characters whose "Unicode particular, it's useful to test codepoints whose "Unicode
Normalization Form C" and "Unicode Normalization Form KC" are Normalization Form C" and "Unicode Normalization Form KC" are
different. Some examples of such characters include Vulgar Fraction different. Some examples of such codepoints include Vulgar Fraction
One Half (U+00BD) and Acute Accent (U+00B4). One Half (U+00BD) and Acute Accent (U+00B4).
SaltedPassword := Hi(Normalize(password), salt, i) SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key") ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey) StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," + AuthMessage := client-first-message-bare + "," +
server-first-message + "," + server-first-message + "," +
client-final-message-without-proof client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage) ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof := ClientKey XOR ClientSignature ClientProof := ClientKey XOR ClientSignature
skipping to change at page 11, line 11 skipping to change at page 11, line 11
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 hash function taken from the IANA uppercased name of the underlying hash function taken from the IANA
"Hash Function Textual Names" registry (see http://www.iana.org), "Hash Function Textual Names" registry (see http://www.iana.org),
optionally followed by the suffix "-PLUS" (see below). Note that optionally followed by the suffix "-PLUS" (see below). Note that
SASL mechanism names are limited to 20 characters, which means that SASL mechanism names are limited to 20 octets, which means that only
only hash function names with lengths shorter or equal to 9 hash function names with lengths shorter or equal to 9 octets (20-
characters (20-length("SCRAM-")-length("-PLUS") can be used. For length("SCRAM-")-length("-PLUS") can be used. For cases when the
cases when the underlying hash function name is longer than 9 underlying hash function name is longer than 9 octets, an alternative
characters, an alternative 9 character (or shorter) name can be used 9 octet (or shorter) name can be used to construct the corresponding
to construct the corresponding SCRAM mechanism name, as long as this SCRAM mechanism name, as long as this alternative name doesn't
alternative name doesn't conflict with any other hash function name conflict with any other hash function name from the IANA "Hash
from the IANA "Hash Function Textual Names" registry. In order to Function Textual Names" registry. In order to prevent future
prevent future conflict, such alternative name SHOULD be registered conflict, such alternative name SHOULD be registered in the IANA
in the IANA "Hash Function Textual Names" registry. "Hash Function Textual Names" registry.
For interoperability, all SCRAM clients and servers MUST implement For interoperability, all SCRAM clients and servers MUST implement
the SCRAM-SHA-1 authentication mechanism, i.e. an authentication the SCRAM-SHA-1 authentication mechanism, i.e. an authentication
mechanism from the SCRAM family that uses the SHA-1 hash function as mechanism from the SCRAM family that uses the SHA-1 hash function as
defined in [RFC3174]. defined in [RFC3174].
The "-PLUS" suffix is used only when the server supports channel The "-PLUS" suffix is used only when the server supports channel
binding to the external channel. If the server supports channel binding to the external channel. If the server supports channel
binding, it will advertise both the "bare" and "plus" versions of binding, it will advertise both the "bare" and "plus" versions of
whatever mechanisms it supports (e.g., if the server supports only whatever mechanisms it supports (e.g., if the server supports only
skipping to change at page 14, line 36 skipping to change at page 14, line 36
prepare the username using the "SASLPrep" profile [RFC4013] of prepare the username using the "SASLPrep" profile [RFC4013] of
the "stringprep" algorithm [RFC3454] treating it as a query the "stringprep" algorithm [RFC3454] treating it as a query
string (i.e., unassigned Unicode code points are allowed). If string (i.e., unassigned Unicode code points are allowed). If
the preparation of the username fails or results in an empty the preparation of the username fails or results in an empty
string, the client SHOULD abort the authentication exchange 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 MUST
prepare it using the "SASLPrep" profile [RFC4013] of the either prepare it using the "SASLPrep" profile [RFC4013] of the
"stringprep" algorithm [RFC3454] treating it as a query string "stringprep" algorithm [RFC3454] treating it as a query string
(i.e., unassigned Unicode code points are allowed). If the (i.e., unassigned Unicode codepoints are allowed) or otherwise
preparation of the username fails or results in an empty be prepared to do SASLprep-aware string comparisons and/or
string, the server SHOULD abort the authentication exchange. index lookups. If the preparation of the username fails or
Whether or not the server prepares the username using results in an empty string, the server SHOULD abort the
"SASLPrep", it MUST use it as received in hash calculations. authentication exchange. Whether or not the server prepares
the username using "SASLPrep", it MUST use it as received in
hash calculations.
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 19, line 11 skipping to change at page 19, line 11
Servers MUST choose the channel binding type indicated by the client, Servers MUST choose the channel binding type indicated by the client,
or fail authentication if they don't support it. or fail authentication if they don't 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)>
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)>
attr-val = ALPHA "=" value attr-val = ALPHA "=" value
;; Generic syntax of any attribute sent ;; Generic syntax of any attribute sent
;; by server or client ;; 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 / "="
printable = %x21-2B / %x2D-7E printable = %x21-2B / %x2D-7E
;; Printable ASCII except ",". ;; Printable ASCII except ",".
;; Note that any "printable" is also ;; Note that any "printable" is also
;; a valid "value". ;; a valid "value".
base64-char = ALPHA / DIGIT / "/" / "+" base64-char = ALPHA / DIGIT / "/" / "+"
base64-4 = 4base64-char base64-4 = 4base64-char
base64-3 = 3base64-char "=" base64-3 = 3base64-char "="
base64-2 = 2base64-char "==" base64-2 = 2base64-char "=="
base64 = *base64-4 [base64-3 / base64-2] base64 = *base64-4 [base64-3 / base64-2]
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.
cb-name = 1*(ALPHA / DIGIT / "." / "-") cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056 section 7. ;; See RFC 5056 section 7.
;; E.g. "tls-server-end-point" or ;; E.g. "tls-server-end-point" or
;; "tls-unique" ;; "tls-unique"
gs2-cbind-flag = "p=" cb-name / "n" / "y" 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=". ;; 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)
;; Reserved for signalling mandatory extensions. ;; Reserved for signalling mandatory extensions.
;; The exact syntax will be defined in ;; The exact syntax will be defined in
;; the future. ;; the future.
channel-binding = "c=" base64 channel-binding = "c=" base64
;; base64 encoding of cbind-input ;; base64 encoding of cbind-input
proof = "p=" base64 proof = "p=" base64
nonce = "r=" c-nonce [s-nonce] nonce = "r=" c-nonce [s-nonce]
;; Second part provided by server. ;; Second part provided by server.
c-nonce = printable c-nonce = printable
s-nonce = printable s-nonce = printable
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-bare = client-first-message-bare =
[reserved-mext ","] [reserved-mext ","]
username "," nonce ["," extensions] username "," nonce ["," extensions]
client-first-message = client-first-message =
gs2-header client-first-message-bare 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
gss-server-error = "e=" value server-error = "e=" server-error-value
server-final-message = gss-server-error /
verifier ["," extensions]
;; The error message is only for the GSS-API
;; form of SCRAM, and it is OPTIONAL to
;; implement it.
extensions = attr-val *("," attr-val) server-error-value = "invalid-encoding" /
;; All extensions are optional, "extensions-not-supported" / ; unrecognized 'm' value
;; i.e. unrecognized attributes "invalid-proof" /
;; not defined in this document "channel-bindings-dont-match" /
;; MUST be ignored. "server-does-support-channel-binding" /
; server does not support channel binding
"channel-binding-not-supported" /
"unsupported-channel-binding-type" /
"unknown-user" /
"invalid-username-encoding" /
; invalid username encoding (invalid UTF-8 or
; SASLprep failed)
"no-resources" /
"other-error" /
server-error-value-ext
; Unrecognized errors should be treated as "other-error".
; In order to prevent information disclosure the server
; may substitute the real reason with "other-error".
cbind-data = 1*OCTET server-error-value-ext = value
; Additional error reasons added by extensions
; to this document.
cbind-input = gs2-header [ cbind-data ] server-final-message = (server-error / verifier)
;; cbind-data MUST be present for ["," extensions]
;; gs2-cbind-flag of "p" and MUST be absent ;; The error message is only for the GSS-API
;; for "y" or "n". ;; form of SCRAM, and it is OPTIONAL to
;; implement it.
extensions = attr-val *("," attr-val)
;; All extensions are optional,
;; i.e. unrecognized attributes
;; not defined in this document
;; MUST be ignored.
cbind-data = 1*OCTET
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,
 End of changes. 48 change blocks. 
137 lines changed or deleted 164 lines changed or added

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