idnits 2.17.1 draft-newman-auth-scram-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (December 2007) is 5976 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: 'RFC4422' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC1939' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC2195' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC2202' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC2289' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'DIGEST-MD5' is defined on line 547, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Abhijit Menon-Sen 3 Internet-Draft Oryx Mail Systems GmbH 4 Intended Status: Proposed Standard Chris Newman 5 Expires: May 1, 2008 Sun Microsystems 6 December 2007 8 Salted Challenge Response Authentication Mechanism (SCRAM) 9 draft-newman-auth-scram-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 30 Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft expires in May 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The secure authentication mechanism most widely deployed and used by 42 Internet application protocols is the transmission of clear-text 43 passwords over a channel protected by Transport Layer Security 44 (TLS). There are some significant security concerns with that 45 mechanism, which could be addressed by the use of a challenge 47 Internet-draft December 2007 49 response authentication mechanism protected by TLS. Unfortunately, 50 the challenge response mechanisms presently on the standards track 51 all fail to meet requirements necessary for widespread deployment, 52 and have had success only in limited use. 54 This specification describes the Salted Challenge Response 55 Authentication Mechanism (SCRAM), which addresses the security 56 concerns and meets the deployability requirements. When used in 57 combination with TLS or an equivalent security layer, this mechanism 58 could improve the status-quo for application protocol authentication 59 and provide a suitable choice for a mandatory-to-implement mechanism 60 for future application protocol standards. 62 1. Conventions Used in This Document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 Formal syntax is defined by [RFC4234] including the core rules 69 defined in Appendix B of [RFC4234]. 71 Example lines prefaced by "C:" are sent by the client and ones 72 prefaced by "S:" by the server. If a single "C:" or "S:" label 73 applies to multiple lines, then the line breaks between those lines 74 are for editorial clarity only, and are not part of the actual 75 protocol exchange. 77 1.1. Terminology 79 This document uses several terms defined in [RFC4949] ("Internet 80 Security Glossary") including the following: authentication, 81 authentication exchange, authentication information, brute force, 82 challenge-response, cryptographic hash function, dictionary attack, 83 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 84 one-way encryption function, password, replay attack and salt. 85 Readers not familiar with these terms should use that glossary as a 86 reference. 88 Some clarifications and additional definitions follow: 90 - Authentication information: Information used to verify an identity 91 claimed by a SCRAM client. The authentication information for a 92 SCRAM identity consists of salt and the "StoredKey" and 93 "ServerKey" (as defined in the algorithm overview) for each 94 supported cryptographic hash function. 96 Internet-draft December 2007 98 - Authentication database: The database used to look up the 99 authentication information associated with a particular identity. 100 For application protocols, LDAPv3 (see [RFC4510]) is frequently 101 used as the authentication database. For network-level protocols 102 such as PPP or 802.11x, the use of RADIUS is more common. 104 - Base64: An encoding mechanism defined in [RFC4648] which converts 105 an octet string input to a textual output string which can be 106 easily displayed to a human. The use of base64 in SCRAM is 107 restricted to the canonical form with no whitespace. 109 - Octet: An 8-bit byte. 111 - Octet string: A sequence of 8-bit bytes. 113 - Salt: A random octet string that is combined with a password 114 before applying a one-way encryption function. This value is used 115 to protect passwords that are stored in an authentication 116 database. 118 1.2. Notation 120 The pseudocode description of the algorithm uses the following 121 notations: 123 - ":=": The variable on the left hand side represents the octet 124 string resulting from the expression on the right hand side. 126 - "+": Octet string concatenation. 128 - "[ ]": A portion of an expression enclosed in "[" and "]" may not 129 be included in the result under some circumstances. See the 130 associated text for a description of those circumstances. 132 - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 133 [RFC2104]) using the octet string represented by "key" as the key 134 and the octet string "str" as the input string. The size of the 135 result is the hash result size for the hash function in use. For 136 example, it is 20 octets for SHA-1 (see [RFC3174]). 138 - H(str): Apply the cryptographic hash function to the octet string 139 "str", producing an octet string as a result. The size of the 140 result depends on the hash result size for the hash function in 141 use. 143 - Hi(str): Apply the cryptographic hash function to the octet string 144 "str", then repeat the application on the output string for a 146 Internet-draft December 2007 148 number of iterations equal to the integer i minus 1. 150 - XOR: Apply the exclusive-or operation to combine the octet string 151 on the left of this operator with the octet string on the right of 152 this operator. The length of the output and each of the two inputs 153 will be the same for this use. 155 2. Introduction 157 This specification describes the Salted Challenge Response 158 Authentication Mechanism (SCRAM) which addresses the requirements 159 necessary to deploy a challenge-response mechanism more widely than 160 past attempts. When used in combination with Transport Layer 161 Security (TLS, see [RFC4346]) or an equivalent security layer, this 162 mechanism could improve the status-quo for application protocol 163 authentication and provide a suitable choice for a mandatory-to- 164 implement mechanism for future application protocol standards. 166 For simplicity, this mechanism does not presently include 167 negotiation of a security layer. It is intended to be used with an 168 external security layer such as that provided by TLS or SSH. 170 SCRAM provides the following protocol features: 172 - The authentication information stored in the authentication 173 database is not sufficient by itself to impersonate the client. 174 The information is salted to prevent a pre-stored dictionary 175 attack if the database is stolen. 177 - The server does not gain the ability to impersonate the client to 178 other servers (with an exception for server-authorized proxies). 180 - The mechanism permits the use of a server-authorized proxy without 181 requiring that proxy to have super-user rights with the back-end 182 server. 184 - A standard attribute is defined to enable storage of the 185 authentication information in LDAPv3 (see [RFC4510]). 187 - Bindings to several authentication frameworks are provided so the 188 mechanism is not limited to a small subset of protocols. 190 - Both the client and server can be authenticated by the protocol. 192 - The cryptographic hash function used to authenticate can be 193 upgraded gracefully without breaking backwards compatibility or 194 risking downgrade attacks. 196 Internet-draft December 2007 198 For an in-depth discussion of why other challenge response 199 mechanisms are not considered sufficient, see appendix A. For more 200 information about the motivations behind the design of this 201 mechanism, see appendix B. 203 Comments regarding this draft may be sent either to the ietf- 204 sasl@imc.org mailing list or to the authors. 206 3. SCRAM Algorithm Overview 208 To begin with, the client is in possession of a username and 209 password. It sends the username to the server, which retrieves the 210 corresponding authentication information, i.e. a salt, StoredKey, 211 and ServerKey. The server sends the salt and an iteration count to 212 the client, which then computes the following values and sends a 213 ClientProof to the server: 215 SaltedPassword := Hi(HMAC(password, salt)) 216 ClientKey := H(SaltedPassword) 217 StoredKey := H(ClientKey) 218 AuthMessage := client-first-message + "," + 219 server-first-message + "," + 220 final-client-message-without-proof 221 ClientSignature := HMAC(StoredKey, AuthMessage) 222 ClientProof := ClientKey XOR ClientSignature 223 ServerKey := HMAC(SaltedPassword, salt) 224 ServerSignature := HMAC(ServerKey, AuthMessage) 226 The server authenticates the client by computing the 227 ClientSignature, exclusive-ORing that with the ClientProof to 228 recover the ClientKey and verifying the correctness of the ClientKey 229 by applying the hash function and comparing the result to the 230 StoredKey. If the ClientKey is correct, this proves that the client 231 has access to the user's password. 233 Similarly, the client authenticates the server by computing the 234 ServerSignature and comparing it to the value sent by the server. 235 If the two are equal, it proves that the server had access to the 236 user's SaltedPassword. 238 The AuthMessage is computed by concatenating messages from the 239 authentication exchange. The format of these messages is defined in 240 the Formal Syntax section. 242 Internet-draft December 2007 244 4. SCRAM Authentication Exchange 246 SCRAM is a text protocol where the client and server exchange 247 messages containing one or more attribute-value pairs separated by 248 commas. Each attribute has a one-letter name. The messages and their 249 attributes are described in section 4.1, and defined in the Formal 250 Syntax section. 252 This is a simple example of a SCRAM authentication exchange: 254 C: n=Chris Newman,h=md5,r=ClientNonce 255 S: r=ClientNonceServerNonce,h=md5,s=PxR/wv+epq,i=128 256 C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 257 S: v=WxPv/siO5l+qxN4 259 First, the client sends a message containing the username, a list of 260 the hash functions it supports, and a random, unique nonce. In 261 response, the server sends its list of supported hash functions, an 262 iteration count i, the user's salt, and appends its own nonce to the 263 client-specified one. The client then responds with the same nonce 264 and a ClientProof computed as explained earlier. The server verifies 265 the proof and responds with a ServerSignature, concluding the 266 authentication exchange. 268 4.1 SCRAM attributes 270 This section describes the permissible attributes, their use, and 271 the format of their values. 273 - a: This optional attribute specifies an authorization identity. A 274 client may include it in its first message to the server if it 275 wants to authenticate as one user, but subsequently act as a 276 different user. This is typically used by an administrator to 277 perform some management task on behalf of another user, or by a 278 proxy in some situations (see appendix A for more details). 280 If this attribute is omitted (as it normally would be), or 281 specified with an empty value, the authorization identity is 282 assumed to be the same as the username specified with the 283 (required) "n" attribute. 285 The server always authenticates the user specified by the "n" 286 attribute. If the "a" attribute specifies a different user, the 287 server associates that identity with the connection after 288 successful authentication and authorization checks. 290 The syntax of this field is the same as that of the "n" field with 292 Internet-draft December 2007 294 respect to quoting of '=' and ','. 296 - n: This attribute specifies the name of the user whose password is 297 used for authentication. A client must include it in its first 298 message to the server. If the "a" attribute is not specified 299 (which would normally be the case), this username is also the 300 identity which will be associated with the connection subsequent 301 to authentication and authorization. 303 The characters ',' or '=' in usernames are sent as '=2C' and '=3D' 304 respectively. If the server receives a username which contains '=' 305 not followed by either '2C' or '3D', then the server MUST fail the 306 authentication. 308 - h: This attribute is a colon-separated list of supported hash 309 function names, as defined in the IANA "Hash Function Textual 310 Names" registry. 312 - r: This attribute specifies a sequence of random printable 313 characters excluding ',' which forms the nonce used as input to 314 the hash function. No quoting is applied to this string (unless 315 the binding of SCRAM to a particular protocol states otherwise). 316 As described earlier, the client supplies an initial value in its 317 first message, and the server augments that value with its own 318 nonce in its first response. It is important that this be value 319 different for each authentication. The client must verify that the 320 initial part of the nonce used in subsequent messages is the same 321 as the nonce it initially specified. 323 - c: This optional attribute specifies base64-encoded channel- 324 binding data. It may be sent by either the client or the server. 325 If specified, the authentication MUST fail unless the value is 326 successfully verified. Whether this attribute is included, and 327 the meaning and contents of the channel-binding data depends on 328 the external security layer in use. This is necessary to detect a 329 man-in-the-middle attack on the security layer. 331 - s: This attribute specifies the base64-encoded salt used by the 332 server for this user. It is sent by the server in its first 333 message to the client. 335 - i: This attribute specifies an iteration count for the selected 336 hash function, and must be sent by the server along with the 337 user's salt. 339 - p: This attribute specifies a base64-encoded ClientProof. The 340 client computes this value as described in the overview and sends 341 it to the server. 343 Internet-draft December 2007 345 - v: This attribute specifies a base64-encoded ServerSignature. It 346 is sent by the server in its final message, and may be used by the 347 client to verify that the server has access to the user's 348 authentication information. This value is computed as explained in 349 the overview. 351 5. Hash functions 353 SCRAM can use hash functions defined by the IANA "Hash Function 354 Textual Names" registry. 356 For interoperability, all SCRAM clients and servers MUST implement 357 the MD5 hash function as defined in [RFC1321]. 359 Servers SHOULD announce a hash iteration-count of at least 128. 361 6. Formal Syntax 363 The following syntax specification uses the Augmented Backus-Naur 364 Form (ABNF) notation as specified in [RFC4234]. 366 generic-message = attr-val *("," attr-val) 368 attr-val = ALPHA "=" value 370 value = *(value-char) 372 value-safe-char = %20-2B / %2D-3C / %3E-7E / 373 UTF8-2 / UTF8-2 / UTF-3 / UTF8-4 374 ;; UTF8-char except CTL, "=", and ",". 376 value-char = value-safe-char / "=" 378 base64-char = ALPHA / DIGIT / "/" / "+" 380 base64-4 = 4*4(base64-char) 382 base64-3 = 3*3(base64-char) "=" 384 base64-2 = 2*2(base64-char) "==" 386 base64 = *(base64-4) [base64-3 / base64-2] 388 saslname = 1*(value-safe-char / "=2C" / "=3D") 389 ;; Conforms to 390 ;; Usernames are prepared using SASLPrep. 392 Internet-draft December 2007 394 authzid = "a=" saslname 396 username = "n=" saslname 398 channel-binding = "c=" base64 400 proof = "p=" base64 402 nonce = "r=" value [value] 403 ;; Second part provided by server. 405 salt = "s=" base64 407 verifier = "v=" base64 409 hash-list = "h=" hash-name *(":" hash-name) 411 hash-name = value 412 ;; Hash Function Textual Name, from 413 ;; http://www.iana.org/assignments/hash- 414 function-text-names 416 iteration-count = "i=" 1*DIGIT 418 client-first-message = 419 [authzid ","] username "," hash-list "," nonce 421 server-first-message = 422 nonce "," hash-list "," salt "," iteration-count 424 client-final-message-without-proof = 425 nonce "," channel-binding 427 client-final-message = 428 client-final-message-without-proof "," proof 430 server-final-message = 431 verifier 433 7. Security Considerations 435 If the authentication exchange is performed without a strong 436 security layer, then a passive eavesdropper can gain sufficient 437 information to mount an offline dictionary or brute-force attack 438 which can be used to recover the user's password. The amount of time 439 necessary for this attack depends on the cryptographic hash function 440 selected, the strength of the password and the iteration count 442 Internet-draft December 2007 444 supplied by the server. An external security layer with strong 445 encryption will prevent this attack. 447 If the external security layer used to protect the SCRAM exchange 448 uses an anonymous key exchange, then the SCRAM channel binding 449 mechanism can be used to detect a man-in-the-middle attack on the 450 security layer and cause the authentication to fail as a result. 451 However, the man-in-the-middle attacker will have gained sufficient 452 information to mount an offline dictionary or brute-force attack. 453 For this reason, SCRAM includes the ability to increase the 454 iteration count over time. 456 If the authentication information is stolen from the authentication 457 database, then an offline dictionary or brute-force attack can be 458 used to recover the user's password. The use of salt mitigates this 459 attack somewhat by requiring a separate attack on each password. 460 Authentication mechanisms which protect against this attack are 461 available (e.g., the EKE class of mechanisms), but the patent 462 situation is presently unclear. 464 If an attacker obtains the authentication information from the 465 authentication repository and either eavesdrops on one 466 authentication exchange or impersonates a server, the attacker gains 467 the ability to impersonate that user to all servers providing SCRAM 468 access using the same password and salt. For this reason, it is 469 important to use randomly-generated salt values. 471 If the server detects (from the value of the client-specified "h" 472 attribute) that both endpoints support a stronger hash function that 473 the one the client actually chooses to use, then it SHOULD treat 474 this as a downgrade attack and reject the authentication attempt. 476 8. IANA considerations 478 (Hash function names registry, SASL mechanism registration.) 480 9. Acknowedgements 482 The authors would like to thank Alexey Melnikov and Dave Cridland 483 for their contributions to this document. 485 Internet-draft December 2007 487 10. Normative References 489 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 490 Encodings", RFC 4648, SJD, October 2006. 492 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 493 April 1992. 495 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 496 Message Authentication", IBM, February 1997. 498 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 499 Requirement Levels", RFC 2119, Harvard University, March 500 1997. 502 [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 503 3174, Motorola, September 2001 505 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 506 Specifications: ABNF", RFC 4234, Brandenburg 507 Internetworking, Demon Internet Ltd, October 2005. 509 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 510 Protocol, Version 1.1", RFC 4346, Brandenburg 511 Internetworking, April 2006. 513 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 514 Layer (SASL)", RFC 4422, Isode Limited, June 2006. 516 11. Informative References 518 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", RFC 519 1939, Carnegie Mellon, May 1996. 521 [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 522 for Simple Challenge/Response", RFC 2195, MCI, September 523 1997. 525 [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 526 RFC 2202, IBM, September 1997 528 [RFC2289] Haller, Metz, Nesser, Straw, "A One-Time Password 529 System", RFC 2289, STD0061, February 1998. 531 [RFC4949] Shirey, "Internet Security Glossary, Version 2", RFC 532 4949, FYI 0036, August 2007. 534 Internet-draft December 2007 536 [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for 537 Security", RFC 4086, BCP 0106, Motorola Laboratories, 538 June 2005. 540 [RFC4120] Neuman, Yo, Hartman, Raebun, "The Kerberos Network 541 Authentication Service (V5)", RFC 4120, USC-ISI, July 542 2005. 544 [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP): 545 Technical Specification Road Map", RFC 4510, June 2006. 547 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL 548 Mechanism", draft-ietf-sasl-rfc2831bis-12.txt, Isode 549 Ltd., March 2007 551 12. Authors' Addresses 553 Abhijit Menon-Sen 554 Oryx Mail Systems GmbH 556 Email: ams@oryx.com 558 Chris Newman 559 Sun Microsystems 560 1050 Lakes Drive 561 West Covina, CA 91790 562 USA 564 Email: chris.newman@sun.com 566 Appendix A: Other Authentication Mechanisms 568 The DIGEST-MD5 mechanism has proved to be too complex to implement 569 and test, and thus has poor interoperability. The security layer is 570 often not implemented, and almost never used; everyone uses TLS 571 instead. 573 The PLAIN SASL mechanism allows a malicious server or eavesdropper 574 to impersonate the authenticating user to any other server for which 575 the user has the same password. It also sends the password in the 576 clear over the network, unless TLS is used. Server authentication is 577 not supported. 579 (To be completed.) 581 Internet-draft December 2007 583 Appendix B: Design Motivations 585 (To be written.) 587 Appendix C: SCRAM Examples 589 (To be written.) 591 Appendix D: SCRAM Interoperability Testing 593 (To be written.) 595 Intellectual Property Statement 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed 599 to pertain to the implementation or use of the technology described 600 in this document or the extent to which any license under such 601 rights might or might not be available; nor does it represent that 602 it has made any independent effort to identify any such rights. 603 Information on the procedures with respect to rights in RFC 604 documents can be found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use 609 of such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository 611 at http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at ietf- 617 ipr@ietf.org. 619 Full Copyright Statement 621 Copyright (C) The IETF Trust (2007). This document is subject to the 622 rights, licenses and restrictions contained in BCP 78, and except as 623 set forth therein, the authors retain all their rights. 625 This document and the information contained herein are provided on 626 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 628 Internet-draft December 2007 630 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 631 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 632 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 633 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 634 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 635 FOR A PARTICULAR PURPOSE. 637 Acknowledgment 639 Funding for the RFC Editor function is currently provided by the 640 Internet Society. 642 Internet-draft December 2007 644 (RFC Editor: Please delete everything after this point) 646 Open Issues 648 - The appendices need to be written. 650 - Should the server send a base64-encoded ServerSignature for the 651 value of the "v" attribute, or should it compute a ServerProof the 652 way the client computes a ClientProof? 654 - What about this LDAP attribute to store authentication 655 information? 657 - It is entirely unclear to me how best to handle channel bindings. 658 Should the channel binding data be sent directly at all? 660 - It's not clear from the document that the hash function to use for 661 a particular authentication exchange is selected by the client 662 before the exchange begins. 664 - Should the title include the acronym SASL to help the greppers? 666 Changes since -04 668 - Update Base64 and Security Glossary references. 670 - Add Formal Syntax section. 672 - Don't bother with "v=". 674 - Make MD5 mandatory to implement. Suggest i=128. 676 Changes since -03 678 - Seven years have passed, in which it became clear that DIGEST-MD5 679 suffered from unacceptably bad interoperability, so SCRAM-MD5 is 680 now back from the dead. 682 - Be hash agnostic, so MD5 can be replaced more easily. 684 - General simplification.