draft-ietf-sasl-scram-03.txt   draft-ietf-sasl-scram-04.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: January 31, 2010 Isode Ltd Expires: February 1, 2010 Isode Ltd
C. Newman C. Newman
N. Williams N. Williams
Sun Microsystems Sun Microsystems
July 30, 2009 July 31, 2009
Salted Challenge Response (SCRAM) SASL Mechanism Salted Challenge Response (SCRAM) SASL Mechanism
draft-ietf-sasl-scram-03.txt draft-ietf-sasl-scram-04.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 January 31, 2010. This Internet-Draft will expire on February 1, 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).
A separate document defines a standard LDAPv3 [RFC4510] attribute
that enables storage of the SCRAM authentication information in 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 Comments regarding this draft may be sent either to the
ietf-sasl@imc.org mailing list or to the authors. ietf-sasl@imc.org mailing list or to the authors.
3. SCRAM Algorithm Overview 3. SCRAM Algorithm Overview
skipping to change at page 10, line 26 skipping to change at page 10, line 26
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. If the server supports channel
advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the binding, it will advertise both the "bare" and "plus" versions of
server will advertise only SCRAM-SHA-1. The "-PLUS" exists to allow whatever mechanisms it supports (e.g., if the server supports only
SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
and SCRAM-SHA-1-PLUS); if the server does not support channel
binding, then it will advertise only the "bare" version of the
mechanism (e.g., 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 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.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
For more discussions of channel bindings, and the syntax of the For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [RFC5056]. channel binding data for various security protocols, see [RFC5056].
6.1. Default Channel Binding 6.1. Default Channel Binding
A default channel binding type agreement process for all SASL A default channel binding type agreement process for all SASL
application protocols that do not provide their own channel binding application protocols that do not provide their own channel binding
type agreement is provided as follows. type agreement is provided as follows.
Clients and servers MUST implement the "tls-unique" [tls-unique] 'tls-unique' is the default channel binding type for any application
channel binding type. Clients and servers SHOULD choose the highest- that doesn't specify one.
layer/innermost end-to-end TLS channel as the channel to bind to.
Clients SHOULD choose the tls-unique channel binding type. Servers MUST implement the "tls-unique" [tls-unique]
Conversely, clients MAY choose a different channel binding type based [I-D.altman-tls-channel-bindings] channel binding type, if they
on user input, configuration, or a future, as-yet undefined channel implement any channel binding. Clients SHOULD implement the "tls-
binding type negotiation protocol. Servers MUST choose the channel unique" [tls-unique] [I-D.altman-tls-channel-bindings] channel
binding type indicated by the client, if they support it. binding type, if they implement any channel binding. Clients and
servers SHOULD choose the highest- layer/innermost end-to-end TLS
channel as the channel to bind to.
Servers MUST choose the channel binding type indicated by the client,
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)>
skipping to change at page 22, line 30 skipping to change at page 22, line 30
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 includes the ability to increase the iteration
count over time. count over time.
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). available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is
an example of such technology. There are IPR disclosures at
http://datatracker.ietf.org/ipr/ that mention RFC 2945.
If an attacker obtains the authentication information from the If an attacker obtains the authentication information from the
authentication repository and either eavesdrops on one authentication authentication repository and either eavesdrops on one authentication
exchange or impersonates a server, the attacker gains the ability to exchange or impersonates a server, the attacker gains the ability to
impersonate that user to all servers providing SCRAM access using the impersonate that user to all servers providing SCRAM access using the
same hash function, password, iteration count and salt. For this same hash function, password, iteration count and salt. For this
reason, it is important to use randomly-generated salt values. reason, it is important to use randomly-generated salt values.
SCRAM does not negotiate a hash function to use. Hash function SCRAM does not negotiate a hash function to use. Hash function
negotiation is left to the SASL mechanism negotiation. It is negotiation is left to the SASL mechanism negotiation. It is
skipping to change at page 23, line 8 skipping to change at page 23, line 10
preferred over SCRAM with SHA-1). preferred over SCRAM with SHA-1).
Note that to protect the SASL mechanism negotiation applications Note that to protect the SASL mechanism negotiation applications
normally must list the server mechs twice: once before and once after normally must list the server mechs twice: once before and once after
authentication, the latter using security layers. Since SCRAM does authentication, the latter using security layers. Since SCRAM does
not provide security layers the only ways to protect the mechanism not provide security layers the only ways to protect the mechanism
negotiation are: a) use channel binding to an external channel, or b) negotiation are: a) use channel binding to an external channel, or b)
use an external channel that authenticates a user-provided server use an external channel that authenticates a user-provided server
name. name.
SCRAM does not protect against downgrade attacks of channel binding
types. The complexities of negotiation a channel binding type, and
handling down-grade attacks in that negotiation, was intentionally
left out of scope for this document.
A hostile server can perform a computational denial-of-service attack A hostile server can perform a computational denial-of-service attack
on clients by sending a big iteration count value. on clients by sending a big iteration count value.
See [RFC4086] for more information about generating randomness. See [RFC4086] for more information about generating randomness.
10. IANA Considerations 10. IANA Considerations
IANA is requested to add the following family of SASL mechanisms to IANA is requested to add the following family of SASL mechanisms to
the SASL Mechanism registry established by [RFC4422]: the SASL Mechanism registry established by [RFC4422]:
skipping to change at page 32, line 28 skipping to change at page 32, line 28
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] [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]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", draft-altman-tls-channel-bindings-05 (work in
progress), June 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.
[I-D.melnikov-sasl-scram-ldap]
Melnikov, A., "LDAP schema for storing SCRAM secrets",
draft-melnikov-sasl-scram-ldap-02 (work in progress),
July 2009.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, September 2000.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
June 2006. June 2006.
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006. Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
 End of changes. 13 change blocks. 
16 lines changed or deleted 48 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/