draft-ietf-sasl-scram-00.txt   draft-ietf-sasl-scram-01.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 24, 2009 Isode Ltd Expires: November 27, 2009 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
May 23, 2009 May 26, 2009
Salted Challenge Response (SCRAM) SASL Mechanism Salted Challenge Response (SCRAM) SASL Mechanism
draft-ietf-sasl-scram-00.txt draft-ietf-sasl-scram-01.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 24, 2009. This Internet-Draft will expire on November 27, 2009.
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 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 text protocol where the client and server exchange SCRAM is a text protocol where the client and server exchange
messages containing one or more attribute-value pairs separated by messages containing one or more attribute-value pairs separated by
commas. Each attribute has a one-letter name. The messages and commas. Each attribute has a one-letter name. The messages and
their attributes are described in Section 5.1, and defined in their attributes are described in Section 5.1, and defined in
Section 7. 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:
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=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 C: c=biwK,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
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,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=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 C: c=cCx0bHMtc2VydmVyLWVuZC1wb2ludDrLWEW1c6dn7JKtAzqysWmX/
vu6q+3GuDucFjUF60Sv+A==,r=ClientNonceServerNonce,p=Wx
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
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
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
skipping to change at page 16, line 8 skipping to change at page 16, line 8
this is an indication that there has been a downgrade attack this is an indication that there has been a downgrade attack
(e.g., an attacker changed the server's mechanism list to exclude (e.g., an attacker changed the server's mechanism list to exclude
the -PLUS suffixed SCRAM mechanism name(s)). the -PLUS suffixed SCRAM mechanism name(s)).
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 6.1. Channel Binding to TLS Channels
If an external TLS channel is to be bound into the SCRAM If an external TLS channel is to be bound into the authentication,
authentication, and if the channel was established using a X.509 and if the channel supports channel bindings of type 'tls-server-end-
[RFC5280] server certificate to authenticate the server, then the point', then those MUST be used, else if the channel supports channel
SCRAM client and server MUST use the 'tls-server-end-point' channel bindings of type 'tls-unique' type, then those MUST be used.
binding type. See the IANA Channel Binding Types registry.
If an external TLS channel is to be bound into the SCRAM
authentication, and if the channel was established either without the
use of any X.509 server certificate to authenticate the server, or
with a non X.509 server certificate, then the SCRAM client and server
MUST use the 'tls-unique' channel binding type.
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 28, line 9 skipping to change at page 28, line 9
o The mechanism is extensible, but [hopefully] not overengineered in o The mechanism is extensible, but [hopefully] not overengineered in
this respect. this respect.
o Easier to implement than DIGEST-MD5 in both clients and servers. o Easier to implement than DIGEST-MD5 in both clients and servers.
Appendix C. Internet-Draft Change History Appendix C. Internet-Draft Change History
(RFC Editor: Please delete everything after this point) (RFC Editor: Please delete everything after this point)
Open Issues
o Add proper examples and test vectors
Changes since -10 Changes since -10
o Converted the source for this I-D to XML. o Converted the source for this I-D to XML.
o Added text to make SCRAM compliant with the new GS2 design. o Added text to make SCRAM compliant with the new GS2 design.
o Added text on channel binding negotiation. o Added text on channel binding negotiation.
o Added text on channel binding, including a reference to RFC5056. o Added text on channel binding, including a reference to RFC5056.
 End of changes. 11 change blocks. 
22 lines changed or deleted 20 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/