idnits 2.17.1 draft-newman-auth-scram-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 664. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 (July 13, 2008) is 5760 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: 'IANA-SASL' is mentioned on line 512, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 519, but not defined == Unused Reference: 'RFC4422' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC1939' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC2195' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC2202' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC2289' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'DIGEST-MD5' is defined on line 596, but no explicit reference was found in the text ** 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) ** Obsolete normative reference: RFC 4013 (ref. 'SASLPrep') (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 7 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: December 13, 2008 Sun Microsystems 6 July 13, 2008 8 Salted Challenge Response Authentication Mechanism (SCRAM) 10 draft-newman-auth-scram-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 31 Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft expires in December 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The secure authentication mechanism most widely deployed and used by 43 Internet application protocols is the transmission of clear-text 44 passwords over a channel protected by Transport Layer Security 45 (TLS). There are some significant security concerns with that 46 mechanism, which could be addressed by the use of a challenge 47 response authentication mechanism protected by TLS. Unfortunately, 48 the challenge response mechanisms presently on the standards track 49 all fail to meet requirements necessary for widespread deployment, 50 and have had success only in limited use. 52 This specification describes the Salted Challenge Response 53 Authentication Mechanism (SCRAM), which addresses the security 54 concerns and meets the deployability requirements. When used in 55 combination with TLS or an equivalent security layer, this mechanism 56 could improve the status-quo for application protocol authentication 57 and provide a suitable choice for a mandatory-to-implement mechanism 58 for future application protocol standards. 60 1. Conventions Used in This Document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 Formal syntax is defined by [RFC4234] including the core rules 67 defined in Appendix B of [RFC4234]. 69 Example lines prefaced by "C:" are sent by the client and ones 70 prefaced by "S:" by the server. If a single "C:" or "S:" label 71 applies to multiple lines, then the line breaks between those lines 72 are for editorial clarity only, and are not part of the actual 73 protocol exchange. 75 1.1. Terminology 77 This document uses several terms defined in [RFC4949] ("Internet 78 Security Glossary") including the following: authentication, 79 authentication exchange, authentication information, brute force, 80 challenge-response, cryptographic hash function, dictionary attack, 81 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 82 one-way encryption function, password, replay attack and salt. 83 Readers not familiar with these terms should use that glossary as a 84 reference. 86 Some clarifications and additional definitions follow: 88 - Authentication information: Information used to verify an identity 89 claimed by a SCRAM client. The authentication information for a 90 SCRAM identity consists of salt, iteration count, the "StoredKey" 91 and "ServerKey" (as defined in the algorithm overview) for each 92 supported cryptographic hash function. 94 - Authentication database: The database used to look up the 95 authentication information associated with a particular identity. 96 For application protocols, LDAPv3 (see [RFC4510]) is frequently 97 used as the authentication database. For network-level protocols 98 such as PPP or 802.11x, the use of RADIUS is more common. 100 - Base64: An encoding mechanism defined in [RFC4648] which converts 101 an octet string input to a textual output string which can be 102 easily displayed to a human. The use of base64 in SCRAM is 103 restricted to the canonical form with no whitespace. 105 - Octet: An 8-bit byte. 107 - Octet string: A sequence of 8-bit bytes. 109 - Salt: A random octet string that is combined with a password 110 before applying a one-way encryption function. This value is used 111 to protect passwords that are stored in an authentication 112 database. 114 1.2. Notation 116 The pseudocode description of the algorithm uses the following 117 notations: 119 - ":=": The variable on the left hand side represents the octet 120 string resulting from the expression on the right hand side. 122 - "+": Octet string concatenation. 124 - "[ ]": A portion of an expression enclosed in "[" and "]" may not 125 be included in the result under some circumstances. See the 126 associated text for a description of those circumstances. 128 - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 129 [RFC2104]) using the octet string represented by "key" as the key 130 and the octet string "str" as the input string. The size of the 131 result is the hash result size for the hash function in use. For 132 example, it is 20 octets for SHA-1 (see [RFC3174]). 134 - H(str): Apply the cryptographic hash function to the octet string 135 "str", producing an octet string as a result. The size of the 136 result depends on the hash result size for the hash function in 137 use. 139 - XOR: Apply the exclusive-or operation to combine the octet string 140 on the left of this operator with the octet string on the right of 141 this operator. The length of the output and each of the two inputs 142 will be the same for this use. 144 - Hi(str, salt): 146 U0 := HMAC(str, salt) 147 U1 := HMAC(str, U0) 148 U2 := HMAC(str, U1) 149 ... 150 Ui-1 := HMAC(str, Ui-2) 151 Ui := HMAC(str, Ui-1) 153 Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui 154 where "i" is the iteration counter. <> 158 2. Introduction 160 This specification describes the Salted Challenge Response 161 Authentication Mechanism (SCRAM) which addresses the requirements 162 necessary to deploy a challenge-response mechanism more widely than 163 past attempts. When used in combination with Transport Layer 164 Security (TLS, see [RFC4346]) or an equivalent security layer, this 165 mechanism could improve the status-quo for application protocol 166 authentication and provide a suitable choice for a mandatory-to- 167 implement mechanism for future application protocol standards. 169 For simplicity, this mechanism does not presently include 170 negotiation of a security layer. It is intended to be used with an 171 external security layer such as that provided by TLS or SSH. 173 SCRAM provides the following protocol features: 175 - The authentication information stored in the authentication 176 database is not sufficient by itself to impersonate the client. 177 The information is salted to prevent a pre-stored dictionary 178 attack if the database is stolen. 180 - The server does not gain the ability to impersonate the client to 181 other servers (with an exception for server-authorized proxies). 183 - The mechanism permits the use of a server-authorized proxy without 184 requiring that proxy to have super-user rights with the back-end 185 server. 187 - A standard attribute is defined to enable storage of the 188 authentication information in LDAPv3 (see [RFC4510]). 190 - Bindings to several authentication frameworks are provided so the 191 mechanism is not limited to a small subset of protocols. <> 194 - Both the client and server can be authenticated by the protocol. 196 - The cryptographic hash function used to authenticate can be 197 upgraded gracefully without breaking backwards compatibility or 198 risking downgrade attacks. <> 201 For an in-depth discussion of why other challenge response 202 mechanisms are not considered sufficient, see appendix A. For more 203 information about the motivations behind the design of this 204 mechanism, see appendix B. 206 Comments regarding this draft may be sent either to the ietf- 207 sasl@imc.org mailing list or to the authors. 209 3. SCRAM Algorithm Overview 211 To begin with, the client is in possession of a username and 212 password. It sends the username to the server, which retrieves the 213 corresponding authentication information, i.e. a salt, StoredKey, 214 and ServerKey and the iteration count. The server sends the salt and 215 an iteration count to the client, which then computes the following 216 values and sends a ClientProof to the server: 218 SaltedPassword := Hi(password, salt) 219 ClientKey := H(SaltedPassword) 220 StoredKey := H(ClientKey) 221 AuthMessage := client-first-message + "," + 222 server-first-message + "," + 223 final-client-message-without-proof 224 ClientSignature := HMAC(StoredKey, AuthMessage) 225 ClientProof := ClientKey XOR ClientSignature 226 ServerKey := HMAC(SaltedPassword, salt) 227 ServerSignature := HMAC(ServerKey, AuthMessage) 229 The server authenticates the client by computing the 230 ClientSignature, exclusive-ORing that with the ClientProof to 231 recover the ClientKey and verifying the correctness of the ClientKey 232 by applying the hash function and comparing the result to the 233 StoredKey. If the ClientKey is correct, this proves that the client 234 has access to the user's password. 236 Similarly, the client authenticates the server by computing the 237 ServerSignature and comparing it to the value sent by the server. 238 If the two are equal, it proves that the server had access to the 239 user's SaltedPassword. 241 The AuthMessage is computed by concatenating messages from the 242 authentication exchange. The format of these messages is defined in 243 the Formal Syntax section. 245 4. SCRAM Authentication Exchange 247 SCRAM is a text protocol where the client and server exchange 248 messages containing one or more attribute-value pairs separated by 249 commas. Each attribute has a one-letter name. The messages and their 250 attributes are described in section 4.1, and defined in the Formal 251 Syntax section. 253 This is a simple example of a SCRAM authentication exchange: 255 C: n=Chris Newman,h=sha1,r=ClientNonce 256 S: r=ClientNonceServerNonce,h=sha1,s=PxR/wv+epq,i=128 257 C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 258 S: v=WxPv/siO5l+qxN4 260 First, the client sends a message containing the username, an 261 optional authorization identity, a list of the hash functions it 262 supports, and a random, unique nonce. In response, the server sends 263 its list of supported hash functions, an iteration count i, the 264 user's salt, and appends its own nonce to the client-specified one. 265 The client then picks a hash function common to both the client and 266 the server (*), and then it responds with the same nonce and a 267 ClientProof computed using the selected hash function as explained 268 earlier. The server verifies the nonce and the proof, verifies that 269 the authorization identity (if supplied by the client in the initial 270 message) is authorized to act as the authentication identity, and, 271 finally, it responds with a ServerSignature, concluding the 272 authentication exchange. The client then authenticates the server by 273 computing the ServerSignature and comparing it to the value sent by 274 the server. If the two are different, the client MUST consider the 275 authentication exchange to be unsuccessful and it might have to drop 276 the connection. 278 (*) The client might retry SCRAM authentication using different hash 279 functions. It MUST start with the strongest hash function (common to 280 both the client and the server) it supports. 282 4.1 SCRAM attributes 284 This section describes the permissible attributes, their use, and 285 the format of their values. 287 - a: This optional attribute specifies an authorization identity. A 288 client may include it in its first message to the server if it 289 wants to authenticate as one user, but subsequently act as a 290 different user. This is typically used by an administrator to 291 perform some management task on behalf of another user, or by a 292 proxy in some situations (see appendix A for more details). 294 Upon the receipt of this value the server verifies its correctness 295 according to the used SASL protocol profile. Failed verification 296 results in failed authentication exchange. 298 If this attribute is omitted (as it normally would be), or 299 specified with an empty value, the authorization identity is 300 assumed to be derived from the username specified with the 301 (required) "n" attribute. 303 The server always authenticates the user specified by the "n" 304 attribute. If the "a" attribute specifies a different user, the 305 server associates that identity with the connection after 306 successful authentication and authorization checks. 308 The syntax of this field is the same as that of the "n" field with 309 respect to quoting of '=' and ','. 311 - n: This attribute specifies the name of the user whose password is 312 used for authentication. A client must include it in its first 313 message to the server. If the "a" attribute is not specified 314 (which would normally be the case), this username is also the 315 identity which will be associated with the connection subsequent 316 to authentication and authorization. 318 Before sending the username to the server, the client MUST prepare 319 the username using the "SASLPrep" profile [SASLPrep] of the 320 "stringprep" algorithm [RFC3454]. If the preparation of the 321 username fails or results in an empty string, the client SHOULD 322 abort the authentication exchange (*). 324 (*) An interactive client can request a repeated entry of username 325 value. 327 Upon receipt of the username by the server, the server SHOULD 328 prepare it using the "SASLPrep" profile [SASLPrep] of the 329 "stringprep" algorithm [RFC3454]. If the preparation of the 330 username fails or results in an empty string, the server SHOULD 331 abort the authentication exchange. 333 The characters ',' or '=' in usernames are sent as '=2C' and '=3D' 334 respectively. If the server receives a username which contains '=' 335 not followed by either '2C' or '3D', then the server MUST fail the 336 authentication. 338 - h: This attribute is a colon-separated list of supported hash 339 function names, as defined in the IANA "Hash Function Textual 340 Names" registry. 342 - r: This attribute specifies a sequence of random printable 343 characters excluding ',' which forms the nonce used as input to 344 the hash function. No quoting is applied to this string (unless 345 the binding of SCRAM to a particular protocol states otherwise). 346 As described earlier, the client supplies an initial value in its 347 first message, and the server augments that value with its own 348 nonce in its first response. It is important that this be value 349 different for each authentication. The client MUST verify that the 350 initial part of the nonce used in subsequent messages is the same 351 as the nonce it initially specified. The server MUST verify that 352 the nonce sent by the client in the second message is the same as 353 the one sent by the server in its first message. 355 - c: This optional attribute specifies base64-encoded channel- 356 binding data. It may be sent by either the client or the server. 357 If specified, the authentication MUST fail unless the value is 358 successfully verified. Whether this attribute is included, and 359 the meaning and contents of the channel-binding data depends on 360 the external security layer in use. This is necessary to detect a 361 man-in-the-middle attack on the security layer. 363 - s: This attribute specifies the base64-encoded salt used by the 364 server for this user. It is sent by the server in its first 365 message to the client. 367 - i: This attribute specifies an iteration count for the selected 368 hash function, and must be sent by the server along with the 369 user's salt. 371 - p: This attribute specifies a base64-encoded ClientProof. The 372 client computes this value as described in the overview and sends 373 it to the server. 375 - v: This attribute specifies a base64-encoded ServerSignature. It 376 is sent by the server in its final message, and may be used by the 377 client to verify that the server has access to the user's 378 authentication information. This value is computed as explained in 379 the overview. 381 5. Hash functions 383 SCRAM can use hash functions defined by the IANA "Hash Function 384 Textual Names" registry. 386 For interoperability, all SCRAM clients and servers MUST implement 387 the SHA-1 hash function as defined in [RFC3174]. 389 Servers SHOULD announce a hash iteration-count of at least 128. 391 6. Formal Syntax 393 The following syntax specification uses the Augmented Backus-Naur 394 Form (ABNF) notation as specified in [RFC4234]. "UTF8-2", "UTF8-3" 395 and "UTF8-4" non-terminal are defined in [UTF-8]. 397 generic-message = attr-val *("," attr-val) 399 attr-val = ALPHA "=" value 401 value = *(value-char) 403 value-safe-char = %20-2B / %2D-3C / %3E-7E / 404 UTF8-2 / UTF-3 / UTF8-4 405 ;; UTF8-char except CTL, "=", and ",". 407 value-char = value-safe-char / "=" 409 base64-char = ALPHA / DIGIT / "/" / "+" 411 base64-4 = 4*4(base64-char) 413 base64-3 = 3*3(base64-char) "=" 415 base64-2 = 2*2(base64-char) "==" 417 base64 = *(base64-4) [base64-3 / base64-2] 419 saslname = 1*(value-safe-char / "=2C" / "=3D") 420 ;; Conforms to 422 authzid = "a=" saslname 423 ;; Protocol specific. 425 username = "n=" saslname 426 ;; Usernames are prepared using SASLPrep. 428 channel-binding = "c=" base64 430 proof = "p=" base64 432 nonce = "r=" value [value] 433 ;; Second part provided by server. 435 salt = "s=" base64 437 verifier = "v=" base64 439 hash-list = "h=" hash-name *(":" hash-name) 441 hash-name = value 442 ;; Hash Function Textual Name, from 443 ;; http://www.iana.org/assignments/hash- 444 function-text-names 446 iteration-count = "i=" 1*DIGIT 448 client-first-message = 449 [authzid ","] username "," hash-list "," nonce 451 server-first-message = 452 nonce "," hash-list "," salt "," iteration-count 454 client-final-message-without-proof = 455 nonce "," channel-binding 457 client-final-message = 458 client-final-message-without-proof "," proof 460 server-final-message = 461 verifier 463 7. Security Considerations 465 If the authentication exchange is performed without a strong 466 security layer, then a passive eavesdropper can gain sufficient 467 information to mount an offline dictionary or brute-force attack 468 which can be used to recover the user's password. The amount of time 469 necessary for this attack depends on the cryptographic hash function 470 selected, the strength of the password and the iteration count 471 supplied by the server. An external security layer with strong 472 encryption will prevent this attack. 474 If the external security layer used to protect the SCRAM exchange 475 uses an anonymous key exchange, then the SCRAM channel binding 476 mechanism can be used to detect a man-in-the-middle attack on the 477 security layer and cause the authentication to fail as a result. 478 However, the man-in-the-middle attacker will have gained sufficient 479 information to mount an offline dictionary or brute-force attack. 480 For this reason, SCRAM includes the ability to increase the 481 iteration count over time. 483 If the authentication information is stolen from the authentication 484 database, then an offline dictionary or brute-force attack can be 485 used to recover the user's password. The use of salt mitigates this 486 attack somewhat by requiring a separate attack on each password. 487 Authentication mechanisms which protect against this attack are 488 available (e.g., the EKE class of mechanisms), but the patent 489 situation is presently unclear. 491 If an attacker obtains the authentication information from the 492 authentication repository and either eavesdrops on one 493 authentication exchange or impersonates a server, the attacker gains 494 the ability to impersonate that user to all servers providing SCRAM 495 access using the same hash function <>, 496 password and salt. For this reason, it is important to use 497 randomly-generated salt values. 499 If the server detects (from the value of the client-specified "h" 500 attribute) that both endpoints support a stronger hash function that 501 the one the client actually chooses to use, then it SHOULD treat 502 this as a downgrade attack and reject the authentication attempt. 504 A hostile server can perform a computational denial-of-service 505 attack on clients by sending a big iteration count value. 507 8. IANA considerations 509 (To be done: Hash function names registry.) 511 IANA is requested to add the following entry to the SASL Mechanism 512 registry [IANA-SASL]: 514 To: iana@iana.org 515 Subject: Registration of a new SASL mechanism SCRAM 517 SASL mechanism name (or prefix for the family): SCRAM 518 Security considerations: Section 7 of [RFCXXXX] 519 Published specification (optional, recommended): [RFCXXXX] 520 Person & email address to contact for further information: 521 IETF SASL WG 522 Intended usage: COMMON 523 Owner/Change controller: IESG 524 Note: 526 9. Acknowedgements 528 The authors would like to thank Alexey Melnikov and Dave Cridland 529 for their contributions to this document. 531 10. Normative References 533 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 534 Encodings", RFC 4648, SJD, October 2006. 536 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 537 10646", STD 63, RFC 3629, November 2003. 539 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 540 Message Authentication", IBM, February 1997. 542 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 543 Requirement Levels", RFC 2119, Harvard University, March 544 1997. 546 [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 547 3174, Motorola, September 2001 549 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 550 Specifications: ABNF", RFC 4234, Brandenburg 551 Internetworking, Demon Internet Ltd, October 2005. 553 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 554 Protocol, Version 1.1", RFC 4346, Brandenburg 555 Internetworking, April 2006. 557 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 558 Layer (SASL)", RFC 4422, Isode Limited, June 2006. 560 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user 561 names and passwords", RFC 4013, February 2005. 563 [RFC3454] Hoffman, P., Blanchet, M., "Preparation of 564 Internationalized Strings ("stringprep")", RFC 3454, 565 December 2002. 567 11. Informative References 569 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", RFC 570 1939, Carnegie Mellon, May 1996. 572 [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 573 for Simple Challenge/Response", RFC 2195, MCI, September 574 1997. 576 [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 577 RFC 2202, IBM, September 1997 579 [RFC2289] Haller, Metz, Nesser, Straw, "A One-Time Password 580 System", RFC 2289, STD0061, February 1998. 582 [RFC4949] Shirey, "Internet Security Glossary, Version 2", RFC 583 4949, FYI 0036, August 2007. 585 [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for 586 Security", RFC 4086, BCP 0106, Motorola Laboratories, 587 June 2005. 589 [RFC4120] Neuman, Yo, Hartman, Raebun, "The Kerberos Network 590 Authentication Service (V5)", RFC 4120, USC-ISI, July 591 2005. 593 [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP): 594 Technical Specification Road Map", RFC 4510, June 2006. 596 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL 597 Mechanism", draft-ietf-sasl-rfc2831bis-12.txt, Isode 598 Ltd., March 2007 600 12. Authors' Addresses 602 Abhijit Menon-Sen 603 Oryx Mail Systems GmbH 605 Email: ams@oryx.com 607 Chris Newman 608 Sun Microsystems 609 1050 Lakes Drive 610 West Covina, CA 91790 611 USA 613 Email: chris.newman@sun.com 615 Appendix A: Other Authentication Mechanisms 617 The DIGEST-MD5 mechanism has proved to be too complex to implement 618 and test, and thus has poor interoperability. The security layer is 619 often not implemented, and almost never used; everyone uses TLS 620 instead. 622 The PLAIN SASL mechanism allows a malicious server or eavesdropper 623 to impersonate the authenticating user to any other server for which 624 the user has the same password. It also sends the password in the 625 clear over the network, unless TLS is used. Server authentication is 626 not supported. 628 (To be completed.) 630 Appendix B: Design Motivations 632 (To be written.) 634 Appendix C: SCRAM Examples 636 (To be written.) 638 Appendix D: SCRAM Interoperability Testing 640 (To be written.) 642 Intellectual Property Statement 644 The IETF takes no position regarding the validity or scope of any 645 Intellectual Property Rights or other rights that might be claimed 646 to pertain to the implementation or use of the technology described 647 in this document or the extent to which any license under such 648 rights might or might not be available; nor does it represent that 649 it has made any independent effort to identify any such rights. 650 Information on the procedures with respect to rights in RFC 651 documents can be found in BCP 78 and BCP 79. 653 Copies of IPR disclosures made to the IETF Secretariat and any 654 assurances of licenses to be made available, or the result of an 655 attempt made to obtain a general license or permission for the use 656 of such proprietary rights by implementers or users of this 657 specification can be obtained from the IETF on-line IPR repository 658 at http://www.ietf.org/ipr. 660 The IETF invites any interested party to bring to its attention any 661 copyrights, patents or patent applications, or other proprietary 662 rights that may cover technology that may be required to implement 663 this standard. Please address the information to the IETF at 664 ietf-ipr@ietf.org. 666 Full Copyright Statement 668 Copyright (C) The IETF Trust (2008). This document is subject to the 669 rights, licenses and restrictions contained in BCP 78, and except as 670 set forth therein, the authors retain all their rights. 672 This document and the information contained herein are provided on 673 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 674 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 675 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 676 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 677 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 678 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 679 FOR A PARTICULAR PURPOSE. 681 Acknowledgment 683 Funding for the RFC Editor function is currently provided by the 684 Internet Society. 686 (RFC Editor: Please delete everything after this point) 688 Open Issues 690 - The appendices need to be written. 692 - Should the server send a base64-encoded ServerSignature for the 693 value of the "v" attribute, or should it compute a ServerProof the 694 way the client computes a ClientProof? 696 - What about this LDAP attribute to store authentication 697 information? 699 - It is entirely unclear to me how best to handle channel bindings. 700 Should the channel binding data be sent directly at all? 702 Should hash algorithm be negotiated inside SCRAM, or should it be a 703 part of the mechanism name (e.g. SCRAM-HMAC-SHA1)? 705 Need to clarify extensibility of authentication exchange: should 706 unrecognized attributes be ignored? If yes, need to update ABNF 707 accordingly. 709 Changes since -05 710 Changed the mandatory to implement hash algorithm to SHA1 (as per WG 711 consensus). 713 Added text about use of SASLPrep for username 714 canonicalization/validation. 716 Clarified that authorization identity is canonicalized/verified 717 according to SASL protocol profile. 719 Clarified how clients select the authentication function. 721 Added IANA registration for the new mechanism. 723 Added missing normative references (UTF-8, SASLPrep). 725 Various editorial changes based on comments from Hallvard B 726 Furuseth, Nico William and Simon Josefsson. 728 Changes since -04 729 - Update Base64 and Security Glossary references. 731 - Add Formal Syntax section. 733 - Don't bother with "v=". 735 - Make MD5 mandatory to implement. Suggest i=128. 737 Changes since -03 739 - Seven years have passed, in which it became clear that DIGEST-MD5 740 suffered from unacceptably bad interoperability, so SCRAM-MD5 is 741 now back from the dead. 743 - Be hash agnostic, so MD5 can be replaced more easily. 745 - General simplification.