RFC 7677

SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms

📅 published November 2015, from ietf

RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS 🎀

Simple Authentication and Security Layer (SASL) Mechanisms

Part 1 of 2 🦋

Okay bestie, this is RFC 7677 💖, written by T. Hansen from AT&T Laboratories 🌸. It's a Standards Track doc from the IETF (Internet Engineering Task Force), dated November 2015, with ISSN 2070-1721. It doesn't obsolete anything, but it does update RFC 5802, so it's giving glow-up for that one 💅✨.

Abstract 🌈

This doc registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS 🔐. It also gives tips for implementing the original SCRAM-SHA-1-PLUS mechanism securely, and it updates the SCRAM registration procedures from RFC 5802 📝.

Status of This Memo 📜

This is an Internet Standards Track document, no cap 🧚.

It's a product of the IETF, which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more about Internet Standards, check out Section 2 of RFC 5741 🔍.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7677 💌.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🌷.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Key Word Definitions  . . . . . . . . . . . . . . . . . . . .   2
3.  SCRAM-SHA-256 and SCRAM-SHA-256-PLUS  . . . . . . . . . . . .   2
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
  5.1.  Updates to SCRAM-* Registration . . . . . . . . . . . . .   4
  5.2.  SASL-SCRAM Family Mechanisms Registration Procedure . . .   4
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction ✨

Okay so this doc registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS 🎀. SHA-256 has way stronger security properties than SHA-1, and SCRAM mechanisms built on it are expected to have much greater predicted longevity than the ones built on SHA-1. Iconic 👑.

The registration form for the SCRAM family of algorithms also gets updated from [RFC5802] 📝.

After [RFC5802] was published, people discovered that Transport Layer Security (TLS) [RFC5246] doesn't have the properties that the "tls-unique" channel binding needs in order to be secure [RFC7627]. 😭 So this doc has normative text that covers both the original SCRAM-SHA-1-PLUS and the brand new SCRAM-SHA-256-PLUS mechanism 🔥.

2. Key Word Definitions 🔑

The key words in this doc are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They mean what [RFC2119] says they mean 💅.

3. SCRAM-SHA-256 and SCRAM-SHA-256-PLUS 🦋

SCRAM-SHA-256 and SCRAM-SHA-256-PLUS are set up the same way that SCRAM-SHA-1 and SCRAM-SHA-1-PLUS are in [RFC5802]. The only difference is that the hash function for HMAC() and H() is SHA-256 instead of SHA-1 [RFC6234] 🌈.

For SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, the hash iteration-count a server announces SHOULD be at least 4096 ⭐.

The GSS-API mechanism OID for SCRAM-SHA-256 is 1.3.6.1.5.5.18 (see Section 5) 🧚.

Here's a simple SCRAM-SHA-256 auth exchange where the client doesn't support channel bindings 🫶. The username user and the password pencil are being used:

C: n,,n=user,r=rOprNGfwEbeRWgbNEkqO

S: r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
   s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096

C: c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,
   p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=

S: v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=

4. Security Considerations 💀

The security considerations from [RFC5802] still apply, so stay alert bestie 😭.

Not a vibe, a rule: either SCRAM-SHA-256-PLUS and SCRAM-SHA-1-PLUS MUST be used over a TLS channel that has had the session hash extension [RFC7627] negotiated, or session resumption MUST NOT have been used 🚨.

If you want the reasons to move from SHA-1 to a strong mechanism like SHA-256, check out [RFC4270] and [RFC6194] 🔍.

The strength of this mechanism depends partly on the hash iteration-count, which is denoted by "i" in [RFC5802] 🧮. As a rule of thumb, the hash iteration-count should be such that a modern machine will take 0.1 seconds to perform the complete algorithm. However, that's unlikely to be practical on mobile devices and other relatively low-performance systems 📱. When this was written, the rule of thumb gave around 15,000 iterations required. Still, a hash iteration-count of 4096 takes around 0.5 seconds on current mobile handsets ⏱️. This computational cost can be avoided by caching the ClientKey, assuming the Salt and hash iteration-count stay stable 🧠. So the recommendation of this specification is that the hash iteration-count SHOULD be at least 4096, but careful consideration ought to be given to using a significantly higher value, particularly where mobile use is less important 🍓.

6.1. Normative References

okay so these are the must-read docs, bestie 📚✨ here's the full reference list, every detail intact:

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
           Authentication and Security Layer (SASL)", RFC 4422,
           DOI 10.17487/RFC4422, June 2006,
           <http://www.rfc-editor.org/info/rfc4422>.

[RFC5802]  Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
           "Salted Challenge Response Authentication Mechanism
           (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
           DOI 10.17487/RFC5802, July 2010,
           <http://www.rfc-editor.org/info/rfc5802>.

[RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
           (SHA and SHA-based HMAC and HKDF)", RFC 6234,
           DOI 10.17487/RFC6234, May 2011,
           <http://www.rfc-editor.org/info/rfc6234>.

[RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
           Langley, A., and M. Ray, "Transport Layer Security (TLS)
           Session Hash and Extended Master Secret Extension",
           RFC 7627, DOI 10.17487/RFC7627, September 2015,
           <http://www.rfc-editor.org/info/rfc7627>.

6.2. Informative References

these ones are the background reading 🧠💅 useful, not required:

[RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
           Hashes in Internet Protocols", RFC 4270,
           DOI 10.17487/RFC4270, November 2005,
           <http://www.rfc-editor.org/info/rfc4270>.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           DOI 10.17487/RFC5226, May 2008,
           <http://www.rfc-editor.org/info/rfc5226>.

[RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
           Considerations for the SHA-0 and SHA-1 Message-Digest
           Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
           <http://www.rfc-editor.org/info/rfc6194>.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246,
           DOI 10.17487/RFC5246, August 2008,
           <http://www.rfc-editor.org/info/rfc5246>.

Acknowledgements 🫶

this doc was helped along by discussions on the KITTEN WG mailing list 💖 the author wants to give a special shoutout to Russ Allbery, Dave Cridland, Shawn Emery, Stephen Farrell, Simon Josefsson, Pearl Liang, Alexey Melnikov, Peter Saint-Andre, Robert Sparks, Martin Thompson, and Nico Williams for their comments on this topic. literally the dream team 👑

Author's Address 🎀

Tony Hansen
AT&T Laboratories
200 Laurel Ave. South
Middletown, NJ  07748
United States

Email: tony+scramsha256@maillennium.att.com

and that's the whole spec, bestie 🦋 every requirement, every example, every reference, served with a side of slay ✨

📦 where this page comes from