idnits 2.17.00 (12 Aug 2021) /tmp/idnits19237/draft-melnikov-scram-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5802, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7677, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (25 October 2021) is 201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6234' is defined on line 179, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 239, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Ltd 4 Updates: 5802, 7677 (if approved) 25 October 2021 5 Intended status: Standards Track 6 Expires: 28 April 2022 8 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS- 9 API Mechanisms 10 draft-melnikov-scram-bis-00 12 Abstract 14 This document updates requirements on implementations of various 15 Salted Challenge Response Authentication Mechanism (SCRAM) Simple 16 Authentication and Security Layer (SASL) mechanisms based on more 17 modern security practices. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 28 April 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Key Word Definitions . . . . . . . . . . . . . . . . . . . . 2 54 3. Implementation Recommendations . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 6.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 The intent of this document is to serve as an implementor's roadmap 66 for implementing various Salted Challenge Response Authentication 67 Mechanism (SCRAM) [RFC5802] SASL [RFC4422] mechanisms. 69 [RFC5802] defined the generic SCRAM framework and described 70 instantiation of a SCRAM mechanism using SHA-1 hash function: SCRAM- 71 SHA-1 (and SCRAM-SHA-1-PLUS). [RFC7677] described another 72 instantiation using SHA-256 hash function (SCRAM-SHA-256 and SCRAM- 73 SHA-256-PLUS) and also clarified conditions for using the mandatory- 74 to-implement "tls-unique" channel binding with TLS 1.2. 75 [tls-1.3-channel-binding] defines the "tls-exporter" channel binding 76 that is to be used when a SCRAM mechanism is used over TLS 1.3 77 [RFC8446] or later. 79 [I-D.melnikov-scram-sha-512] and [I-D.melnikov-scram-sha3-512] define 80 further instantiations of SCRAM using SHA-512 and SHA3-512 hash 81 functions respectively. 83 [I-D.melnikov-scram-2fa] defines an extension to SCRAM for two factor 84 authentication. It is applicable to all instantiations of SCRAM. 86 2. Key Word Definitions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 3. Implementation Recommendations 95 [[Might need to rephrase this, depending on what the final version of 96 "tls-1.3-channel-binding" says.]] This document updates [RFC5802] and 97 [RFC7677] to use the "tls-exporter" channel binding 98 [tls-1.3-channel-binding] as the mandatory to implement (instead of 99 "tls-unique") when a SCRAM mechanism is used over TLS 1.3 [RFC8446] 100 or later. 102 [[Discuss if rough consensus can be reached on this in the KITTEN 103 WG.]] All SCRAM implementations SHOULD support 104 [I-D.melnikov-scram-2fa] to allow for two factor authentication with 105 SCRAM. 107 [[Possibly narrow down choices to only one of these. Discuss in the 108 KITTEN WG.]] Unless required for backward compatibility, server and 109 client implementations MUST support SCRAM-SHA-512-PLUS/SCRAM-SHA-512 110 [I-D.melnikov-scram-sha-512] and/or SCRAM-SHA3-512-PLUS/SCRAM- 111 SHA3-512 [I-D.melnikov-scram-sha3-512] instead of SCRAM-SHA-1-PLUS/ 112 SCRAM-SHA-1 [RFC5802]. 114 4. Security Considerations 116 The security considerations from [RFC5802] still apply. 118 To be secure, SCRAM-*-PLUS MUST be used over a TLS channel that has 119 had the session hash extension [RFC7627] negotiated, or session 120 resumption MUST NOT have been used. When using SCRAM over TLS 1.2 121 [RFC5246], the "tls-unique" channel binding is still the default 122 channel binding to use (see Section 6.1 of [RFC5802]), assuming the 123 above conditions are satisfied. As "tls-unique" channel binding is 124 not defined for TLS 1.3 [RFC8446], when using SCRAM over TLS 1.3, the 125 "tls-exporter" channel binding [tls-1.3-channel-binding] MUST be the 126 default channel binding (in the sense specified in Section 6.1 of 127 [RFC5802]) to use. 129 See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a 130 strong security mechanism like SHA-512. 132 The strength of this mechanism is dependent in part on the hash 133 iteration-count, as denoted by "i" in [RFC5802]. As a rule of thumb, 134 the hash iteration-count should be such that a modern machine will 135 take 0.1 seconds to perform the complete algorithm; however, this is 136 unlikely to be practical on mobile devices and other relatively low- 137 performance systems. At the time this was written, the rule of thumb 138 gives around 15,000 iterations required; however, a hash iteration- 139 count of 10000 takes around 0.5 seconds on current mobile handsets. 140 This computational cost can be avoided by caching the ClientKey 141 (assuming the Salt and hash iteration-count is stable). Therefore, 142 the recommendation of this specification is that the hash iteration- 143 count SHOULD be at least 10000, but careful consideration ought to be 144 given to using a significantly higher value, particularly where 145 mobile use is less important. 147 5. IANA Considerations 149 IANA is requested to add RFC XXXX as an extra reference for the 150 following SASL SCRAM mechanisms listed in the "SASL SCRAM Family 151 Mechanisms" registry: SCRAM-SHA-1, SCRAM-SHA-1-PLUS, SCRAM-SHA-256 152 and SCRAM-SHA-256-PLUS. 154 6. References 156 6.1. Normative References 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, 160 DOI 10.17487/RFC2119, March 1997, 161 . 163 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 164 Authentication and Security Layer (SASL)", RFC 4422, 165 DOI 10.17487/RFC4422, June 2006, 166 . 168 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 169 (TLS) Protocol Version 1.2", RFC 5246, 170 DOI 10.17487/RFC5246, August 2008, 171 . 173 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 174 "Salted Challenge Response Authentication Mechanism 175 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 176 DOI 10.17487/RFC5802, July 2010, 177 . 179 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 180 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 181 DOI 10.17487/RFC6234, May 2011, 182 . 184 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 185 Langley, A., and M. Ray, "Transport Layer Security (TLS) 186 Session Hash and Extended Master Secret Extension", 187 RFC 7627, DOI 10.17487/RFC7627, September 2015, 188 . 190 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 191 Authentication and Security Layer (SASL) Mechanisms", 192 RFC 7677, DOI 10.17487/RFC7677, November 2015, 193 . 195 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 196 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 197 May 2017, . 199 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 200 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 201 . 203 [tls-1.3-channel-binding] 204 Whited, S., "Channel Bindings for TLS 1.3", Work in 205 Progress, Internet-Draft, draft-ietf-kitten-tls-channel- 206 bindings-for-tls13-11, 18 October 2021, 207 . 210 [I-D.melnikov-scram-2fa] 211 Melnikov, A., "Extensions to Salted Challenge Response 212 (SCRAM) for 2 factor authentication", Work in Progress, 213 Internet-Draft, draft-melnikov-scram-2fa-03, 24 May 2021, 214 . 217 [I-D.melnikov-scram-sha-512] 218 Melnikov, A., "SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple 219 Authentication and Security Layer (SASL) Mechanisms", Work 220 in Progress, Internet-Draft, draft-melnikov-scram-sha- 221 512-02, 19 October 2021, . 224 [I-D.melnikov-scram-sha3-512] 225 Melnikov, A., "SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS 226 Simple Authentication and Security Layer (SASL) 227 Mechanisms", Work in Progress, Internet-Draft, draft- 228 melnikov-scram-sha3-512-02, 19 October 2021, 229 . 232 6.2. Informative References 234 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 235 Hashes in Internet Protocols", RFC 4270, 236 DOI 10.17487/RFC4270, November 2005, 237 . 239 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 240 IANA Considerations Section in RFCs", RFC 5226, 241 DOI 10.17487/RFC5226, May 2008, 242 . 244 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 245 Considerations for the SHA-0 and SHA-1 Message-Digest 246 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 247 . 249 Acknowledgements 251 This document is based on RFC 7677 by Tony Hansen. 253 Thank you to Ludovic Bocquet for comments and corrections. 255 Author's Address 257 Alexey Melnikov (editor) 258 Isode Ltd 259 14 Castle Mews 260 Hampton 261 TW12 2NP 262 United Kingdom 264 Email: alexey.melnikov@isode.com