idnits 2.17.1 draft-hansen-scram-sha256-03.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC5802, but the abstract doesn't seem to directly say this. It does mention RFC5802 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2015) is 3200 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) -- Looks like a reference, but probably isn't: '1' on line 313 -- Looks like a reference, but probably isn't: '2' on line 315 ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kitten T. Hansen 3 Internet-Draft AT&T Laboratories 4 Updates: 5802 (if approved) July 20, 2015 5 Intended status: Standards Track 6 Expires: January 21, 2016 8 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms 9 draft-hansen-scram-sha256-03 11 Abstract 13 This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- 14 SHA-256-PLUS. It also updates the SCRAM registration procedures of 15 RFC 5802. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 21, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Key Word Definitions . . . . . . . . . . . . . . . . . . . . 2 53 3. SCRAM-SHA-256 and SCRAM-SHA-256-PLUS . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. Updates to SCRAM-* Registration . . . . . . . . . . . . . 4 57 5.2. SASL-SCRAM Family Mechanisms Registration Procedure . . . 4 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . 7 62 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 64 A.1. Changes for -02 to -03 . . . . . . . . . . . . . . . . . 7 65 A.2. Changes for -01 to -02 . . . . . . . . . . . . . . . . . 8 66 A.3. Changes for -00 to -01 . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- 72 SHA-256-PLUS. SHA-256 has stronger security properties than SHA-1, 73 and it is expected that SCRAM mechanisms based on it will have 74 greater predicted longevity than the SCRAM mechanisms based on SHA-1. 76 The registration form for the SCRAM family of algorithms is also 77 updated from [RFC5802]. 79 Note: this paragraph may be removed before publication. 80 This document was written because [RFC5802] requires that new SASL 81 mechanisms in the SCRAM family be subject to IETF review. This 82 document is being discussed in the KITTEN working group (see the 83 kitten@ietf.org [1] mailing list). It was pursued further because of 84 a desire for its use within a document being discussed in the HTTP- 85 AUTH working group (see the httpauth@ietf.org [2] mailing list). 87 2. Key Word Definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. SCRAM-SHA-256 and SCRAM-SHA-256-PLUS 95 The SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms are defined 96 in the same way that SCRAM-SHA-1 and SCRAM-SHA-1-PLUS are defined in 97 [RFC5802], except that the hash function for HMAC() and H() uses 98 SHA-256 instead of SHA-1 [RFC6234]. 100 For the SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms, the 101 hash iteration-count announced by a server SHOULD be at least 4096. 103 The GSS-API mechanism OID for SCRAM-SHA-256 is TBD1 (see Section 5). 105 This is a simple example of a SCRAM-SHA-256 authentication exchange 106 when the client doesn't support channel bindings. The username 107 'user' and password 'pencil' are being used. 109 C: n,,n=user,r=rOprNGfwEbeRWgbNEkqO 111 S: r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0, 112 s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096 114 C: c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0, 115 p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ= 117 S: v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4= 119 4. Security Considerations 121 The security considerations from [RFC5802] still apply. 123 See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a 124 strong security mechanism like SHA-256. 126 The strength of this mechanism is dependent in part on the hash- 127 iteration count, as denoted by "i" in [RFC5802]. As a rule of thumb, 128 the hash-iteration count should be such that a modern machine will 129 take 0.1 seconds to perform the complete algorithm; however this is 130 unlikely to be practical on mobile devices and other relatively low- 131 performance systems. At the time this was written, the rule of thumb 132 gives around 15,000 iterations required; however an iteration count 133 of 4096 takes around 0.5 seconds on current mobile handsets. This 134 computational cost can be avoided by caching the ClientKey (assuming 135 the Salt and iteration count is stable). Therefore the 136 recommendation of this specification is that the iteration count 137 SHOULD be at least 4096, but careful consideration ought to be given 138 to using a significantly higher value, particularly where mobile use 139 is less important. 141 5. IANA Considerations 143 5.1. Updates to SCRAM-* Registration 145 The IANA registry for SCRAM-* (the SCRAM family of SASL mechanisms) 146 in the SASL Mechanism registry ([RFC4422]) is updated as follows. 147 The email address for reviews has been updated, and the note at the 148 end changed. 150 To: iana@iana.org 151 Subject: Registration of a new SASL family SCRAM 153 SASL mechanism name (or prefix for the family): SCRAM-* 154 Security considerations: Section 7 of [RFC5802] 155 Published specification (optional, recommended): RFCXXXX 156 Person & email address to contact for further information: IETF 157 KITTEN WG kitten@ietf.org 158 Intended usage: COMMON 159 Owner/Change controller: IESG iesg@ietf.org 160 Note: Members of this family MUST be explicitly registered using 161 the "IETF Review" [RFC5226] registration procedure. Reviews MUST 162 be requested on the KITTEN mailing list kitten@ietf.org (or a 163 successor designated by the responsible Security AD). 165 Note to future SCRAM-mechanism designers: each new SASL SCRAM 166 mechanism MUST be explicitly registered with IANA within the SASL 167 SCRAM Family Mechanisms registry. 169 5.2. SASL-SCRAM Family Mechanisms Registration Procedure 171 A new IANA registry is to be added for members of the SCRAM family of 172 SASL mechanisms, named SASL SCRAM Family Mechanisms. It adds two new 173 fields to the existing SCRAM mechanism registry: Minimum iteration- 174 count and Associated OID. 176 To: iana@iana.org 177 Subject: Registration of a new SASL SCRAM family mechanism 179 SASL mechanism name (or prefix for the family): SCRAM- 180 Security considerations: Section 7 of [RFC5802] 181 Published specification (optional, recommended): RFCXXXX 182 Minimum iteration-count: The minimum iteration-count that servers 183 SHOULD announce 184 Associated OID: TBD-BY-IANA 185 Person & email address to contact for further information: IETF 186 KITTEN WG kitten@ietf.org 187 Intended usage: COMMON 188 Owner/Change controller: IESG iesg@ietf.org 189 Note: Members of this family MUST be explicitly registered using 190 the "IETF Review" [RFC5226] registration procedure. Reviews MUST 191 be requested on the KITTEN mailing list kitten@ietf.org (or a 192 successor designated by the responsible Security Area Director). 194 Note: At publication of a new SASL SCRAM Family Mechanism, IANA 195 SHOULD assign a GSS-API mechanism OID for this mechanism from the 196 iso.org.dod.internet.security.mechanisms prefix (see the "SMI 197 Security for Mechanism Codes" registry) and fill in the value for 198 "TBD-BY-IANA" above. Only one OID needs to be assigned for a 199 SCRAM- and SCRAM--PLUS pair. The same OID should be 200 assigned to both entries in the registry. 202 [RFC Editor: This note should be removed before publication.] 203 Note to IANA and the RFC Editor: The above string "TBD-BY-IANA" is 204 NOT to be filled in with an OID within THIS document, but is to be 205 placed as is within the registry. 207 Note to future SASL SCRAM mechanism designers: each new SASL SCRAM 208 mechanism MUST be explicitly registered with IANA and MUST comply 209 with the SCRAM-mechanism naming convention defined in Section 4 of 210 [RFC5802]. 212 The existing entries for SASL SCRAM-SHA-1 and SCRAM-SHA-1-PLUS are to 213 be moved from the existing SASL Mechanism registry to the SASL SCRAM 214 Family Mechanism registry. When doing so, the following values are 215 to be added: 217 Minimum iteration-count: 4096 218 OID: 1.3.6.1.5.5.14 (from [RFC5802]) 220 The following new SASL SCRAM mechanisms are added to the SASL SCRAM 221 Family Mechanism registry: 223 IANA has added the following entries to the SASL SCRAM Family 224 Mechanism registry established by RFCXXXX: 226 To: iana@iana.org 227 Subject: Registration of a new SASL SCRAM Family mechanism SCRAM- 228 SHA-256 230 SASL mechanism name (or prefix for the family): SCRAM-SHA-256 231 Security considerations: Section Section 4 of RFCXXXX 232 Published specification (optional, recommended): RFCXXXX 233 Minimum iteration-count: 4096 234 OID: TBD1 235 Person & email address to contact for further information: IETF 236 KITTEN WG kitten@ietf.org 237 Intended usage: COMMON 238 Owner/Change controller: IESG iesg@ietf.org 239 Note: 241 To: iana@iana.org 242 Subject: Registration of a new SASL SCRAM Family mechanism SCRAM- 243 SHA-256-PLUS 245 SASL mechanism name (or prefix for the family): SCRAM-SHA-256-PLUS 246 Security considerations: Section Section 4 of RFCXXXX 247 Published specification (optional, recommended): RFCXXXX 248 Minimum iteration-count: 4096 249 OID: "TBD1" 250 Person & email address to contact for further information: IETF 251 KITTEN WG kitten@ietf.org 252 Intended usage: COMMON 253 Owner/Change controller: IESG iesg@ietf.org 254 Note: 256 [This note may be removed on publication.] IANA needs to assign the 257 GSS-API mechanism OID TBD1 listed above from the 258 iso.org.dod.internet.security.mechanisms prefix (see the "SMI 259 Security for Mechanism Codes" registry). 261 6. Acknowledgements 263 This document benefited from discussions on the KITTEN WG mailing 264 list. The author would like to specially thank Russ Albery, Dave 265 Cridland, Shawn Emery, Simon Josefsson, Pearl Liang, Alexey Melnikov, 266 Peter Saint-Andre, Martin Thompson and Nico Williams for their 267 comments on this topic. 269 7. References 271 7.1. Normative References 273 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 274 Authentication and Security Layer (SASL)", RFC 4422, 275 DOI 10.17487/RFC4422, June 2006, 276 . 278 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 279 "Salted Challenge Response Authentication Mechanism 280 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 281 DOI 10.17487/RFC5802, July 2010, 282 . 284 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 285 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 286 DOI 10.17487/RFC6234, May 2011, 287 . 289 7.2. Informative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 297 Hashes in Internet Protocols", RFC 4270, 298 DOI 10.17487/RFC4270, November 2005, 299 . 301 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 302 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 303 DOI 10.17487/RFC5226, May 2008, 304 . 306 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 307 Considerations for the SHA-0 and SHA-1 Message-Digest 308 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 309 . 311 7.3. URIs 313 [1] mailto:kitten@ietf.org 315 [2] mailto:httpauth@ietf.org 317 Appendix A. Change Log 319 This section should be removed before publication as an RFC. 321 A.1. Changes for -02 to -03 323 Changed from Informational document to Standards Track. 325 Beefed up the Security Considerations (Section 4) section. 327 At the request of IANA, reworked the IANA Considerations (Section 5) 328 section. 330 A.2. Changes for -01 to -02 332 Removed !!!!!!!!!!!!!!!! comments requesting discussion after 333 discussion on kitten mailing list. 335 A.3. Changes for -00 to -01 337 Added Security Considerations (Section 4) section. 339 Added Minimum iteration-count and associated OID fields to 340 registration forms and reworked the IANA Considerations (Section 5) 341 section. 343 Author's Address 345 Tony Hansen 346 AT&T Laboratories 347 200 Laurel Ave. South 348 Middletown, NJ 07748 349 USA 351 Email: tony+scramsha256@maillennium.att.com