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.
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.