SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
updated by
- rfc-9266 — Channel Bindings for TLS 1.3
updates
- rfc-5802 — Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
Extracted elements (15)
A minimum iteration-count of 4096 is chosen as a practical floor because, while roughly 15,000 iterations are recommended for desktop performance targets, 4096 takes around 0.5 seconds on current mobile handsets, making higher values impractical for mobile use cases.
After publication of RFC 5802, it was discovered that TLS does not have the expected properties for 'tls-unique' channel binding to be secure without the session hash extension (RFC 7627); this motivated the normative text in this document requiring RFC 7627 or prohibition of session resumption when using '-PLUS' variants.
SHA-256 has stronger security properties than SHA-1, and SCRAM mechanisms based on it are expected to have greater predicted longevity than those based on SHA-1, motivating the introduction of SCRAM-SHA-256.
SCRAM-SHA-256 and SCRAM-SHA-256-PLUS follow the same message flow and field structure as SCRAM-SHA-1/SCRAM-SHA-1-PLUS (RFC 5802); implementations differ only in the substitution of SHA-256 for SHA-1 in HMAC() and H().
At publication of a new SASL SCRAM Family Mechanism, IANA SHOULD assign a GSS-API mechanism OID from the iso.org.dod.internet.security.mechanisms prefix; only one OID needs to be assigned for a SCRAM-<NAME> and SCRAM-<NAME>-PLUS pair.
Each new SASL SCRAM mechanism MUST be explicitly registered with IANA within the SASL SCRAM Family Mechanisms registry and MUST comply with the SCRAM-mechanism naming convention defined in Section 4 of RFC 5802.
For SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, the hash iteration-count announced by a server SHOULD be at least 4096.
Members of the SCRAM family MUST be explicitly registered using the 'IETF Review' registration procedure, with reviews requested on the KITTEN mailing list.
SCRAM-SHA-256 and SCRAM-SHA-256-PLUS are defined identically to SCRAM-SHA-1 and SCRAM-SHA-1-PLUS from RFC 5802, except that HMAC() and H() use SHA-256 instead of SHA-1.
To be secure, either SCRAM-SHA-256-PLUS or SCRAM-SHA-1-PLUS MUST be used over a TLS channel that has had the session hash extension (RFC 7627) negotiated, or session resumption MUST NOT have been used.
The GSS-API mechanism OID for SCRAM-SHA-256 (and SCRAM-SHA-256-PLUS) is 1.3.6.1.5.5.18, assigned from the SMI Security for Mechanism Codes registry.
A new IANA registry 'SASL SCRAM Family Mechanisms' is created, extending the existing SASL mechanism registry with two new fields: Minimum iteration-count and Associated OID. Existing SCRAM-SHA-1 and SCRAM-SHA-1-PLUS entries are migrated into it with Minimum iteration-count 4096 and OID 1.3.6.1.5.5.14.
SCRAM-SHA-256 is registered in the 'SASL SCRAM Family Mechanisms' registry with minimum iteration-count 4096 and OID 1.3.6.1.5.5.18; SCRAM-SHA-256-PLUS is registered with the same minimum iteration-count and OID.
The '-PLUS' variants (SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS) MUST only be used over a TLS channel with the RFC 7627 session hash extension negotiated, or where session resumption has not been used, because TLS without that extension does not provide the security properties required for 'tls-unique' channel binding.
The strength of SCRAM is partly dependent on the hash iteration-count; as a rule of thumb it should be set so a modern machine takes 0.1 seconds for the complete algorithm (approximately 15,000 iterations at time of writing), though 4096 is a practical floor for mobile devices. Caching ClientKey can amortize the cost when salt and iteration-count are stable.