idnits 2.17.1 draft-newman-auth-scram-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([HMAC], [CRAM-MD5], [SHA1], [SASL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1997) is 9718 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) == Missing Reference: 'UTF-8' is mentioned on line 90, but not defined == Unused Reference: 'IMAP4' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'UTF8' is defined on line 484, but no explicit reference was found in the text -- No information found for draft-ietf-drums-abnf-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNF' ** Obsolete normative reference: RFC 2095 (ref. 'CRAM-MD5') (Obsoleted by RFC 2195) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) -- Possible downref: Non-RFC (?) normative reference: ref. 'SASL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'SKEY') -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' ** Obsolete normative reference: RFC 2044 (ref. 'UTF8') (Obsoleted by RFC 2279) Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: SCRAM-SHA1 SASL Mechanism Innosoft 4 Document: draft-newman-auth-scram-00.txt September 1997 5 Expires in six months 7 Salted Challenge Response Authentication Mechanism (SCRAM) 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 SCRAM is a simple passphrase-based authentication mechanism which 31 uses only a publicly available cryptographic hash function to 32 provide authentication for protocols. It is designed to replace 33 plaintext password mechanisms without significant additional 34 complexity, loss of performance or plaintext equivalent verifiers. 36 CRAM-MD5 [CRAM-MD5], a similar mechanism, has the drawback that the 37 password verifier stored on the server can be used to impersonate 38 the user. Current plaintext password mechanisms do not have this 39 drawback and it is a serious issue for servers which allow remote 40 login or sites which distribute the authentication database to 41 multiple servers via an insecure protocol. SCRAM-SHA1 corrects 42 this drawback with minimal additional complexity. 44 This document defines the SCRAM-SHA1 SASL mechanism [SASL] using 45 the SHA1 [SHA1] and HMAC-SHA1 [HMAC] algorithms. 47 0. Open Issues 49 (1) Although this mechanism has no new concepts, it has not had 50 extensive review. Advice on the completeness of the security 51 considerations is appreciated. 53 (2) The TWEKE proposal (appendix B) is more secure and more 54 complex. Is it an acceptable or desirable tradeoff? Perhaps SCRAM 55 could get 40% penetration into the plaintext market and TWEKE could 56 get 30%, would it be worthwhile to do TWEKE instead of SCRAM in 57 this case? What if there's a bigger difference? 59 1. Conventions Used in this Document 61 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 62 in this document are to be interpreted as defined in "Key words for 63 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 65 2. Client Implementation of SCRAM-SHA1 67 This section includes a step-by-step guide for client implementors. 68 Although section 7 contains the formal definition of the syntax and 69 is the authoritative reference in case of errors here, this section 70 should be sufficient to build a correct implementation. 72 When used with SASL the mechanism name is "SCRAM-SHA1". The 73 mechanism does not provide a security layer. 75 The client begins by sending a message to the server containing 76 three pieces of information: 78 (1) An authorization identity. When the empty string is used, this 79 defaults to the authentication identity. This is used by system 80 administrators or proxy servers to login with a different user 81 identity. This field may be up to 255 octets and is terminated by 82 a NUL (0) octet. US-ASCII printable characters are preferred, 83 although UTF-8 [UTF-8] printable characters are permitted to 84 support international names. Use of character sets other than 85 US-ASCII and UTF-8 is forbidden. 87 (2) An authentication identity. The identity whose passphrase will 88 be used. This field may be up to 255 octets and is terminated by a 89 NUL (0) octet. US-ASCII printable characters are preferred, 90 although UTF-8 [UTF-8] printable characters are permitted to 91 support international names. Use of character sets other than 92 US-ASCII and UTF-8 is forbidden. 94 (3) A "client nonce" of 8 to 256 octets. It is important that this 95 be globally unique and somewhat random. It can be generated by 96 appending the system clock to a random number (advice for 97 generating good random numbers can be found in [RANDOM]) and the 98 client's IP address or domain name. 100 The server responds by sending a message containing three pieces of 101 information: 103 (4) An 8-octet salt value, specific to the authentication identity. 105 (5) A server id consisting of the service name of the protocol's 106 SASL profile followed by a "." followed by the domain name of the 107 server followed by an "@" and optional extension data terminated by 108 NUL. This will not be longer than 512 octets. The client SHOULD 109 verify this is correct. 111 (6) A "server nonce" of 8 to 32 octets. 113 The client then does the following: 115 (A) Create a buffer containing the user's passphrase. The client 116 MUST support passphrases of at least 64 octets. US-ASCII 117 characters are preferred, although UTF-8 characters are permitted. 118 Character sets other than UTF-8 MUST NOT be used. 120 (B) Apply the SHA1 function to (A), producing a 20 octet result. 121 Once this is done, (A) SHOULD be erased from memory. 123 (C) Apply the HMAC-SHA1 function with the result of (B) as the key 124 and the 8-octet salt (4) value as the data. This produces a 20 125 octet result. 127 (D) Create a buffer containing the server's response (4)-(6), 128 immediately followed by the initial client message (1)-(3). 130 (E) Apply the HMAC-SHA1 function with the result of (C) as the key 131 and the buffer from (D) as the data. This produces a 20-octet 132 result. 134 (F) Create a 20-octet buffer containing the exclusive-or of (B) and 135 (E). 137 The client then sends a message to the server containing the 138 following: 140 (7) The 20-octet result of step (F). 142 If authentication is successful, then the server responds with the 143 following: 145 (8) A 20-octet mutual authentication verifier. 147 The client SHOULD verify this with the following procedure: 149 (G) Create a buffer containing the initial client message (1)-(3) 150 immediately followed by the initial server response (4)-(6). 152 (H) Apply the HMAC-SHA1 function with the result of (C) as the key 153 and the buffer from (G) as the data. 155 (I) If the result of (H) matches (8), the server is authenticated. 157 A secured client MAY store the result of (B) to re-authenticate. 158 Permanent storage of (B) by the client is discouraged although it 159 is preferable to storing the actual passphrase. 161 3. Server Implementation of SCRAM-SHA1. 163 The section includes a step-by-step guide for server implementors. 164 Although section 7 contains the formal definition of the syntax and 165 is the authoritative reference in case of errors here, this section 166 in conjunction with section 2 should be sufficient to build a 167 correct implementation. 169 The server's authentication database contains an 8-octet salt and 170 20-octet verifier for each local user. The server MAY support 171 remote users using the syntax "user@host" for the authentication 172 identity, but if it doesn't it MUST truncate the authentication 173 identity at the "@" sign prior to lookup in the authentication 174 database. 176 The authentication verifier is equal to the result of step (C) 177 above. To create its initial response, the server simply looks up 178 the authentication identity to fetch the salt, and generates an 8 179 to 32 octet nonce. This nonce MUST be unique to prevent replay 180 attacks. It can be generated by appending a system clock to a 181 random number [RANDOM]. To verify the client's credentials, the 182 server preforms the following steps: 184 (a) Generate a buffer identical to step (D) for the client. 186 (b) Apply the HMAC-SHA1 function with the stored verifier as the 187 key and the result of (a) as the data. This produces a 20-octet 188 result equal to step (E) above. 190 (c) Exclusive-or the result of (b) with message (7) from the 191 client. This produces a 20-octet result which should be equal to 192 the output of step (B) above. 194 (d) Apply the HMAC-SHA1 function with (c) as the key and the stored 195 salt as the data. This produces a 20-octet result. 197 (e) if the result of (d) is equal to the stored verifier, then the 198 user is authenticated. 200 (f) Generate a buffer identical to step (G) above. 202 (g) Apply the HMAC-SHA1 function with the stored verifier as the 203 key and the buffer from (f) as the data. This produces a 20-octet 204 result. 206 The result of (g) is sent to the client as the mutual 207 authentication step. 209 4. Example 211 XXX: to be done 213 5. System Administrator Advice 215 This section includes advice for system administrators using this 216 mechanism. 218 Although the verifiers used by SCRAM-SHA1 are probably more secure 219 than those used by current plaintext mechanisms (such as Unix 220 /etc/password), it is still very important to keep them secret. 221 Just as tools exist to try common passwords against Unix 222 /etc/password files, it is also possible to build such tools for 223 SCRAM-SHA1. In addition, once a SCRAM-SHA1 verifier is stolen, a 224 passive (undetectable) snoop of that user logging in will result in 225 the output of step (B) above, which is sufficient to impersonate a 226 user. This is far better than current plaintext mechanisms where a 227 passive snoop always recovers the user's password, but is still a 228 serious concern. 230 Verifiers SHOULD be kept hidden from all users on the server. 231 Sites which distribute verifiers among multiple servers, SHOULD 232 encrypt them when distributing them. 234 SCRAM-SHA1 is only a good mechanism if passphrases are well chosen. 235 For this reason, implementations should use the term "passphrase" 236 rather than "password" and when a user's passphrase is set, site 237 policy restrictions should be applied. A reasonable site policy 238 would require passphrases of at least 10 characters with at least 239 one non-alphanumeric character. 241 SCRAM-SHA1 doesn't protect the integrity or privacy of data 242 exchanged after authentication. Use of an external encryption 243 layer or a stronger authentication mechanism such as Kerberos is 244 encouraged if this functionality is needed. 246 6. SCRAM-SHA1 Functional Notation 248 This section is designed to provide a quick understanding of 249 SCRAM-SHA1 for the mathematically inclined. 251 + octet concatenation 252 XOR the exclusive-or function 253 AU is the authentication user identity (NUL terminated) 254 AZ is the authorization user identity (NUL terminated) 255 if AZ would be the same as AU, a single NUL is used instead. 256 SV is the name of the service and server 257 p is the plaintext passphrase 258 H(x) is a one-way hash function applied to "x", such as SHA-1 259 M(x,y) is a message authentication code (MAC) such as HMAC-SHA1 260 "y" is the key and "x" is the text signed by the key. 261 V is a per-user verifier the server stores 262 s is a per-user salt value the server stores 263 P is the proof the client sends the server 264 Us is a unique nonce the server sends to the client 265 Uc is a unique nonce the client sends to the server 267 The verifier (V) is computed by applying the hash function to the 268 plaintext passphrase, then using the result to sign the salt. 269 Thus: 271 V = M(s, H(p)) 273 The proof (P) is computed as follows: 275 P = H(p) XOR M(s + SV + Us + AZ + AU + Uc, V) 277 The SCRAM exchange is as follows: 279 client -> server: AZ + AU + Uc 280 server -> client: s + SV + Us 281 client -> server: P 282 server -> client: M(AZ + AU + Uc + s + SV + Us, V) 283 The server verifies P by checking that the following is equal to V: 285 M(s, P XOR M(s + SV + Us + AZ + AU + Uc, V)) 287 The client verifies the server's identity by performing the same 288 computation the server does and comparing it to the server's 289 result. 291 7. Formal Syntax of SCRAM-SHA1 Messages 293 This is the formal syntactic definition of the client and server 294 messages. This uses the ABNF [ABNF] notation. 296 client-msg-1 = [authorize-id] NUL authenticate-id NUL client-nonce 298 server-msg-1 = salt server-id NUL server-nonce 300 client-msg-2 = proof 302 server-msg-2 = mutual-auth 304 passphrase = 8*UTF8-SAFE 305 ;; At least 64 octets MUST be supported 307 authorize-id = *UTF8-PRINT 308 ;; No more than 255 octets 310 authenticate-id = *UTF8-PRINT 311 ;; No more than 255 octets 313 server-id = service-name "." server-domain 314 "@" [ server-ext-data ] 315 ;; No more that 511 octets total 317 service-name = *USASCII-PRINT 318 ;; a GSSAPI service name 320 server-domain = *USASCII-PRINT 321 ;; an internet domain name 323 server-ext-data = *UTF8-SAFE 324 ;; extension data 326 server-id = *UTF8-PRINT 327 ;; No more than 511 octets 329 client-nonce = 8*256OCTET 331 server-nonce = 8*32OCTET 333 salt = 8OCTET 335 proof = 20OCTET 337 mutual-auth = 20OCTET 339 NUL = %x00 ;; US-ASCII NUL character 341 US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F 342 ;; US-ASCII except CR, LF, NUL 344 US-ASCII-PRINT = %x20-7E 345 ;; printable US-ASCII including SPACE 347 UTF8-SAFE = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3 348 / UTF8-4 / UTF8-5 350 UTF8-PRINT = US-ASCII-PRINT / UTF8-1 / UTF8-2 / UTF8-3 351 / UTF8-4 / UTF8-5 353 UTF8-CONT = %x80..BF 355 UTF8-1 = %xC0..DF UTF8-CONT 357 UTF8-2 = %xE0..EF 2UTF8-CONT 359 UTF8-3 = %xF0..F7 3UTF8-CONT 361 UTF8-4 = %xF8..FB 4UTF8-CONT 363 UTF8-5 = %xFC..FD 5UTF8-CONT 365 8. Security Considerations 367 Security considerations are discussed throughout this document. 368 The security considerations of SHA1 [SHA1] and HMAC [HMAC] also 369 apply. 371 SCRAM-SHA1 is conjectured to be a reasonably strong mechanism as 372 long as passphrases are well chosen and verifiers are kept secret. 373 Making a SCRAM-SHA1 verifier public is believed to be no worse than 374 making a Unix /etc/password verifier public when a plaintext-only 375 mechanism is used. 377 There are two particularly dangerous attacks against SCRAM-SHA1. 378 The first is to passively record an authentication session (or 379 steal the verifier) and perform an offline dictionary attack to 380 find the passphrase. This type of attack is estimated to be about 381 40% effective at typical sites with current behavior patterns 382 [SCHNEIER]. Use of the term "passphrase", enforcement of site 383 policy when passphrases are changed and user education may improve 384 this to acceptable levels for many sites. 386 The second attack is to both steal the verifier for a user and 387 passively record an authentication session by that user. This 388 results in the ability to impersonate that user and more than 389 doubles the speed of a dictionary attack or brute-force attack to 390 recover the actual passphrase. For this reason, verifiers should 391 be kept well-protected. 393 This mechanism provides no protection for the session after 394 authentication. A passive observer can see information 395 transmitted, and an active attacker can hijack the session. Use of 396 an external encryption layer such as TLS [TLS] can address this 397 problem. 399 This mechanism uses a hash-function combined with exclusive-or as a 400 simple single-block cipher. [SCHNEIER] expresses reservations 401 about ciphers built using one-way hash functions, although not all 402 of his reservations may apply to this limited use. 404 9. Intellectual Property Issues and Prior Art 406 The author is not aware of any patents which apply to this 407 mechanism. 409 This is primarily a derivative of simple hash-based challenge 410 response systems. The hash-based challenge response idea has 411 existed since at least 1992, when the RIPE project published the 412 SKID algorithm according to [SCHNEIER]. 414 The repeated-hash idea used to verify the client's authenticator is 415 derived from S/KEY [SKEY]. 417 The idea of using a hash function to construct a cipher (with 418 exclusive-or) was originally invented by Peter Gutmann in 1993 419 according to [SCHNEIER]. 421 The idea of using salt to protect against global dictionary attacks 422 dates back to the unix /etc/password system or before. There is 423 some discussion of this in [SCHNEIER]. 425 SCRAM combines these four techniques. The author of this 426 specification first proposed this publicly on a mailing list July 427 16, 1997. There is nothing new about this mechanism beyond the 428 idea of combining these existing techniques. 430 The SCRAM algorithm includes a single-block cipher capable of 431 encrypting 20 octets of authentication data. The author does not 432 believe this will cause problems for export restrictions, but 433 checking with the appropriate government(s) should be considered. 434 Computer readable source code for cryptographic hash functions such 435 as MD5 and SHA1 have been exported from the United States without 436 problems. 438 10. References 440 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: 441 ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt 443 [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 444 for Simple Challenge/Response", RFC 2095, MCI, January 1997. 446 448 [HMAC] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 449 Authentication", RFC 2104, IBM, UCSD, February 1997. 451 453 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 454 4rev1", RFC 2060, University of Washington, December 1996. 456 458 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 459 Requirement Levels", RFC 2119, Harvard University, March 1997. 461 463 [RANDOM] Eastlake, Crocker, Schiller, "Randomness Recommendations 464 for Security", RFC 1750, DEC, Cybercash, MIT, December 1994. 466 468 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", 469 work in progress. 471 [SCHNEIER] Schneier, "Applied Cryptography: Protocols, Algorithms 472 and Source Code in C," John Wiley and Sons, Inc., 1996. 474 [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 476 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC 477 1760, Bellcore, February 1995. 479 481 [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in 482 progress. 484 [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and 485 ISO 10646", RFC 2044, Alis Technologies, October 1996. 487 489 11. Author's Address 491 Chris Newman 492 Innosoft International, Inc. 493 1050 Lakes Drive 494 West Covina, CA 91790 USA 496 Email: chris.newman@innosoft.com 498 A. Appendix - Sample Source Code 500 XXX: to be done 502 B. Appendix - TWEKE Proposal 504 Tom Wu has proposed adding a Diffie-Hellman key exchange to this 505 mechanism. Diffie-Hellman works roughly as follows: 507 Server picks g, n and x. Server computes X = g^x mod n. 509 server -> client: g, n, X 511 Client picks y and computes Y = g^y mod n and K = X^y mod n. 513 client -> server: Y 515 Server computes K = Y^x mod n (which is the same as the client's 516 K). 518 If g, n, x and y are sufficiently big and have the right 519 characteristics, then both the client and server share K which is 520 very difficult for a passive evesdropper to obtain. 522 The TWEKE proposal would add the following steps: 524 (4.5) Server sends g, n, X. 526 (7.5) Client sends Y. 528 and would modify steps (D) and (a) to include the value K. This 529 would result in a protocol safe from passive attacks. The expense 530 would be reduced performance, the need for a bignum math library 531 and a requirement that an export license be obtained from certain 532 governments (included the United States). This would not defend 533 against active attacks, but should be free of patent restrictions 534 after October 6th, 1997. 536 TWEKE might be harder to deploy than SCRAM due to the higher math 537 and the use of public key technology. 539 C. Appendix - Additional Services 541 Several additional services are needed to make SCRAM useful in 542 various usage scenarios. These include remote authentication 543 database support for servers, authentication database APIs for 544 servers, remote passphrase change support for clients, single- 545 sign-on APIs for clients and management tools. The server-id is 546 included to facilite the remote authentication database service. 547 Otherwise these issues are deferred for future work.