draft-ietf-sasl-scram-08.txt   draft-ietf-sasl-scram-09.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 5, 2010 Isode Ltd Expires: April 10, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
October 2, 2009 October 7, 2009
Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism
draft-ietf-sasl-scram-08.txt draft-ietf-sasl-scram-09.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 5, 2010. This Internet-Draft will expire on April 10, 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 5, line 30 skipping to change at page 5, line 30
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 a Unicode normalization algorithm to a UTF-8
[RFC3629] encoded "str". The resulting string is also in UTF-8. [RFC3629] encoded "str". The resulting string is also in UTF-8.
Implementations SHOULD use the SASLPrep profile [RFC4013] of the Implementations SHOULD use the SASLPrep profile [RFC4013] of the
"stringprep" algorithm [RFC3454] as the normalization algorithm. "stringprep" algorithm [RFC3454] as the normalization algorithm.
When applying SASLPrep, "str" is treated as a "stored strings",
which means that unassigned Unicode codepoints are prohibited (see
Section 7 of [RFC3454]).
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
use. use.
o XOR: Apply the exclusive-or operation to combine the octet string o XOR: Apply the exclusive-or operation to combine the octet string
on the left of this operator with the octet string on the right of on the left of this operator with the octet string on the right of
this operator. The length of the output and each of the two this operator. The length of the output and each of the two
inputs will be the same for this use. inputs will be the same for this use.
o Hi(str, salt): o Hi(str, salt, i):
U0 := HMAC(str, salt + INT(1)) U0 := HMAC(str, salt + INT(1))
U1 := HMAC(str, U0) U1 := HMAC(str, U0)
U2 := HMAC(str, U1) U2 := HMAC(str, U1)
... ...
Ui-1 := HMAC(str, Ui-2) Ui-1 := HMAC(str, Ui-2)
Ui := HMAC(str, Ui-1) Ui := HMAC(str, Ui-1)
Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
skipping to change at page 9, line 37 skipping to change at page 9, line 37
(*) - 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 characters. In
particular, it's useful to test characters whose "Unicode particular, it's useful to test characters 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 characters 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) 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
ServerKey := HMAC(SaltedPassword, "Server Key") ServerKey := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage) ServerSignature := HMAC(ServerKey, AuthMessage)
skipping to change at page 24, line 23 skipping to change at page 24, line 23
the password and the iteration count supplied by the server. An the password and the iteration count supplied by the server. An
external security layer with strong encryption will prevent this external security layer with strong encryption will prevent this
attack. attack.
If the external security layer used to protect the SCRAM exchange If the external security layer used to protect the SCRAM exchange
uses an anonymous key exchange, then the SCRAM channel binding uses an anonymous key exchange, then the SCRAM channel binding
mechanism can be used to detect a man-in-the-middle attack on the mechanism can be used to detect a man-in-the-middle attack on the
security layer and cause the authentication to fail as a result. security layer and cause the authentication to fail as a result.
However, the man-in-the-middle attacker will have gained sufficient However, the man-in-the-middle attacker will have gained sufficient
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 allows to increase the iteration count over
count over time. time. (Note that a server that is only in posession of "StoredKey"
and "ServerKey" can't automatic increase the iteration count upon
successful authentication. Such increase would require resetting
user's password.)
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. The WG selected not to use EKE like an example of such technology. The WG selected not to use EKE like
mechanisms as basis for SCRAM. mechanisms as basis for SCRAM.
skipping to change at page 28, line 9 skipping to change at page 28, line 9
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-SHA-1 from the iso.org.dod.internet.security.mechanisms for SCRAM-SHA-1 from the iso.org.dod.internet.security.mechanisms
prefix (see "SMI Security for Mechanism Codes" registry). 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, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen and Peter Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen, Ben
Saint-Andrefor their contributions to this document. Campbell and Peter Saint-Andre 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 46 skipping to change at page 31, line 46
registrations of all other SCRAM- mechanisms. registrations of all other SCRAM- mechanisms.
Changes since -06 Changes since -06
o Removed hash negotiation from SCRAM and turned it into a family of o Removed hash negotiation from SCRAM and turned it into a family of
SASL mechanisms. SASL mechanisms.
o Start using "Hash Function Textual Names" IANA registry for SCRAM o Start using "Hash Function Textual Names" IANA registry for SCRAM
mechanism naming. mechanism naming.
o Fixed definition of Hi(str, salt) to be consistent with [RFC2898]. o Fixed definition of Hi(str, salt, i) to be consistent with
[RFC2898].
o Clarified extensibility of SCRAM: added m= attribute (for future o Clarified extensibility of SCRAM: added m= attribute (for future
mandatory extensions) and specified that all unrecognized mandatory extensions) and specified that all unrecognized
attributes must be ignored. attributes must be ignored.
Changes since -05 Changes since -05
o Changed the mandatory to implement hash algorithm to SHA-1 (as per o Changed the mandatory to implement hash algorithm to SHA-1 (as per
WG consensus). WG consensus).
o Added text about use of SASLPrep for username canonicalization/ o Added text about use of SASLPrep for username canonicalization/
validation. validation.
o Clarified that authorization identity is canonicalized/verified o Clarified that authorization identity is canonicalized/verified
according to SASL protocol profile. according to SASL protocol profile.
o Clarified that iteration count is per-user. o Clarified that iteration count is per-user.
skipping to change at page 34, line 30 skipping to change at page 34, 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-06 (work in for TLS", draft-altman-tls-channel-bindings-07 (work in
progress), August 2009. progress), October 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.
 End of changes. 12 change blocks. 
13 lines changed or deleted 22 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/