draft-ietf-sasl-scram-06.txt   draft-ietf-sasl-scram-07.txt 
NETWORK WORKING GROUP A. Menon-Sen NETWORK WORKING GROUP A. Menon-Sen
Internet-Draft Oryx Mail Systems GmbH Internet-Draft Oryx Mail Systems GmbH
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Melnikov
Expires: March 13, 2010 Isode Ltd Expires: March 14, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
September 9, 2009 September 10, 2009
Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism
draft-ietf-sasl-scram-06.txt draft-ietf-sasl-scram-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 13, 2010. This Internet-Draft will expire on March 14, 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 7, line 47 skipping to change at page 7, line 47
o The server does not gain the ability to impersonate the client to o The server does not gain the ability to impersonate the client to
other servers (with an exception for server-authorized proxies). other servers (with an exception for server-authorized proxies).
o The mechanism permits the use of a server-authorized proxy without o The mechanism permits the use of a server-authorized proxy without
requiring that proxy to have super-user rights with the back-end requiring that proxy to have super-user rights with the back-end
server. server.
o Mutual authentication is supported, but only the client is named o Mutual authentication is supported, but only the client is named
(i.e., the server has no name). (i.e., the server has no name).
o When used as a SASL mechanism, SCRAM is capable of transporting
authorization identities (see [RFC4422], Section 2) from the
client to the server.
A separate document defines a standard LDAPv3 [RFC4510] attribute A separate document defines a standard LDAPv3 [RFC4510] attribute
that enables storage of the SCRAM authentication information in LDAP. that enables storage of the SCRAM authentication information in LDAP.
See [I-D.melnikov-sasl-scram-ldap]. See [I-D.melnikov-sasl-scram-ldap].
For an in-depth discussion of why other challenge response mechanisms For an in-depth discussion of why other challenge response mechanisms
are not considered sufficient, see appendix A. For more information are not considered sufficient, see appendix A. For more information
about the motivations behind the design of this mechanism, see about the motivations behind the design of this mechanism, see
appendix B. appendix B.
Comments regarding this draft may be sent either to the sasl@ietf.org Comments regarding this draft may be sent either to the sasl@ietf.org
mailing list or to the authors. mailing list or to the authors.
skipping to change at page 11, line 13 skipping to change at page 11, line 13
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 SASL mechanism whose client response and server challenge SCRAM is a SASL mechanism whose client response and server challenge
messages are text-based messages containing one or more attribute- messages are text-based messages containing one or more attribute-
value pairs separated by commas. Each attribute has a one-letter value pairs separated by commas. Each attribute has a one-letter
name. The messages and their attributes are described in name. The messages and their attributes are described in
Section 5.1, and defined in Section 7. Section 5.1, and defined in Section 7.
SCRAM is a client-first SASL mechanism (See [RFC4422], Section 5,
item 2a), and returns additional data together with a server's
indication of a successful outcome.
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=biwsCg==,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 C: c=biwsCg==,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
S: v=WxPv/siO5l+qxN4 S: v=WxPv/siO5l+qxN4
[[anchor5: Note that the all hashes above are fake and will be fixed [[anchor5: Note that the all hashes above are fake and will be fixed
during AUTH48.]] during AUTH48.]]
skipping to change at page 13, line 35 skipping to change at page 13, line 38
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 SHOULD
prepare it using the "SASLPrep" profile [RFC4013] of the prepare it using the "SASLPrep" profile [RFC4013] of the
"stringprep" algorithm [RFC3454] treating it as a stored string "stringprep" algorithm [RFC3454] treating it as a query string
(i.e., unassigned Unicode code points are forbidden). If the (i.e., unassigned Unicode code points are allowed). If the
preparation of the username fails or results in an empty preparation of the username fails or results in an empty
string, the server SHOULD abort the authentication exchange. string, the server SHOULD abort the 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.
o r: This attribute specifies a sequence of random printable o r: This attribute specifies a sequence of random printable ASCII
characters excluding ',' which forms the nonce used as input to characters excluding ',' which forms the nonce used as input to
the hash function. No quoting is applied to this string. As the hash function. No quoting is applied to this string. As
described earlier, the client supplies an initial value in its described earlier, the client supplies an initial value in its
first message, and the server augments that value with its own first message, and the server augments that value with its own
nonce in its first response. It is important that this value be nonce in its first response. It is important that this value be
different for each authentication. The client MUST verify that different for each authentication. The client MUST verify that
the initial part of the nonce used in subsequent messages is the the initial part of the nonce used in subsequent messages is the
same as the nonce it initially specified. The server MUST verify same as the nonce it initially specified. The server MUST verify
that the nonce sent by the client in the second message is the that the nonce sent by the client in the second message is the
same as the one sent by the server in its first message. same as the one sent by the server in its first message.
o c: This REQUIRED attribute specifies base64-encoded of a header o c: This REQUIRED attribute specifies the base64-encoded GS2 header
and the channel-binding data. It is sent by the client in its and channel-binding data. It is sent by the client in its second
second authentication message. The header consist of: authentication message. The attribute data consist of:
* the GS2 header from the client's first message (recall: a * the GS2 header from the client's first message (recall: a
channel binding flag and an optional authzid). This header is channel binding flag and an optional authzid). This header is
going to include channel binding type prefix (see [RFC5056]), going to include channel binding type prefix (see [RFC5056]),
if and only if the client is using channel binding; if and only if the client is using channel binding;
* followed by the external channel's channel binding data, if and * followed by the external channel's channel binding data, if and
only if the client is using channel binding. only if the client is using channel binding.
o s: This attribute specifies the base64-encoded salt used by the o s: This attribute specifies the base64-encoded salt used by the
skipping to change at page 18, line 29 skipping to change at page 18, line 29
;; 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 ASCII except ",".
;; Note that any "printable" is also
;; 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]
skipping to change at page 19, line 34 skipping to change at page 19, line 40
;; 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 = value c-nonce = printable
s-nonce = value 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 =
 End of changes. 14 change blocks. 
12 lines changed or deleted 28 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/