draft-ietf-sasl-scram-10.txt   draft-ietf-sasl-scram-11.txt 
NETWORK WORKING GROUP A. Menon-Sen NETWORK WORKING GROUP C. Newman
Internet-Draft Oryx Mail Systems GmbH Internet-Draft Sun Microsystems
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Menon-Sen
Expires: April 16, 2010 Isode Ltd Expires: August 12, 2010 Oryx Mail Systems GmbH
C. Newman A. Melnikov
Isode Ltd
N. Williams N. Williams
Sun Microsystems Sun Microsystems
October 13, 2009 February 8, 2010
Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism
draft-ietf-sasl-scram-10.txt draft-ietf-sasl-scram-11.txt
Abstract
The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use.
This specification describes a family of Simple Authentication and
Security Layer (SASL, RFC 4422) authentication mechanisms called the
Salted Challenge Response Authentication Mechanism (SCRAM), which
addresses the security concerns and meets the deployability
requirements. When used in combination with TLS or an equivalent
security layer, a mechanism from this family could improve the
status-quo for application protocol authentication and provide a
suitable choice for a mandatory-to-implement mechanism for future
application protocol standards.
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 2, line 13
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 16, 2010. This Internet-Draft will expire on August 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The secure authentication mechanism most widely deployed and used by described in the BSD License.
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use.
This specification describes a family of Simple Authentication and
Security Layer (SASL, RFC 4422) authentication mechanisms called the
Salted Challenge Response Authentication Mechanism (SCRAM), which
addresses the security concerns and meets the deployability
requirements. When used in combination with TLS or an equivalent
security layer, a mechanism from this family could improve the
status-quo for application protocol authentication and provide a
suitable choice for a mandatory-to-implement mechanism for future
application protocol standards.
Table of Contents Table of Contents
1. Conventions Used in This Document . . . . . . . . . . 4 1. Conventions Used in This Document . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
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
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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, i): o Hi(str, salt, i):
U0 := HMAC(str, salt + INT(1)) U1 := HMAC(str, salt + INT(1))
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 := U1 XOR U2 XOR ... XOR Ui
where "i" is the iteration count, "+" is the string concatenation where "i" is the iteration count, "+" is the string concatenation
operator and INT(g) is a four-octet encoding of the integer g, operator and INT(g) is a four-octet encoding of the integer g,
most significant octet first. most significant octet first.
Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
with dkLen == output length of HMAC() == output length of H(). with dkLen == output length of HMAC() == output length of H().
2. Introduction 2. Introduction
skipping to change at page 37, line 7 skipping to change at page 37, line 7
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[tls-server-end-point] [tls-server-end-point]
Zhu, L., "Registration of TLS server end-point channel Zhu, L., "Registration of TLS server end-point channel
bindings", IANA http://www.iana.org/assignments/ bindings", IANA http://www.iana.org/assignments/
channel-binding-types/tls-server-end-point, July 2008. channel-binding-types/tls-server-end-point, July 2008.
Authors' Addresses Authors' Addresses
Chris Newman
Sun Microsystems
1050 Lakes Drive
West Covina, CA 91790
USA
Email: chris.newman@sun.com
Abhijit Menon-Sen Abhijit Menon-Sen
Oryx Mail Systems GmbH Oryx Mail Systems GmbH
Email: ams@oryx.com Email: ams@toroid.org
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
Chris Newman
Sun Microsystems
1050 Lakes Drive
West Covina, CA 91790
USA
Email: chris.newman@sun.com
Nicolas Williams Nicolas Williams
Sun Microsystems Sun Microsystems
5300 Riata Trace Ct 5300 Riata Trace Ct
Austin, TX 78727 Austin, TX 78727
USA USA
Email: Nicolas.Williams@sun.com Email: Nicolas.Williams@sun.com
 End of changes. 11 change blocks. 
47 lines changed or deleted 51 lines changed or added

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