Skip to main content

Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
RFC 5802

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    sasl mailing list <>, 
    sasl chair <>
Subject: Protocol Action: 'Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism' to Proposed Standard

The IESG has approved the following document:

- 'Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism '
   <draft-ietf-sasl-scram-10.txt> as a Proposed Standard

This document is the product of the Simple Authentication and Security Layer Working Group. 

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

   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.

Working Group Summary

   There were significant and long discussions over several design
   choices, worth mentioning are:

   1) Hash function.  The decision was to define a SASL mechanism
   family to allow for future extension, but not register it as a
   family in the IANA registry.  The decision is to use HMAC-SHA-1 as
   the initial default, and to register SCRAM-SHA-1* the mechanism
   name.  The alternatives considered were HMAC-MD5 and HMAC-SHA-2.
   HMAC-SHA-1 was the compromise proposal.  

   2) Channel binding type negotiation.  After long considerations, it
   was decided to leave channel binding type negotiation external to
   SCRAM and to provide a default of tls-unique.  This simplify the
   design and makes it easy to implement in popular configurations
   (i.e., together with TLS).  

   3) IANA policy.  Two aspects have been considered.  First, whether
   to actually register a SASL mechanism family or just define a
   family and register the two family members as separate mechanism
   names.  The conclusion has been to register a family.  Secondly,
   the registration policy has been discussed.  

Document Quality

   There are several early experimental implementations and more
   implementers are interested.


   The document shepherd is Simon Josefsson, and the responsible
   area director is Pasi Eronen.

RFC Editor Note