| blob | 915b9adea79a066710f1dfe69905efdc5c0ee3d6 |
1 \r
2 \r
3 \r
4 \r
5 \r
6 \r
7 Network Working Group Abhijit Menon-Sen\r
8 Internet-Draft Oryx Mail Systems GmbH\r
9 Intended Status: Proposed Standard Chris Newman\r
10 Expires: August 2009 Sun Microsystems\r
11 Alexey Melnikov\r
12 Isode Ltd\r
13 February 15, 2009\r
14 \r
15 \r
16 Salted Challenge Response (SCRAM) SASL Mechanism\r
17 \r
18 draft-newman-auth-scram-09.txt\r
19 \r
20 \r
21 Status of this Memo\r
22 \r
23 This Internet-Draft is submitted to IETF in full conformance with\r
24 the provisions of BCP 78 and BCP 79.\r
25 \r
26 Internet-Drafts are working documents of the Internet Engineering\r
27 Task Force (IETF), its areas, and its working groups. Note that\r
28 other groups may also distribute working documents as Internet-\r
29 Drafts.\r
30 \r
31 Internet-Drafts are draft documents valid for a maximum of six\r
32 months and may be updated, replaced, or obsoleted by other documents\r
33 at any time. It is inappropriate to use Internet-Drafts as reference\r
34 material or to cite them other than as "work in progress."\r
35 \r
36 The list of current Internet-Drafts can be accessed at\r
37 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-\r
38 Draft Shadow Directories can be accessed at\r
39 http://www.ietf.org/shadow.html.\r
40 \r
41 This Internet-Draft expires in July 2009.\r
42 \r
43 \r
44 Copyright Notice\r
45 \r
46 Copyright (c) 2009 IETF Trust and the persons identified as the\r
47 document authors. All rights reserved.\r
48 \r
49 This document is subject to BCP 78 and the IETF Trust's Legal\r
50 Provisions Relating to IETF Documents\r
51 (http://trustee.ietf.org/license-info) in effect on the date of\r
52 publication of this document. Please review these documents\r
53 carefully, as they describe your rights and restrictions with\r
54 respect to this document.\r
55 \r
56 \r
57 \r
58 Menon-Sen & Co Expires August 2009 FF[Page 1]\r
59 \r
60 \r
61 \r
62 \r
63 \r
64 Internet-draft February 2009\r
65 \r
66 \r
67 Abstract\r
68 \r
69 The secure authentication mechanism most widely deployed and used by\r
70 Internet application protocols is the transmission of clear-text\r
71 passwords over a channel protected by Transport Layer Security\r
72 (TLS). There are some significant security concerns with that\r
73 mechanism, which could be addressed by the use of a challenge\r
74 response authentication mechanism protected by TLS. Unfortunately,\r
75 the challenge response mechanisms presently on the standards track\r
76 all fail to meet requirements necessary for widespread deployment,\r
77 and have had success only in limited use.\r
78 \r
79 This specification describes a family of authentication mechanisms\r
80 called the Salted Challenge Response Authentication Mechanism\r
81 (SCRAM), which addresses the security concerns and meets the\r
82 deployability requirements. When used in combination with TLS or an\r
83 equivalent security layer, a mechanism from this family could\r
84 improve the status-quo for application protocol authentication and\r
85 provide a suitable choice for a mandatory-to-implement mechanism for\r
86 future application protocol standards.\r
87 \r
88 \r
89 1. Conventions Used in This Document\r
90 \r
91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
93 document are to be interpreted as described in [RFC2119].\r
94 \r
95 Formal syntax is defined by [RFC5234] including the core rules\r
96 defined in Appendix B of [RFC5234].\r
97 \r
98 Example lines prefaced by "C:" are sent by the client and ones\r
99 prefaced by "S:" by the server. If a single "C:" or "S:" label\r
100 applies to multiple lines, then the line breaks between those lines\r
101 are for editorial clarity only, and are not part of the actual\r
102 protocol exchange.\r
103 \r
104 \r
105 1.1. Terminology\r
106 \r
107 This document uses several terms defined in [RFC4949] ("Internet\r
108 Security Glossary") including the following: authentication,\r
109 authentication exchange, authentication information, brute force,\r
110 challenge-response, cryptographic hash function, dictionary attack,\r
111 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,\r
112 one-way encryption function, password, replay attack and salt.\r
113 Readers not familiar with these terms should use that glossary as a\r
114 reference.\r
115 \r
116 \r
117 \r
118 Menon-Sen & Co Expires August 2009 FF[Page 2]\r
119 \r
120 \r
121 \r
122 \r
123 \r
124 Internet-draft February 2009\r
125 \r
126 \r
127 Some clarifications and additional definitions follow:\r
128 \r
129 - Authentication information: Information used to verify an identity\r
130 claimed by a SCRAM client. The authentication information for a\r
131 SCRAM identity consists of salt, iteration count, the "StoredKey"\r
132 and "ServerKey" (as defined in the algorithm overview) for each\r
133 supported cryptographic hash function.\r
134 \r
135 - Authentication database: The database used to look up the\r
136 authentication information associated with a particular identity.\r
137 For application protocols, LDAPv3 (see [RFC4510]) is frequently\r
138 used as the authentication database. For network-level protocols\r
139 such as PPP or 802.11x, the use of RADIUS is more common.\r
140 \r
141 - Base64: An encoding mechanism defined in [RFC4648] which converts\r
142 an octet string input to a textual output string which can be\r
143 easily displayed to a human. The use of base64 in SCRAM is\r
144 restricted to the canonical form with no whitespace.\r
145 \r
146 - Octet: An 8-bit byte.\r
147 \r
148 - Octet string: A sequence of 8-bit bytes.\r
149 \r
150 - Salt: A random octet string that is combined with a password\r
151 before applying a one-way encryption function. This value is used\r
152 to protect passwords that are stored in an authentication\r
153 database.\r
154 \r
155 \r
156 1.2. Notation\r
157 \r
158 The pseudocode description of the algorithm uses the following\r
159 notations:\r
160 \r
161 - ":=": The variable on the left hand side represents the octet\r
162 string resulting from the expression on the right hand side.\r
163 \r
164 - "+": Octet string concatenation.\r
165 \r
166 - "[ ]": A portion of an expression enclosed in "[" and "]" may not\r
167 be included in the result under some circumstances. See the\r
168 associated text for a description of those circumstances.\r
169 \r
170 - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in\r
171 [RFC2104]) using the octet string represented by "key" as the key\r
172 and the octet string "str" as the input string. The size of the\r
173 result is the hash result size for the hash function in use. For\r
174 example, it is 20 octets for SHA-1 (see [RFC3174]).\r
175 \r
176 \r
177 \r
178 Menon-Sen & Co Expires August 2009 FF[Page 3]\r
179 \r
180 \r
181 \r
182 \r
183 \r
184 Internet-draft February 2009\r
185 \r
186 \r
187 - H(str): Apply the cryptographic hash function to the octet string\r
188 "str", producing an octet string as a result. The size of the\r
189 result depends on the hash result size for the hash function in\r
190 use.\r
191 \r
192 - XOR: Apply the exclusive-or operation to combine the octet string\r
193 on the left of this operator with the octet string on the right of\r
194 this operator. The length of the output and each of the two inputs\r
195 will be the same for this use.\r
196 \r
197 - Hi(str, salt):\r
198 \r
199 U0 := HMAC(str, salt || INT(1))\r
200 U1 := HMAC(str, U0)\r
201 U2 := HMAC(str, U1)\r
202 ...\r
203 Ui-1 := HMAC(str, Ui-2)\r
204 Ui := HMAC(str, Ui-1)\r
205 \r
206 Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui\r
207 where "i" is the iteration count, "||" is the string concatenation\r
208 operator and INT(g) is a four-octet encoding of the integer g,\r
209 most significant octet first.\r
210 \r
211 This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and\r
212 with dkLen == output length of HMAC() == output length of H().\r
213 \r
214 \r
215 \r
216 2. Introduction\r
217 \r
218 This specification describes a family of authentication mechanisms\r
219 called the Salted Challenge Response Authentication Mechanism\r
220 (SCRAM) which addresses the requirements necessary to deploy a\r
221 challenge-response mechanism more widely than past attempts. When\r
222 used in combination with Transport Layer Security (TLS, see [TLS])\r
223 or an equivalent security layer, a mechanism from this family could\r
224 improve the status-quo for application protocol authentication and\r
225 provide a suitable choice for a mandatory-to-implement mechanism for\r
226 future application protocol standards.\r
227 \r
228 For simplicity, this family of mechanism does not presently include\r
229 negotiation of a security layer. It is intended to be used with an\r
230 external security layer such as that provided by TLS or SSH.\r
231 \r
232 SCRAM provides the following protocol features:\r
233 \r
234 - The authentication information stored in the authentication\r
235 \r
236 \r
237 \r
238 Menon-Sen & Co Expires August 2009 FF[Page 4]\r
239 \r
240 \r
241 \r
242 \r
243 \r
244 Internet-draft February 2009\r
245 \r
246 \r
247 database is not sufficient by itself to impersonate the client.\r
248 The information is salted to prevent a pre-stored dictionary\r
249 attack if the database is stolen.\r
250 \r
251 - The server does not gain the ability to impersonate the client to\r
252 other servers (with an exception for server-authorized proxies).\r
253 \r
254 - The mechanism permits the use of a server-authorized proxy without\r
255 requiring that proxy to have super-user rights with the back-end\r
256 server.\r
257 \r
258 - A standard attribute is defined to enable storage of the\r
259 authentication information in LDAPv3 (see [RFC4510]).\r
260 \r
261 - Both the client and server can be authenticated by the protocol.\r
262 \r
263 For an in-depth discussion of why other challenge response\r
264 mechanisms are not considered sufficient, see appendix A. For more\r
265 information about the motivations behind the design of this\r
266 mechanism, see appendix B.\r
267 \r
268 Comments regarding this draft may be sent either to the ietf-\r
269 sasl@imc.org mailing list or to the authors.\r
270 \r
271 \r
272 3. SCRAM Algorithm Overview\r
273 \r
274 Note that this section omits some details, such as client and server\r
275 nonces. See Section 5 for more details.\r
276 \r
277 To begin with, the client is in possession of a username and\r
278 password. It sends the username to the server, which retrieves the\r
279 corresponding authentication information, i.e. a salt, StoredKey,\r
280 ServerKey and the iteration count i. (Note that a server\r
281 implementation may chose to use the same iteration count for all\r
282 account.) The server sends the salt and the iteration count to the\r
283 client, which then computes the following values and sends a\r
284 ClientProof to the server:\r
285 \r
286 SaltedPassword := Hi(password, salt)\r
287 ClientKey := H(SaltedPassword)\r
288 StoredKey := H(ClientKey)\r
289 AuthMessage := client-first-message + "," +\r
290 server-first-message + "," +\r
291 final-client-message-without-proof\r
292 ClientSignature := HMAC(StoredKey, AuthMessage)\r
293 ClientProof := ClientKey XOR ClientSignature\r
294 ServerKey := HMAC(SaltedPassword, salt)\r
295 \r
296 \r
297 \r
298 Menon-Sen & Co Expires August 2009 FF[Page 5]\r
299 \r
300 \r
301 \r
302 \r
303 \r
304 Internet-draft February 2009\r
305 \r
306 \r
307 ServerSignature := HMAC(ServerKey, AuthMessage)\r
308 \r
309 The server authenticates the client by computing the\r
310 ClientSignature, exclusive-ORing that with the ClientProof to\r
311 recover the ClientKey and verifying the correctness of the ClientKey\r
312 by applying the hash function and comparing the result to the\r
313 StoredKey. If the ClientKey is correct, this proves that the client\r
314 has access to the user's password.\r
315 \r
316 Similarly, the client authenticates the server by computing the\r
317 ServerSignature and comparing it to the value sent by the server.\r
318 If the two are equal, it proves that the server had access to the\r
319 user's ServerKey.\r
320 \r
321 The AuthMessage is computed by concatenating messages from the\r
322 authentication exchange. The format of these messages is defined in\r
323 the Formal Syntax section.\r
324 \r
325 \r
326 4. SCRAM mechanism names\r
327 \r
328 A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the\r
329 uppercased name of the underlying hashed function taken from the\r
330 IANA "Hash Function Textual Names" registry (see\r
331 http://www.iana.org).\r
332 \r
333 For interoperability, all SCRAM clients and servers MUST implement\r
334 the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an\r
335 authentication mechanism from the SCRAM family that uses the SHA-1\r
336 hash function as defined in [RFC3174].\r
337 \r
338 \r
339 5. SCRAM Authentication Exchange\r
340 \r
341 SCRAM is a text protocol where the client and server exchange\r
342 messages containing one or more attribute-value pairs separated by\r
343 commas. Each attribute has a one-letter name. The messages and their\r
344 attributes are described in section 5.1, and defined in the Formal\r
345 Syntax section.\r
346 \r
347 This is a simple example of a SCRAM-HMAC-SHA-1 authentication\r
348 exchange:\r
349 C: n=Chris Newman,r=ClientNonce\r
350 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128\r
351 C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4\r
352 S: v=WxPv/siO5l+qxN4\r
353 \r
354 With channel-binding data sent by the client this might look like this:\r
355 \r
356 \r
357 \r
358 Menon-Sen & Co Expires August 2009 FF[Page 6]\r
359 \r
360 \r
361 \r
362 \r
363 \r
364 Internet-draft February 2009\r
365 \r
366 \r
367 C: n=Chris Newman,r=ClientNonce\r
368 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128\r
369 C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4\r
370 S: v=WxPv/siO5l+qxN4\r
371 \r
372 <<Note that the channel-bind data above, as well as all hashes are fake>>\r
373 \r
374 First, the client sends a message containing the username, and a\r
375 random, unique nonce. In response, the server sends the user's\r
376 iteration count i, the user's salt, and appends its own nonce to the\r
377 client-specified one. The client then responds with the same nonce\r
378 and a ClientProof computed using the selected hash function as\r
379 explained earlier. In this step the client can also include an\r
380 optional authorization identity. The server verifies the nonce and\r
381 the proof, verifies that the authorization identity (if supplied by\r
382 the client in the second message) is authorized to act as the\r
383 authentication identity, and, finally, it responds with a\r
384 ServerSignature, concluding the authentication exchange. The client\r
385 then authenticates the server by computing the ServerSignature and\r
386 comparing it to the value sent by the server. If the two are\r
387 different, the client MUST consider the authentication exchange to\r
388 be unsuccessful and it might have to drop the connection.\r
389 \r
390 \r
391 5.1 SCRAM attributes\r
392 \r
393 This section describes the permissible attributes, their use, and\r
394 the format of their values. All attribute names are single US-ASCII\r
395 letters and are case-sensitive.\r
396 \r
397 - a: This optional attribute specifies an authorization identity. A\r
398 client may include it in its second message to the server if it\r
399 wants to authenticate as one user, but subsequently act as a\r
400 different user. This is typically used by an administrator to\r
401 perform some management task on behalf of another user, or by a\r
402 proxy in some situations.\r
403 \r
404 Upon the receipt of this value the server verifies its correctness\r
405 according to the used SASL protocol profile. Failed verification\r
406 results in failed authentication exchange.\r
407 \r
408 If this attribute is omitted (as it normally would be), or\r
409 specified with an empty value, the authorization identity is\r
410 assumed to be derived from the username specified with the\r
411 (required) "n" attribute.\r
412 \r
413 The server always authenticates the user specified by the "n"\r
414 attribute. If the "a" attribute specifies a different user, the\r
415 \r
416 \r
417 \r
418 Menon-Sen & Co Expires August 2009 FF[Page 7]\r
419 \r
420 \r
421 \r
422 \r
423 \r
424 Internet-draft February 2009\r
425 \r
426 \r
427 server associates that identity with the connection after\r
428 successful authentication and authorization checks.\r
429 \r
430 The syntax of this field is the same as that of the "n" field with\r
431 respect to quoting of '=' and ','.\r
432 \r
433 - n: This attribute specifies the name of the user whose password is\r
434 used for authentication. A client must include it in its first\r
435 message to the server. If the "a" attribute is not specified\r
436 (which would normally be the case), this username is also the\r
437 identity which will be associated with the connection subsequent\r
438 to authentication and authorization.\r
439 \r
440 Before sending the username to the server, the client MUST prepare\r
441 the username using the "SASLPrep" profile [SASLPrep] of the\r
442 "stringprep" algorithm [RFC3454]. If the preparation of the\r
443 username fails or results in an empty string, the client SHOULD\r
444 abort the authentication exchange (*).\r
445 \r
446 (*) An interactive client can request a repeated entry of the\r
447 username value.\r
448 \r
449 Upon receipt of the username by the server, the server SHOULD\r
450 prepare it using the "SASLPrep" profile [SASLPrep] of the\r
451 "stringprep" algorithm [RFC3454]. If the preparation of the\r
452 username fails or results in an empty string, the server SHOULD\r
453 abort the authentication exchange.\r
454 \r
455 The characters ',' or '=' in usernames are sent as '=2C' and '=3D'\r
456 respectively. If the server receives a username which contains '='\r
457 not followed by either '2C' or '3D', then the server MUST fail the\r
458 authentication.\r
459 \r
460 - m: This attribute is reserved for future extensibility. In this\r
461 version of SCRAM, its presence in a client or a server message\r
462 MUST cause authentication failure when the attribute is parsed by\r
463 the other end.\r
464 \r
465 - r: This attribute specifies a sequence of random printable\r
466 characters excluding ',' which forms the nonce used as input to\r
467 the hash function. No quoting is applied to this string (unless\r
468 the binding of SCRAM to a particular protocol states otherwise).\r
469 As described earlier, the client supplies an initial value in its\r
470 first message, and the server augments that value with its own\r
471 nonce in its first response. It is important that this be value\r
472 different for each authentication. The client MUST verify that the\r
473 initial part of the nonce used in subsequent messages is the same\r
474 as the nonce it initially specified. The server MUST verify that\r
475 \r
476 \r
477 \r
478 Menon-Sen & Co Expires August 2009 FF[Page 8]\r
479 \r
480 \r
481 \r
482 \r
483 \r
484 Internet-draft February 2009\r
485 \r
486 \r
487 the nonce sent by the client in the second message is the same as\r
488 the one sent by the server in its first message.\r
489 \r
490 - c: This optional attribute specifies base64-encoded channel-\r
491 binding data. It is sent by the client in the second step. If\r
492 specified by the client, if the server supports the specified\r
493 channel binding type and if the server can't verify it, then the\r
494 server MUST fail the authentication exchange. Whether this\r
495 attribute is included, and the meaning and contents of the\r
496 channel-binding data depends on the external security layer in\r
497 use. This is necessary to detect a man-in-the-middle attack on the\r
498 security layer.\r
499 \r
500 - s: This attribute specifies the base64-encoded salt used by the\r
501 server for this user. It is sent by the server in its first\r
502 message to the client.\r
503 \r
504 - i: This attribute specifies an iteration count for the selected\r
505 hash function and user, and must be sent by the server along with\r
506 the user's salt.\r
507 \r
508 For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash\r
509 iteration-count of at least 128.\r
510 \r
511 - p: This attribute specifies a base64-encoded ClientProof. The\r
512 client computes this value as described in the overview and sends\r
513 it to the server.\r
514 \r
515 - v: This attribute specifies a base64-encoded ServerSignature. It\r
516 is sent by the server in its final message, and may be used by the\r
517 client to verify that the server has access to the user's\r
518 authentication information. This value is computed as explained in\r
519 the overview.\r
520 \r
521 \r
522 6. Formal Syntax\r
523 \r
524 The following syntax specification uses the Augmented Backus-Naur\r
525 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3"\r
526 and "UTF8-4" non-terminal are defined in [UTF-8].\r
527 \r
528 generic-message = attr-val *("," attr-val)\r
529 ;; Generic syntax of any server challenge\r
530 ;; or client response\r
531 \r
532 attr-val = ALPHA "=" value\r
533 \r
534 value = *(value-char)\r
535 \r
536 \r
537 \r
538 Menon-Sen & Co Expires August 2009 FF[Page 9]\r
539 \r
540 \r
541 \r
542 \r
543 \r
544 Internet-draft February 2009\r
545 \r
546 \r
547 value-safe-char = %01-2B / %2D-3C / %3E-7F /\r
548 UTF8-2 / UTF-3 / UTF8-4\r
549 ;; UTF8-char except NUL, "=", and ",".\r
550 \r
551 value-char = value-safe-char / "="\r
552 \r
553 base64-char = ALPHA / DIGIT / "/" / "+"\r
554 \r
555 base64-4 = 4*4(base64-char)\r
556 \r
557 base64-3 = 3*3(base64-char) "="\r
558 \r
559 base64-2 = 2*2(base64-char) "=="\r
560 \r
561 base64 = *(base64-4) [base64-3 / base64-2]\r
562 \r
563 posit-number = (%x31-39) *DIGIT\r
564 ;; A positive number\r
565 \r
566 saslname = 1*(value-safe-char / "=2C" / "=3D")\r
567 ;; Conforms to <value>\r
568 \r
569 authzid = "a=" saslname\r
570 ;; Protocol specific.\r
571 \r
572 username = "n=" saslname\r
573 ;; Usernames are prepared using SASLPrep.\r
574 \r
575 reserved-mext = "m=" 1*(value-char)\r
576 ;; Reserved for signalling mandatory extensions.\r
577 ;; The exact syntax will be defined in\r
578 ;; the future.\r
579 \r
580 channel-binding = "c=" base64\r
581 \r
582 proof = "p=" base64\r
583 \r
584 nonce = "r=" c-nonce [s-nonce]\r
585 ;; Second part provided by server.\r
586 \r
587 c-nonce = value\r
588 \r
589 s-nonce = value\r
590 \r
591 salt = "s=" base64\r
592 \r
593 verifier = "v=" base64\r
594 ;; base-64 encoded ServerSignature.\r
595 \r
596 \r
597 \r
598 Menon-Sen & Co Expires August 2009 FF[Page 10]\r
599 \r
600 \r
601 \r
602 \r
603 \r
604 Internet-draft February 2009\r
605 \r
606 \r
607 iteration-count = "i=" posit-number\r
608 ;; A positive number\r
609 \r
610 client-first-message =\r
611 [reserved-mext ","] username "," nonce [","\r
612 extensions]\r
613 \r
614 server-first-message =\r
615 [reserved-mext ","] nonce "," salt ","\r
616 iteration-count ["," extensions]\r
617 \r
618 client-final-message-without-proof =\r
619 [authzid ","] [channel-binding ","] nonce [","\r
620 extensions]\r
621 \r
622 client-final-message =\r
623 client-final-message-without-proof "," proof\r
624 \r
625 server-final-message =\r
626 verifier ["," extensions]\r
627 \r
628 extensions = attr-val *("," attr-val)\r
629 ;; All extensions are optional,\r
630 ;; i.e. unrecognized attributes\r
631 ;; not defined in this document\r
632 ;; MUST be ignored.\r
633 \r
634 \r
635 7. Security Considerations\r
636 \r
637 If the authentication exchange is performed without a strong\r
638 security layer, then a passive eavesdropper can gain sufficient\r
639 information to mount an offline dictionary or brute-force attack\r
640 which can be used to recover the user's password. The amount of time\r
641 necessary for this attack depends on the cryptographic hash function\r
642 selected, the strength of the password and the iteration count\r
643 supplied by the server. An external security layer with strong\r
644 encryption will prevent this attack.\r
645 \r
646 If the external security layer used to protect the SCRAM exchange\r
647 uses an anonymous key exchange, then the SCRAM channel binding\r
648 mechanism can be used to detect a man-in-the-middle attack on the\r
649 security layer and cause the authentication to fail as a result.\r
650 However, the man-in-the-middle attacker will have gained sufficient\r
651 information to mount an offline dictionary or brute-force attack.\r
652 For this reason, SCRAM includes the ability to increase the\r
653 iteration count over time.\r
654 \r
655 \r
656 \r
657 \r
658 Menon-Sen & Co Expires August 2009 FF[Page 11]\r
659 \r
660 \r
661 \r
662 \r
663 \r
664 Internet-draft February 2009\r
665 \r
666 \r
667 If the authentication information is stolen from the authentication\r
668 database, then an offline dictionary or brute-force attack can be\r
669 used to recover the user's password. The use of salt mitigates this\r
670 attack somewhat by requiring a separate attack on each password.\r
671 Authentication mechanisms which protect against this attack are\r
672 available (e.g., the EKE class of mechanisms), but the patent\r
673 situation is presently unclear.\r
674 \r
675 If an attacker obtains the authentication information from the\r
676 authentication repository and either eavesdrops on one\r
677 authentication exchange or impersonates a server, the attacker gains\r
678 the ability to impersonate that user to all servers providing SCRAM\r
679 access using the same hash function, password, iteration count and\r
680 salt. For this reason, it is important to use randomly-generated\r
681 salt values.\r
682 \r
683 If the server detects (from the value of the client-specified "h"\r
684 attribute) that both endpoints support a stronger hash function that\r
685 the one the client actually chooses to use, then it SHOULD treat\r
686 this as a downgrade attack and reject the authentication attempt.\r
687 \r
688 A hostile server can perform a computational denial-of-service\r
689 attack on clients by sending a big iteration count value.\r
690 \r
691 \r
692 \r
693 \r
694 \r
695 \r
696 \r
697 \r
698 \r
699 \r
700 \r
701 \r
702 \r
703 \r
704 \r
705 \r
706 \r
707 \r
708 \r
709 \r
710 \r
711 \r
712 \r
713 \r
714 \r
715 \r
716 \r
717 \r
718 Menon-Sen & Co Expires August 2009 FF[Page 12]\r
719 \r
720 \r
721 \r
722 \r
723 \r
724 Internet-draft February 2009\r
725 \r
726 \r
727 8. IANA considerations\r
728 \r
729 IANA is requested to add the following entry to the SASL Mechanism\r
730 registry established by [RFC4422]:\r
731 \r
732 To: iana@iana.org\r
733 Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1\r
734 \r
735 SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1\r
736 Security considerations: Section 7 of [RFCXXXX]\r
737 Published specification (optional, recommended): [RFCXXXX]\r
738 Person & email address to contact for further information:\r
739 IETF SASL WG <ietf-sasl@imc.org>\r
740 Intended usage: COMMON\r
741 Owner/Change controller: IESG <iesg@ietf.org>\r
742 Note:\r
743 \r
744 Note that even though this document defines a family of SCRAM-HMAC\r
745 mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in\r
746 the SASL Mechanisms registry. IANA is requested to prevent future\r
747 registrations of SASL mechanisms starting with SCRAM-HMAC- without\r
748 consulting the SASL mailing list <ietf-sasl@imc.org> first.\r
749 \r
750 Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC\r
751 SASL mechanism MUST be explicitly registered with IANA and MUST\r
752 comply with SCRAM-HMAC mechanism naming convention defined in\r
753 Section 4 of this document.\r
754 \r
755 \r
756 \r
757 9. Acknowedgements\r
758 \r
759 The authors would like to thank Dave Cridland for his contributions\r
760 to this document.\r
761 \r
762 \r
763 10. Normative References\r
764 \r
765 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data\r
766 Encodings", RFC 4648, SJD, October 2006.\r
767 \r
768 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO\r
769 10646", STD 63, RFC 3629, November 2003.\r
770 \r
771 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for\r
772 Message Authentication", IBM, February 1997.\r
773 \r
774 [RFC2119] Bradner, "Key words for use in RFCs to Indicate\r
775 \r
776 \r
777 \r
778 Menon-Sen & Co Expires August 2009 FF[Page 13]\r
779 \r
780 \r
781 \r
782 \r
783 \r
784 Internet-draft February 2009\r
785 \r
786 \r
787 Requirement Levels", RFC 2119, Harvard University, March\r
788 1997.\r
789 \r
790 [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC\r
791 3174, Motorola, September 2001\r
792 \r
793 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax\r
794 Specifications: ABNF", RFC 5234, January 2008.\r
795 \r
796 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security\r
797 Layer (SASL)", RFC 4422, Isode Limited, June 2006.\r
798 \r
799 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user\r
800 names and passwords", RFC 4013, February 2005.\r
801 \r
802 [RFC3454] Hoffman, P., Blanchet, M., "Preparation of\r
803 Internationalized Strings ("stringprep")", RFC 3454,\r
804 December 2002.\r
805 \r
806 \r
807 \r
808 11. Informative References\r
809 \r
810 [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension\r
811 for Simple Challenge/Response", RFC 2195, MCI, September\r
812 1997.\r
813 \r
814 [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",\r
815 RFC 2202, IBM, September 1997\r
816 \r
817 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography\r
818 Specification Version 2.0", RFC 2898, September 2000.\r
819 \r
820 [TLS] Dierks, Rescorla, "The Transport Layer Security (TLS)\r
821 Protocol, Version 1.2", RFC 5246, August 2008.\r
822 \r
823 [RFC4949] Shirey, "Internet Security Glossary, Version 2", RFC\r
824 4949, FYI 0036, August 2007.\r
825 \r
826 [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for\r
827 Security", RFC 4086, BCP 0106, Motorola Laboratories,\r
828 June 2005.\r
829 \r
830 [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP):\r
831 Technical Specification Road Map", RFC 4510, June 2006.\r
832 \r
833 [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication\r
834 as a SASL Mechanism", RFC 2831, May 2000. <<Also draft-\r
835 \r
836 \r
837 \r
838 Menon-Sen & Co Expires August 2009 FF[Page 14]\r
839 \r
840 \r
841 \r
842 \r
843 \r
844 Internet-draft February 2009\r
845 \r
846 \r
847 ietf-sasl-rfc2831bis-12.txt>>\r
848 \r
849 [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in\r
850 progress, draft-ietf-sasl-digest-to-historic-00.txt, July\r
851 2008\r
852 \r
853 [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress,\r
854 draft-ietf-sasl-crammd5-to-historic-00.txt, November\r
855 2008.\r
856 \r
857 [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security\r
858 Layer (SASL) Mechanism" RFC 4616, August 2006.\r
859 \r
860 \r
861 12. Authors' Addresses\r
862 \r
863 Abhijit Menon-Sen\r
864 Oryx Mail Systems GmbH\r
865 \r
866 Email: ams@oryx.com\r
867 \r
868 \r
869 Alexey Melnikov\r
870 Isode Ltd\r
871 \r
872 EMail: Alexey.Melnikov@isode.com\r
873 \r
874 \r
875 Chris Newman\r
876 Sun Microsystems\r
877 1050 Lakes Drive\r
878 West Covina, CA 91790\r
879 USA\r
880 \r
881 Email: chris.newman@sun.com\r
882 \r
883 \r
884 Appendix A: Other Authentication Mechanisms\r
885 \r
886 The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex\r
887 to implement and test, and thus has poor interoperability. The\r
888 security layer is often not implemented, and almost never used;\r
889 everyone uses TLS instead. For a more complete list of problems\r
890 with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST-\r
891 HISTORIC].\r
892 \r
893 The CRAM-MD5 SASL mechanism, while widely deployed has also some\r
894 problems, in particular it is missing some modern SASL features such\r
895 \r
896 \r
897 \r
898 Menon-Sen & Co Expires August 2009 FF[Page 15]\r
899 \r
900 \r
901 \r
902 \r
903 \r
904 Internet-draft February 2009\r
905 \r
906 \r
907 as support for internationalized usernames and passwords, support\r
908 for passing of authorization identity, support for channel bindings.\r
909 It also doesn't support server authentication. For a more complete\r
910 list of problems with CRAM-MD5 see [CRAM-HISTORIC].\r
911 \r
912 The PLAIN [PLAIN] SASL mechanism allows a malicious server or\r
913 eavesdropper to impersonate the authenticating user to any other\r
914 server for which the user has the same password. It also sends the\r
915 password in the clear over the network, unless TLS is used. Server\r
916 authentication is not supported.\r
917 \r
918 \r
919 Appendix B: Design Motivations\r
920 \r
921 The following design goals shaped this document. Note that some of\r
922 the goals have changed since the initial version of the document.\r
923 \r
924 The SASL mechanism has all modern SASL features: support for\r
925 internationalized usernames and passwords, support for passing of\r
926 authorization identity, support for channel bindings.\r
927 \r
928 Both the client and server can be authenticated by the protocol.\r
929 \r
930 The authentication information stored in the authentication\r
931 database is not sufficient by itself to impersonate the client.\r
932 \r
933 <<The server does not gain the ability to impersonate the client\r
934 to other servers (with an exception for server-authorized\r
935 proxies).>>\r
936 \r
937 The mechanism is extensible, but [hopefully] not overengineered in\r
938 this respect.\r
939 \r
940 Easier to implement than DIGEST-MD5 in both clients and servers.\r
941 \r
942 \r
943 Appendix C: SCRAM Examples\r
944 \r
945 <<To be written.>>\r
946 \r
947 \r
948 \r
949 \r
950 \r
951 \r
952 \r
953 \r
954 \r
955 \r
956 \r
957 \r
958 Menon-Sen & Co Expires August 2009 FF[Page 16]\r
959 \r
960 \r
961 \r
962 \r
963 \r
964 Internet-draft February 2009\r
965 \r
966 \r
967 (RFC Editor: Please delete everything after this point)\r
968 \r
969 \r
970 Open Issues\r
971 \r
972 - The appendices need to be written.\r
973 \r
974 - Should the server send a base64-encoded ServerSignature for the\r
975 value of the "v" attribute, or should it compute a ServerProof the\r
976 way the client computes a ClientProof?\r
977 \r
978 \r
979 Changes since -07\r
980 \r
981 Updated References.\r
982 \r
983 Clarified purpose of the m= attribute.\r
984 \r
985 Fixed a problem with authentication/authorization identity's ABNF\r
986 not allowing for some characters.\r
987 \r
988 Updated ABNF for nonce to show client-generated and server-generated\r
989 parts.\r
990 \r
991 Only register SCRAM-HMAC-SHA-1 with IANA and require explicit\r
992 registrations of all other SCRAM-HMAC- mechanisms.\r
993 \r
994 \r
995 \r
996 Changes since -06\r
997 \r
998 Removed hash negotiation from SCRAM and turned it into a family of\r
999 SASL mechanisms.\r
1000 \r
1001 Start using "Hash Function Textual Names" IANA registry for SCRAM\r
1002 mechanism naming.\r
1003 \r
1004 Fixed definition of Hi(str, salt) to be consistent with [RFC2898].\r
1005 \r
1006 Clarified extensibility of SCRAM: added m= attribute (for future\r
1007 mandatory extensions) and specified that all unrecognized\r
1008 attributes must be ignored.\r
1009 \r
1010 \r
1011 \r
1012 Changes since -05\r
1013 \r
1014 Changed the mandatory to implement hash algorithm to SHA-1 (as per\r
1015 \r
1016 \r
1017 \r
1018 Menon-Sen & Co Expires August 2009 FF[Page 17]\r
1019 \r
1020 \r
1021 \r
1022 \r
1023 \r
1024 Internet-draft February 2009\r
1025 \r
1026 \r
1027 WG consensus).\r
1028 \r
1029 Added text about use of SASLPrep for username\r
1030 canonicalization/validation.\r
1031 \r
1032 Clarified that authorization identity is canonicalized/verified\r
1033 according to SASL protocol profile.\r
1034 \r
1035 Clarified that iteration count is per-user.\r
1036 \r
1037 Clarified how clients select the authentication function.\r
1038 \r
1039 Added IANA registration for the new mechanism.\r
1040 \r
1041 Added missing normative references (UTF-8, SASLPrep).\r
1042 \r
1043 Various editorial changes based on comments from Hallvard B\r
1044 Furuseth, Nico William and Simon Josefsson.\r
1045 \r
1046 \r
1047 \r
1048 Changes since -04\r
1049 \r
1050 - Update Base64 and Security Glossary references.\r
1051 \r
1052 - Add Formal Syntax section.\r
1053 \r
1054 - Don't bother with "v=".\r
1055 \r
1056 - Make MD5 mandatory to implement. Suggest i=128.\r
1057 \r
1058 \r
1059 \r
1060 Changes since -03\r
1061 \r
1062 - Seven years have passed, in which it became clear that DIGEST-MD5\r
1063 suffered from unacceptably bad interoperability, so SCRAM-MD5 is\r
1064 now back from the dead.\r
1065 \r
1066 - Be hash agnostic, so MD5 can be replaced more easily.\r
1067 \r
1068 - General simplification.\r
1069 \r
1070 \r
1071 \r
1072 \r
1073 \r
1074 \r
1075 \r
1076 \r
1077 \r
1078 Menon-Sen & Co Expires August 2009 FF[Page 18]\r
1079 \r
1080 \r