idnits 2.17.1 draft-ietf-sasl-scram-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 8, 2010) is 5190 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: 'I-D.ietf-sasl-gs2' is mentioned on line 1206, but not defined == Missing Reference: 'RFC2743' is mentioned on line 1211, but not defined == Missing Reference: 'RFC4121' is mentioned on line 1220, but not defined == Missing Reference: 'RFC3962' is mentioned on line 1217, but not defined == Missing Reference: 'RFC3961' is mentioned on line 1214, but not defined == Missing Reference: 'RFC4401' is mentioned on line 1225, but not defined == Missing Reference: 'RFC4402' is mentioned on line 1229, but not defined ** Obsolete undefined reference: RFC 4402 (Obsoleted by RFC 7802) == Missing Reference: 'RFCXXXX' is mentioned on line 1013, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) == Outdated reference: A later version (-10) exists of draft-altman-tls-channel-bindings-07 == Outdated reference: A later version (-04) exists of draft-melnikov-sasl-scram-ldap-02 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP C. Newman 3 Internet-Draft Sun Microsystems 4 Intended status: Standards Track A. Menon-Sen 5 Expires: August 12, 2010 Oryx Mail Systems GmbH 6 A. Melnikov 7 Isode Ltd 8 N. Williams 9 Sun Microsystems 10 February 8, 2010 12 Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism 13 draft-ietf-sasl-scram-11.txt 15 Abstract 17 The secure authentication mechanism most widely deployed and used by 18 Internet application protocols is the transmission of clear-text 19 passwords over a channel protected by Transport Layer Security (TLS). 20 There are some significant security concerns with that mechanism, 21 which could be addressed by the use of a challenge response 22 authentication mechanism protected by TLS. Unfortunately, the 23 challenge response mechanisms presently on the standards track all 24 fail to meet requirements necessary for widespread deployment, and 25 have had success only in limited use. 27 This specification describes a family of Simple Authentication and 28 Security Layer (SASL, RFC 4422) authentication mechanisms called the 29 Salted Challenge Response Authentication Mechanism (SCRAM), which 30 addresses the security concerns and meets the deployability 31 requirements. When used in combination with TLS or an equivalent 32 security layer, a mechanism from this family could improve the 33 status-quo for application protocol authentication and provide a 34 suitable choice for a mandatory-to-implement mechanism for future 35 application protocol standards. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on August 12, 2010. 60 Copyright Notice 62 Copyright (c) 2010 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the BSD License. 75 Table of Contents 77 1. Conventions Used in This Document . . . . . . . . . . 4 78 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4 79 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . 5 80 2. Introduction . . . . . . . . . . . . . . . . . . . . . 7 81 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . 9 82 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . 11 83 5. SCRAM Authentication Exchange . . . . . . . . . . . . 12 84 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 13 85 5.2. Compliance with SASL mechanism requirements . . . . . 16 86 6. Channel Binding . . . . . . . . . . . . . . . . . . . 17 87 6.1. Default Channel Binding . . . . . . . . . . . . . . . 18 88 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 19 89 8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 23 90 8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 23 91 8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 23 92 8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 24 93 9. Security Considerations . . . . . . . . . . . . . . . 25 94 10. IANA Considerations . . . . . . . . . . . . . . . . . 27 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . 29 96 Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 30 97 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 31 98 Appendix C. Internet-Draft Change History . . . . . . . . . . . . 32 99 12. References . . . . . . . . . . . . . . . . . . . . . . 34 100 12.1. Normative References . . . . . . . . . . . . . . . . . 34 101 12.2. Normative References for GSS-API implementors . . . . 34 102 12.3. Informative References . . . . . . . . . . . . . . . . 35 103 Authors' Addresses . . . . . . . . . . . . . . . . . . 37 105 1. Conventions Used in This Document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 Formal syntax is defined by [RFC5234] including the core rules 112 defined in Appendix B of [RFC5234]. 114 Example lines prefaced by "C:" are sent by the client and ones 115 prefaced by "S:" by the server. If a single "C:" or "S:" label 116 applies to multiple lines, then the line breaks between those lines 117 are for editorial clarity only, and are not part of the actual 118 protocol exchange. 120 1.1. Terminology 122 This document uses several terms defined in [RFC4949] ("Internet 123 Security Glossary") including the following: authentication, 124 authentication exchange, authentication information, brute force, 125 challenge-response, cryptographic hash function, dictionary attack, 126 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 127 one-way encryption function, password, replay attack and salt. 128 Readers not familiar with these terms should use that glossary as a 129 reference. 131 Some clarifications and additional definitions follow: 133 o Authentication information: Information used to verify an identity 134 claimed by a SCRAM client. The authentication information for a 135 SCRAM identity consists of salt, iteration count, the "StoredKey" 136 and "ServerKey" (as defined in the algorithm overview) for each 137 supported cryptographic hash function. 139 o Authentication database: The database used to look up the 140 authentication information associated with a particular identity. 141 For application protocols, LDAPv3 (see [RFC4510]) is frequently 142 used as the authentication database. For network-level protocols 143 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 144 common. 146 o Base64: An encoding mechanism defined in [RFC4648] which converts 147 an octet string input to a textual output string which can be 148 easily displayed to a human. The use of base64 in SCRAM is 149 restricted to the canonical form with no whitespace. 151 o Octet: An 8-bit byte. 153 o Octet string: A sequence of 8-bit bytes. 155 o Salt: A random octet string that is combined with a password 156 before applying a one-way encryption function. This value is used 157 to protect passwords that are stored in an authentication 158 database. 160 1.2. Notation 162 The pseudocode description of the algorithm uses the following 163 notations: 165 o ":=": The variable on the left hand side represents the octet 166 string resulting from the expression on the right hand side. 168 o "+": Octet string concatenation. 170 o "[ ]": A portion of an expression enclosed in "[" and "]" may not 171 be included in the result under some circumstances. See the 172 associated text for a description of those circumstances. 174 o Normalize(str): Apply the SASLPrep profile [RFC4013] of the 175 "stringprep" algorithm [RFC3454] as the normalization algorithm to 176 a UTF-8 [RFC3629] encoded "str". The resulting string is also in 177 UTF-8. When applying SASLPrep, "str" is treated as a "stored 178 strings", which means that unassigned Unicode codepoints are 179 prohibited (see Section 7 of [RFC3454]). Note that 180 implementations MUST either implement SASLPrep, or disallow use of 181 non US-ASCII Unicode codepoints in "str". 183 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 184 [RFC2104]) using the octet string represented by "key" as the key 185 and the octet string "str" as the input string. The size of the 186 result is the hash result size for the hash function in use. For 187 example, it is 20 octets for SHA-1 (see [RFC3174]). 189 o H(str): Apply the cryptographic hash function to the octet string 190 "str", producing an octet string as a result. The size of the 191 result depends on the hash result size for the hash function in 192 use. 194 o XOR: Apply the exclusive-or operation to combine the octet string 195 on the left of this operator with the octet string on the right of 196 this operator. The length of the output and each of the two 197 inputs will be the same for this use. 199 o Hi(str, salt, i): 201 U1 := HMAC(str, salt + INT(1)) 202 U2 := HMAC(str, U1) 203 ... 204 Ui-1 := HMAC(str, Ui-2) 205 Ui := HMAC(str, Ui-1) 207 Hi := U1 XOR U2 XOR ... XOR Ui 209 where "i" is the iteration count, "+" is the string concatenation 210 operator and INT(g) is a four-octet encoding of the integer g, 211 most significant octet first. 213 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 214 with dkLen == output length of HMAC() == output length of H(). 216 2. Introduction 218 This specification describes a family of authentication mechanisms 219 called the Salted Challenge Response Authentication Mechanism (SCRAM) 220 which addresses the requirements necessary to deploy a challenge- 221 response mechanism more widely than past attempts (see Appendix A and 222 Appendix B). When used in combination with Transport Layer Security 223 (TLS, see [RFC5246]) or an equivalent security layer, a mechanism 224 from this family could improve the status-quo for application 225 protocol authentication and provide a suitable choice for a 226 mandatory-to-implement mechanism for future application protocol 227 standards. 229 For simplicity, this family of mechanisms does not presently include 230 negotiation of a security layer [RFC4422]. It is intended to be used 231 with an external security layer such as that provided by TLS or SSH, 232 with optional channel binding [RFC5056] to the external security 233 layer. 235 SCRAM is specified herein as a pure Simple Authentication and 236 Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new 237 bridge between SASL and the Generic Security Services Application 238 Programming Interface (GSS-API) called "GS2" [I-D.ietf-sasl-gs2]. 239 This means that this document defines both, a SASL mechanism and a 240 GSS-API mechanism. 242 SCRAM provides the following protocol features: 244 o The authentication information stored in the authentication 245 database is not sufficient by itself to impersonate the client. 246 The information is salted to prevent a pre-stored dictionary 247 attack if the database is stolen. 249 o The server does not gain the ability to impersonate the client to 250 other servers (with an exception for server-authorized proxies). 252 o The mechanism permits the use of a server-authorized proxy without 253 requiring that proxy to have super-user rights with the back-end 254 server. 256 o Mutual authentication is supported, but only the client is named 257 (i.e., the server has no name). 259 o When used as a SASL mechanism, SCRAM is capable of transporting 260 authorization identities (see [RFC4422], Section 2) from the 261 client to the server. 263 A separate document defines a standard LDAPv3 [RFC4510] attribute 264 that enables storage of the SCRAM authentication information in LDAP. 265 See [I-D.melnikov-sasl-scram-ldap]. 267 For an in-depth discussion of why other challenge response mechanisms 268 are not considered sufficient, see appendix A. For more information 269 about the motivations behind the design of this mechanism, see 270 appendix B. 272 3. SCRAM Algorithm Overview 274 The following is a description of a full, uncompressed SASL SCRAM 275 authentication exchange. Nothing in SCRAM prevents either sending 276 the client-first message with the SASL authentication request defined 277 by an application protocol ("initial client response"), nor sending 278 the server-final message as additional data of the SASL outcome of 279 authentication exchange defined by an application protocol. See 280 [RFC4422] for more details. 282 Note that this section omits some details, such as client and server 283 nonces. See Section 5 for more details. 285 To begin with, the SCRAM client is in possession of a username and 286 password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends 287 the username to the server, which retrieves the corresponding 288 authentication information, i.e. a salt, StoredKey, ServerKey and the 289 iteration count i. (Note that a server implementation may choose to 290 use the same iteration count for all accounts.) The server sends the 291 salt and the iteration count to the client, which then computes the 292 following values and sends a ClientProof to the server: 294 (*) - Note that both the username and the password MUST be encoded in 295 UTF-8 [RFC3629]. 297 Informative Note: Implementors are encouraged to create test cases 298 that use both username passwords with non-ASCII codepoints. In 299 particular, it's useful to test codepoints whose "Unicode 300 Normalization Form C" and "Unicode Normalization Form KC" are 301 different. Some examples of such codepoints include Vulgar Fraction 302 One Half (U+00BD) and Acute Accent (U+00B4). 304 SaltedPassword := Hi(Normalize(password), salt, i) 305 ClientKey := HMAC(SaltedPassword, "Client Key") 306 StoredKey := H(ClientKey) 307 AuthMessage := client-first-message-bare + "," + 308 server-first-message + "," + 309 client-final-message-without-proof 310 ClientSignature := HMAC(StoredKey, AuthMessage) 311 ClientProof := ClientKey XOR ClientSignature 312 ServerKey := HMAC(SaltedPassword, "Server Key") 313 ServerSignature := HMAC(ServerKey, AuthMessage) 315 The server authenticates the client by computing the ClientSignature, 316 exclusive-ORing that with the ClientProof to recover the ClientKey 317 and verifying the correctness of the ClientKey by applying the hash 318 function and comparing the result to the StoredKey. If the ClientKey 319 is correct, this proves that the client has access to the user's 320 password. 322 Similarly, the client authenticates the server by computing the 323 ServerSignature and comparing it to the value sent by the server. If 324 the two are equal, it proves that the server had access to the user's 325 ServerKey. 327 The AuthMessage is computed by concatenating messages from the 328 authentication exchange. The format of these messages is defined in 329 Section 7. 331 4. SCRAM Mechanism Names 333 A SCRAM mechanism name is a string "SCRAM-" followed by the 334 uppercased name of the underlying hash function taken from the IANA 335 "Hash Function Textual Names" registry (see http://www.iana.org), 336 optionally followed by the suffix "-PLUS" (see below). Note that 337 SASL mechanism names are limited to 20 octets, which means that only 338 hash function names with lengths shorter or equal to 9 octets (20- 339 length("SCRAM-")-length("-PLUS") can be used. For cases when the 340 underlying hash function name is longer than 9 octets, an alternative 341 9 octet (or shorter) name can be used to construct the corresponding 342 SCRAM mechanism name, as long as this alternative name doesn't 343 conflict with any other hash function name from the IANA "Hash 344 Function Textual Names" registry. In order to prevent future 345 conflict, such alternative name SHOULD be registered in the IANA 346 "Hash Function Textual Names" registry. 348 For interoperability, all SCRAM clients and servers MUST implement 349 the SCRAM-SHA-1 authentication mechanism, i.e. an authentication 350 mechanism from the SCRAM family that uses the SHA-1 hash function as 351 defined in [RFC3174]. 353 The "-PLUS" suffix is used only when the server supports channel 354 binding to the external channel. If the server supports channel 355 binding, it will advertise both the "bare" and "plus" versions of 356 whatever mechanisms it supports (e.g., if the server supports only 357 SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1 358 and SCRAM-SHA-1-PLUS); if the server does not support channel 359 binding, then it will advertise only the "bare" version of the 360 mechanism (e.g., only SCRAM-SHA-1). The "-PLUS" exists to allow 361 negotiation of the use of channel binding. See Section 6. 363 5. SCRAM Authentication Exchange 365 SCRAM is a SASL mechanism whose client response and server challenge 366 messages are text-based messages containing one or more attribute- 367 value pairs separated by commas. Each attribute has a one-letter 368 name. The messages and their attributes are described in 369 Section 5.1, and defined in Section 7. 371 SCRAM is a client-first SASL mechanism (See [RFC4422], Section 5, 372 item 2a), and returns additional data together with a server's 373 indication of a successful outcome. 375 This is a simple example of a SCRAM-SHA-1 authentication exchange 376 when the client doesn't support channel bindings: 378 C: n,,n=Chris Newman,r=ClientNonce 379 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 380 C: c=biwsCg==,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 381 S: v=WxPv/siO5l+qxN4 383 [[anchor5: Note that the all hashes above are fake and will be fixed 384 during AUTH48.]] 386 With channel-binding data sent by the client this might look like 387 this (see [tls-server-end-point] for the definition of tls-server- 388 end-point TLS channel binding): 390 C: p=tls-server-end-point,,n=Chris Newman,r=ClientNonce 391 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 392 C: c=cD10bHMtc2VydmVyLWVuZC1wb2ludCwsy1hFtXOnZ+ySrQM6srFp 393 l/77uqvtxrg7nBY1BetEr/g=,r=ClientNonceServerNonce,p=Wx 394 Pv/siO5l+qxN4 395 S: v=WxPv/siO5l+qxN4 397 [[anchor6: Note that all hashes above are fake and will be fixed 398 during AUTH48.]] 400 First, the client sends the "client-first-message" containing: 402 o a GS2 header consisting of a flag indicating whether channel 403 binding is supported-but-not-used, not supported, or used, and an 404 optional SASL authorization identity; 406 o SCRAM username and a random, unique nonce attributes. 408 Note that the client's first message will always start with "n", "y" 409 or "p", otherwise the message is invalid and authentication MUST 410 fail. This is important, as it allows for GS2 extensibility (e.g., 411 to add support for security layers). 413 In response, the server sends a "server-first-message" containing the 414 user's iteration count i, the user's salt, and appends its own nonce 415 to the client-specified one. 417 The client then responds by sending "client-final-message" with the 418 same nonce and a ClientProof computed using the selected hash 419 function as explained earlier. 421 The server verifies the nonce and the proof, verifies that the 422 authorization identity (if supplied by the client in the first 423 message) is authorized to act as the authentication identity, and, 424 finally, it responds with a "server-final-message", concluding the 425 authentication exchange. 427 The client then authenticates the server by computing the 428 ServerSignature and comparing it to the value sent by the server. If 429 the two are different, the client MUST consider the authentication 430 exchange to be unsuccessful and it might have to drop the connection. 432 5.1. SCRAM Attributes 434 This section describes the permissible attributes, their use, and the 435 format of their values. All attribute names are single US-ASCII 436 letters and are case-sensitive. 438 Note that the order of attributes in client or server messages is 439 fixed, with the exception of extension attributes (described by the 440 "extensions" ABNF production), which can appear in any order in the 441 designated positions. See the ABNF section for authoritative 442 reference. 444 o a: This is an optional attribute, and is part of the GS2 445 [I-D.ietf-sasl-gs2] bridge between the GSS-API and SASL. This 446 attribute specifies an authorization identity. A client may 447 include it in its first message to the server if it wants to 448 authenticate as one user, but subsequently act as a different 449 user. This is typically used by an administrator to perform some 450 management task on behalf of another user, or by a proxy in some 451 situations. 453 Upon the receipt of this value the server verifies its 454 correctness according to the used SASL protocol profile. 455 Failed verification results in failed authentication exchange. 457 If this attribute is omitted (as it normally would be), the 458 authorization identity is assumed to be derived from the 459 username specified with the (required) "n" attribute. 461 The server always authenticates the user specified by the "n" 462 attribute. If the "a" attribute specifies a different user, 463 the server associates that identity with the connection after 464 successful authentication and authorization checks. 466 The syntax of this field is the same as that of the "n" field 467 with respect to quoting of '=' and ','. 469 o n: This attribute specifies the name of the user whose password is 470 used for authentication (a.k.a. "authentication identity" 471 [RFC4422]). A client MUST include it in its first message to the 472 server. If the "a" attribute is not specified (which would 473 normally be the case), this username is also the identity which 474 will be associated with the connection subsequent to 475 authentication and authorization. 477 Before sending the username to the server, the client SHOULD 478 prepare the username using the "SASLPrep" profile [RFC4013] of 479 the "stringprep" algorithm [RFC3454] treating it as a query 480 string (i.e., unassigned Unicode code points are allowed). If 481 the preparation of the username fails or results in an empty 482 string, the client SHOULD abort the authentication exchange 483 (*). 485 (*) An interactive client can request a repeated entry of the 486 username value. 488 Upon receipt of the username by the server, the server MUST 489 either prepare it using the "SASLPrep" profile [RFC4013] of the 490 "stringprep" algorithm [RFC3454] treating it as a query string 491 (i.e., unassigned Unicode codepoints are allowed) or otherwise 492 be prepared to do SASLprep-aware string comparisons and/or 493 index lookups. If the preparation of the username fails or 494 results in an empty string, the server SHOULD abort the 495 authentication exchange. Whether or not the server prepares 496 the username using "SASLPrep", it MUST use it as received in 497 hash calculations. 499 The characters ',' or '=' in usernames are sent as '=2C' and 500 '=3D' respectively. If the server receives a username which 501 contains '=' not followed by either '2C' or '3D', then the 502 server MUST fail the authentication. 504 o m: This attribute is reserved for future extensibility. In this 505 version of SCRAM, its presence in a client or a server message 506 MUST cause authentication failure when the attribute is parsed by 507 the other end. 509 o r: This attribute specifies a sequence of random printable ASCII 510 characters excluding ',' which forms the nonce used as input to 511 the hash function. No quoting is applied to this string. As 512 described earlier, the client supplies an initial value in its 513 first message, and the server augments that value with its own 514 nonce in its first response. It is important that this value be 515 different for each authentication (see [RFC4086] for more details 516 on how to achieve this). The client MUST verify that the initial 517 part of the nonce used in subsequent messages is the same as the 518 nonce it initially specified. The server MUST verify that the 519 nonce sent by the client in the second message is the same as the 520 one sent by the server in its first message. 522 o c: This REQUIRED attribute specifies the base64-encoded GS2 header 523 and channel-binding data. It is sent by the client in its second 524 authentication message. The attribute data consist of: 526 * the GS2 header from the client's first message (recall that the 527 GS2 header contains a channel binding flag and an optional 528 authzid). This header is going to include channel binding type 529 prefix (see [RFC5056]), if and only if the client is using 530 channel binding; 532 * followed by the external channel's channel binding data, if and 533 only if the client is using channel binding. 535 o s: This attribute specifies the base64-encoded salt used by the 536 server for this user. It is sent by the server in its first 537 message to the client. 539 o i: This attribute specifies an iteration count for the selected 540 hash function and user, and MUST be sent by the server along with 541 the user's salt. 543 For SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism servers SHOULD 544 announce a hash iteration-count of at least 4096. Note that a 545 client implementation MAY cache ClientKey&ServerKey (or just 546 SaltedPassword) for later reauthentication to the same service, 547 as it is likely that the server is going to advertise the same 548 salt value upon reauthentication. This might be useful for 549 mobile clients where CPU usage is a concern. 551 o p: This attribute specifies a base64-encoded ClientProof. The 552 client computes this value as described in the overview and sends 553 it to the server. 555 o v: This attribute specifies a base64-encoded ServerSignature. It 556 is sent by the server in its final message, and is used by the 557 client to verify that the server has access to the user's 558 authentication information. This value is computed as explained 559 in the overview. 561 5.2. Compliance with SASL mechanism requirements 563 This section describes compliance with SASL mechanism requirements 564 specified in Section 5 of [RFC4422]. 566 1) "SCRAM-SHA-1" and "SCRAM-SHA-1-PLUS". 568 2a) SCRAM is a client-first mechanism. 570 2b) SCRAM sends additional data with success. 572 3) SCRAM is capable of transferring authorization identities from the 573 client to the server. 575 4) SCRAM does not offer any security layers (SCRAM offers channel 576 binding instead). 578 5) SCRAM has a hash protecting the authorization identity. 580 6. Channel Binding 582 SCRAM supports channel binding to external secure channels, such as 583 TLS. Clients and servers may or may not support channel binding, 584 therefore the use of channel binding is negotiable. SCRAM does not 585 provide security layers, however, therefore it is imperative that 586 SCRAM provide integrity protection for the negotiation of channel 587 binding. 589 Use of channel binding is negotiated as follows: 591 o Servers SHOULD advertise both non-PLUS (SCRAM-) and 592 the PLUS-variant (SCRAM--PLUS) SASL mechanism 593 names. If the server cannot support channel binding, it MAY 594 advertise only the non-PLUS variant. If the server would never 595 succeed authentication of the non-PLUS variant due to policy 596 reasons, it MAY advertise only the PLUS-variant. 598 o If the client negotiates mechanisms then the client MUST select 599 SCRAM--PLUS if offered by the server and the client 600 wants to select SCRAM with the given hash function. Otherwise 601 (the client does not negotiate mechanisms), if the client has no 602 prior knowledge about mechanisms supported by the server and 603 wasn't explicitly configured to use a particular variant of the 604 SCRAM mechanism, then it MUST select only SCRAM- 605 (not suffixed with "-PLUS"). 607 o If the client supports channel binding and the server appears to 608 support it (i.e., the client sees SCRAM--PLUS), or 609 if the client wishes to use channel binding but the client does 610 not negotiate mechanisms, then the client MUST set the GS2 channel 611 binding flag to "p" in order to indicate the channel binding type 612 it is using and it MUST include the channel binding data for the 613 external channel in the computation of the "c=" attribute (see 614 Section 5.1). 616 o If the client supports channel binding but the server does not 617 appear to (i.e., the client did not see SCRAM-- 618 PLUS) then the client MUST either fail authentication or it MUST 619 choose the non-PLUS mechanism and set the GS2 channel binding flag 620 to "y" and MUST NOT include channel binding data for the external 621 channel in the computation of the "c=" attribute (see 622 Section 5.1). 624 o If the client does not support channel binding then the client 625 MUST set the GS2 channel binding flag to "n" and MUST NOT include 626 channel binding data for the external channel in the computation 627 of the "c=" attribute (see Section 5.1). 629 o Upon receipt of the client first message the server checks the GS2 630 channel binding flag (gs2-cb-flag). 632 * If the flag is set to "y" and the server supports channel 633 binding the server MUST fail authentication. This is because 634 if the client sets the GS2 channel binding flag set to "y" then 635 the client must have believed that the server did not support 636 channel binding -- if the server did in fact support channel 637 binding then this is an indication that there has been a 638 downgrade attack (e.g., an attacker changed the server's 639 mechanism list to exclude the -PLUS suffixed SCRAM mechanism 640 name(s)). 642 * If the channel binding flag was "p" and the server does not 643 support the indicated channel binding type then the server MUST 644 fail authentication. 646 The server MUST always validate the client's "c=" field. The server 647 does this by constructing the value of the "c=" attribute and then 648 checking that it matches the client's c= attribute value. 650 For more discussions of channel bindings, and the syntax of the 651 channel binding data for various security protocols, see [RFC5056]. 653 6.1. Default Channel Binding 655 A default channel binding type agreement process for all SASL 656 application protocols that do not provide their own channel binding 657 type agreement is provided as follows. 659 'tls-unique' is the default channel binding type for any application 660 that doesn't specify one. 662 Servers MUST implement the "tls-unique" [tls-unique] 663 [I-D.altman-tls-channel-bindings] channel binding type, if they 664 implement any channel binding. Clients SHOULD implement the "tls- 665 unique" [tls-unique] [I-D.altman-tls-channel-bindings] channel 666 binding type, if they implement any channel binding. Clients and 667 servers SHOULD choose the highest- layer/innermost end-to-end TLS 668 channel as the channel to bind to. 670 Servers MUST choose the channel binding type indicated by the client, 671 or fail authentication if they don't support it. 673 7. Formal Syntax 675 The following syntax specification uses the Augmented Backus-Naur 676 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 677 and "UTF8-4" non-terminal are defined in [RFC3629]. 679 ALPHA = 680 DIGIT = 681 UTF8-2 = 682 UTF8-3 = 683 UTF8-4 = 685 attr-val = ALPHA "=" value 686 ;; Generic syntax of any attribute sent 687 ;; by server or client 689 value = 1*value-char 691 value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / 692 UTF8-2 / UTF8-3 / UTF8-4 693 ;; UTF8-char except NUL, "=", and ",". 695 value-char = value-safe-char / "=" 697 printable = %x21-2B / %x2D-7E 698 ;; Printable ASCII except ",". 699 ;; Note that any "printable" is also 700 ;; a valid "value". 702 base64-char = ALPHA / DIGIT / "/" / "+" 704 base64-4 = 4base64-char 706 base64-3 = 3base64-char "=" 708 base64-2 = 2base64-char "==" 710 base64 = *base64-4 [base64-3 / base64-2] 712 posit-number = %x31-39 *DIGIT 713 ;; A positive number 715 saslname = 1*(value-safe-char / "=2C" / "=3D") 716 ;; Conforms to 718 authzid = "a=" saslname 719 ;; Protocol specific. 721 cb-name = 1*(ALPHA / DIGIT / "." / "-") 722 ;; See RFC 5056 section 7. 723 ;; E.g. "tls-server-end-point" or 724 ;; "tls-unique" 726 gs2-cbind-flag = "p=" cb-name / "n" / "y" 727 ;; "n" -> client doesn't support channel binding 728 ;; "y" -> client does support channel binding 729 ;; but thinks the server does not. 730 ;; "p" -> client requires channel binding. 731 ;; The selected channel binding follows "p=". 733 gs2-header = gs2-cbind-flag "," [ authzid ] "," 734 ;; GS2 header for SCRAM 735 ;; (the actual GS2 header includes an optional 736 ;; flag to indicate that the GSS mechanism is not 737 ;; "standard" but since SCRAM is "standard" we 738 ;; don't include that flag). 740 username = "n=" saslname 741 ;; Usernames are prepared using SASLPrep. 743 reserved-mext = "m=" 1*(value-char) 744 ;; Reserved for signalling mandatory extensions. 745 ;; The exact syntax will be defined in 746 ;; the future. 748 channel-binding = "c=" base64 749 ;; base64 encoding of cbind-input 751 proof = "p=" base64 753 nonce = "r=" c-nonce [s-nonce] 754 ;; Second part provided by server. 756 c-nonce = printable 758 s-nonce = printable 760 salt = "s=" base64 762 verifier = "v=" base64 763 ;; base-64 encoded ServerSignature. 765 iteration-count = "i=" posit-number 766 ;; A positive number 768 client-first-message-bare = 770 [reserved-mext ","] 771 username "," nonce ["," extensions] 773 client-first-message = 774 gs2-header client-first-message-bare 776 server-first-message = 777 [reserved-mext ","] nonce "," salt "," 778 iteration-count ["," extensions] 780 client-final-message-without-proof = 781 channel-binding "," nonce ["," 782 extensions] 784 client-final-message = 785 client-final-message-without-proof "," proof 787 server-error = "e=" server-error-value 789 server-error-value = "invalid-encoding" / 790 "extensions-not-supported" / ; unrecognized 'm' value 791 "invalid-proof" / 792 "channel-bindings-dont-match" / 793 "server-does-support-channel-binding" / 794 ; server does not support channel binding 795 "channel-binding-not-supported" / 796 "unsupported-channel-binding-type" / 797 "unknown-user" / 798 "invalid-username-encoding" / 799 ; invalid username encoding (invalid UTF-8 or 800 ; SASLprep failed) 801 "no-resources" / 802 "other-error" / 803 server-error-value-ext 804 ; Unrecognized errors should be treated as "other-error". 805 ; In order to prevent information disclosure the server 806 ; may substitute the real reason with "other-error". 808 server-error-value-ext = value 809 ; Additional error reasons added by extensions 810 ; to this document. 812 server-final-message = (server-error / verifier) 813 ["," extensions] 814 ;; The error message is only for the GSS-API 815 ;; form of SCRAM, and it is OPTIONAL to 816 ;; implement it. 818 extensions = attr-val *("," attr-val) 819 ;; All extensions are optional, 820 ;; i.e. unrecognized attributes 821 ;; not defined in this document 822 ;; MUST be ignored. 824 cbind-data = 1*OCTET 826 cbind-input = gs2-header [ cbind-data ] 827 ;; cbind-data MUST be present for 828 ;; gs2-cbind-flag of "p" and MUST be absent 829 ;; for "y" or "n". 831 8. SCRAM as a GSS-API Mechanism 833 This section and its sub-sections and all normative references of it 834 not referenced elsewhere in this document are INFORMATIONAL for SASL 835 implementors, but they are NORMATIVE for GSS-API implementors. 837 SCRAM is actually also GSS-API mechanism. The messages are the same, 838 but a) the GS2 header on the client's first message and channel 839 binding data is excluded when SCRAM is used as a GSS-API mechanism, 840 and b) the RFC2743 section 3.1 initial context token header is 841 prefixed to the client's first authentication message (context 842 token). 844 The GSS-API mechanism OID for SCRAM-SHA-1 is (see Section 10). 846 8.1. GSS-API Principal Name Types for SCRAM 848 SCRAM does not name acceptors. Therefore only GSS_C_NO_NAME and 849 names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name 850 input of GSS_Init_sec_context() when using a SCRAM mechanism. 852 SCRAM supports only a single name type for initiators: 853 GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 854 SCRAM. 856 There is no name canonicalization procedure for SCRAM beyond applying 857 SASLprep as described in Section 5.1. 859 The query, display and exported name syntax for SCRAM principal names 860 is the same: there is no syntax -- SCRAM principal names are free- 861 form. (The exported name token does, of course, conform to [RFC2743] 862 section 3.2, but the "NAME" part of the token is just a SCRAM user 863 name.) 865 8.2. GSS-API Per-Message Tokens for SCRAM 867 The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the 868 same as those for the Kerberos V GSS-API mechanism [RFC4121] (see 869 Section 4.2 and sub-sections), using the Kerberos V "aes128-cts-hmac- 870 sha1-96" enctype [RFC3962]. 872 The 128-bit session "protocol key" SHALL be derived by using the 873 least significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API 874 session key" || ClientKey || AuthMessage). "Specific keys" are then 875 derived as usual as described in Section 2 of [RFC4121], [RFC3961] 876 and [RFC3962]. 878 The terms "protocol key" and "specific key" are Kerberos V5 terms 880 [RFC3961]. 882 SCRAM does support PROT_READY, and is PROT_READY on the initiator 883 side first upon receipt of the server's reply to the initial security 884 context token. 886 8.3. GSS_Pseudo_random() for SCRAM 888 The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for 889 the Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor- 890 asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and 891 GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random(). 892 The protocol key to be used for the GSS_Pseudo_random() SHALL be the 893 same as the key defined in Section 8.2. 895 9. Security Considerations 897 If the authentication exchange is performed without a strong security 898 layer (such as TLS with data confidentiality), then a passive 899 eavesdropper can gain sufficient information to mount an offline 900 dictionary or brute-force attack which can be used to recover the 901 user's password. The amount of time necessary for this attack 902 depends on the cryptographic hash function selected, the strength of 903 the password and the iteration count supplied by the server. An 904 external security layer with strong encryption will prevent this 905 attack. 907 If the external security layer used to protect the SCRAM exchange 908 uses an anonymous key exchange, then the SCRAM channel binding 909 mechanism can be used to detect a man-in-the-middle attack on the 910 security layer and cause the authentication to fail as a result. 911 However, the man-in-the-middle attacker will have gained sufficient 912 information to mount an offline dictionary or brute-force attack. 913 For this reason, SCRAM allows to increase the iteration count over 914 time. (Note that a server that is only in posession of "StoredKey" 915 and "ServerKey" can't automatic increase the iteration count upon 916 successful authentication. Such increase would require resetting 917 user's password.) 919 If the authentication information is stolen from the authentication 920 database, then an offline dictionary or brute-force attack can be 921 used to recover the user's password. The use of salt mitigates this 922 attack somewhat by requiring a separate attack on each password. 923 Authentication mechanisms which protect against this attack are 924 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 925 an example of such technology. The WG selected not to use EKE like 926 mechanisms as basis for SCRAM. 928 If an attacker obtains the authentication information from the 929 authentication repository and either eavesdrops on one authentication 930 exchange or impersonates a server, the attacker gains the ability to 931 impersonate that user to all servers providing SCRAM access using the 932 same hash function, password, iteration count and salt. For this 933 reason, it is important to use randomly-generated salt values. 935 SCRAM does not negotiate a hash function to use. Hash function 936 negotiation is left to the SASL mechanism negotiation. It is 937 important that clients be able to sort a locally available list of 938 mechanisms by preference so that the client may pick the most 939 preferred of a server's advertised mechanism list. This preference 940 order is not specified here as it is a local matter. The preference 941 order should include objective and subjective notions of mechanism 942 cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be 943 preferred over SCRAM with SHA-1). 945 Note that to protect the SASL mechanism negotiation applications 946 normally must list the server mechs twice: once before and once after 947 authentication, the latter using security layers. Since SCRAM does 948 not provide security layers the only ways to protect the mechanism 949 negotiation are: a) use channel binding to an external channel, or b) 950 use an external channel that authenticates a user-provided server 951 name. 953 SCRAM does not protect against downgrade attacks of channel binding 954 types. The complexities of negotiation a channel binding type, and 955 handling down-grade attacks in that negotiation, was intentionally 956 left out of scope for this document. 958 A hostile server can perform a computational denial-of-service attack 959 on clients by sending a big iteration count value. 961 See [RFC4086] for more information about generating randomness. 963 10. IANA Considerations 965 IANA is requested to add the following family of SASL mechanisms to 966 the SASL Mechanism registry established by [RFC4422]: 968 To: iana@iana.org 969 Subject: Registration of a new SASL family SCRAM 971 SASL mechanism name (or prefix for the family): SCRAM-* 972 Security considerations: Section 7 of [RFCXXXX] 973 Published specification (optional, recommended): [RFCXXXX] 974 Person & email address to contact for further information: 975 IETF SASL WG 976 Intended usage: COMMON 977 Owner/Change controller: IESG 978 Note: Members of this family must be explicitly registered 979 using the "IETF Review" [RFC5226] registration procedure. 980 Reviews must be requested on the SASL WG mailing list. 982 "IETF Review" [RFC5226] registration procedure MUST be used for 983 registering new mechanisms in this family. The SASL mailing list 984 (or a successor designated by the responsible 985 Security AD) MUST be used for soliciting reviews on such 986 registrations. 988 Note to future SCRAM- mechanism designers: each new SCRAM- SASL 989 mechanism MUST be explicitly registered with IANA and MUST comply 990 with SCRAM- mechanism naming convention defined in Section 4 of this 991 document. 993 IANA is requested to add the following entries to the SASL Mechanism 994 registry established by [RFC4422]: 996 To: iana@iana.org 997 Subject: Registration of a new SASL mechanism SCRAM-SHA-1 999 SASL mechanism name (or prefix for the family): SCRAM-SHA-1 1000 Security considerations: Section 7 of [RFCXXXX] 1001 Published specification (optional, recommended): [RFCXXXX] 1002 Person & email address to contact for further information: 1003 IETF SASL WG 1004 Intended usage: COMMON 1005 Owner/Change controller: IESG 1006 Note: 1008 To: iana@iana.org 1009 Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS 1011 SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS 1012 Security considerations: Section 7 of [RFCXXXX] 1013 Published specification (optional, recommended): [RFCXXXX] 1014 Person & email address to contact for further information: 1015 IETF SASL WG 1016 Intended usage: COMMON 1017 Owner/Change controller: IESG 1018 Note: 1020 This document also requests IANA to assign a GSS-API mechanism OID 1021 for SCRAM-SHA-1 from the iso.org.dod.internet.security.mechanisms 1022 prefix (see "SMI Security for Mechanism Codes" registry). 1024 11. Acknowledgements 1026 This document benefited from discussions on the SASL WG mailing list. 1027 The authors would like to specially thank Dave Cridland, Simon 1028 Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen, Ben 1029 Campbell and Peter Saint-Andre for their contributions to this 1030 document. 1032 Appendix A. Other Authentication Mechanisms 1034 The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has 1035 proved to be too complex to implement and test, and thus has poor 1036 interoperability. The security layer is often not implemented, and 1037 almost never used; everyone uses TLS instead. For a more complete 1038 list of problems with DIGEST-MD5 which lead to the creation of SCRAM 1039 see [I-D.ietf-sasl-digest-to-historic]. 1041 The CRAM-MD5 SASL mechanism, while widely deployed has also some 1042 problems, in particular it is missing some modern SASL features such 1043 as support for internationalized usernames and passwords, support for 1044 passing of authorization identity, support for channel bindings. It 1045 also doesn't support server authentication. For a more complete list 1046 of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic]. 1048 The PLAIN [RFC4616] SASL mechanism allows a malicious server or 1049 eavesdropper to impersonate the authenticating user to any other 1050 server for which the user has the same password. It also sends the 1051 password in the clear over the network, unless TLS is used. Server 1052 authentication is not supported. 1054 Appendix B. Design Motivations 1056 The following design goals shaped this document. Note that some of 1057 the goals have changed since the initial version of the document. 1059 o The SASL mechanism has all modern SASL features: support for 1060 internationalized usernames and passwords, support for passing of 1061 authorization identity, support for channel bindings. 1063 o The protocol supports mutual authentication. 1065 o The authentication information stored in the authentication 1066 database is not sufficient by itself to impersonate the client. 1068 o The server does not gain the ability to impersonate the client to 1069 other servers (with an exception for server-authorized proxies), 1070 unless such other servers allow SCRAM authentication and use the 1071 same salt and iteration count for the user. 1073 o The mechanism is extensible, but [hopefully] not overengineered in 1074 this respect. 1076 o Easier to implement than DIGEST-MD5 in both clients and servers. 1078 Appendix C. Internet-Draft Change History 1080 (RFC Editor: Please delete this section and all subsections.) 1082 Changes since -10 1084 o Converted the source for this I-D to XML. 1086 o Added text to make SCRAM compliant with the new GS2 design. 1088 o Added text on channel binding negotiation. 1090 o Added text on channel binding, including a reference to RFC5056. 1092 o Added text on SCRAM as a GSS-API mechanism. This noted as not 1093 relevant to SASL-only implementors -- the normative references for 1094 SCRAM as a GSS-API mechanism are segregated as well. 1096 Changes since -07 1098 o Updated References. 1100 o Clarified purpose of the m= attribute. 1102 o Fixed a problem with authentication/authorization identity's ABNF 1103 not allowing for some characters. 1105 o Updated ABNF for nonce to show client-generated and server- 1106 generated parts. 1108 o Only register SCRAM-SHA-1 with IANA and require explicit 1109 registrations of all other SCRAM- mechanisms. 1111 Changes since -06 1113 o Removed hash negotiation from SCRAM and turned it into a family of 1114 SASL mechanisms. 1116 o Start using "Hash Function Textual Names" IANA registry for SCRAM 1117 mechanism naming. 1119 o Fixed definition of Hi(str, salt, i) to be consistent with 1120 [RFC2898]. 1122 o Clarified extensibility of SCRAM: added m= attribute (for future 1123 mandatory extensions) and specified that all unrecognized 1124 attributes must be ignored. 1126 Changes since -05 1128 o Changed the mandatory to implement hash algorithm to SHA-1 (as per 1129 WG consensus). 1131 o Added text about use of SASLPrep for username canonicalization/ 1132 validation. 1134 o Clarified that authorization identity is canonicalized/verified 1135 according to SASL protocol profile. 1137 o Clarified that iteration count is per-user. 1139 o Clarified how clients select the authentication function. 1141 o Added IANA registration for the new mechanism. 1143 o Added missing normative references (UTF-8, SASLPrep). 1145 o Various editorial changes based on comments from Hallvard B 1146 Furuseth, Nico William and Simon Josefsson. 1148 Changes since -04 1150 o Update Base64 and Security Glossary references. 1152 o Add Formal Syntax section. 1154 o Don't bother with "v=". 1156 o Make MD5 mandatory to implement. Suggest i=128. 1158 Changes since -03 1160 o Seven years have passed, in which it became clear that DIGEST-MD5 1161 suffered from unacceptably bad interoperability, so SCRAM-MD5 is 1162 now back from the dead. 1164 o Be hash agnostic, so MD5 can be replaced more easily. 1166 o General simplification. 1168 12. References 1170 12.1. Normative References 1172 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1173 Hashing for Message Authentication", RFC 2104, 1174 February 1997. 1176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1177 Requirement Levels", BCP 14, RFC 2119, March 1997. 1179 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1180 (SHA1)", RFC 3174, September 2001. 1182 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1183 Internationalized Strings ("stringprep")", RFC 3454, 1184 December 2002. 1186 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1187 10646", STD 63, RFC 3629, November 2003. 1189 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1190 and Passwords", RFC 4013, February 2005. 1192 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1193 Security Layer (SASL)", RFC 4422, June 2006. 1195 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1196 Encodings", RFC 4648, October 2006. 1198 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1199 Channels", RFC 5056, November 2007. 1201 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1202 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1204 12.2. Normative References for GSS-API implementors 1206 [I-D.ietf-sasl-gs2] 1207 Josefsson, S. and N. Williams, "Using GSS-API Mechanisms 1208 in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-12 1209 (work in progress), April 2009. 1211 [RFC2743] Linn, J., "Generic Security Service Application Program 1212 Interface Version 2, Update 1", RFC 2743, January 2000. 1214 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1215 Kerberos 5", RFC 3961, February 2005. 1217 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1218 Encryption for Kerberos 5", RFC 3962, February 2005. 1220 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1221 Version 5 Generic Security Service Application Program 1222 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1223 July 2005. 1225 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1226 Extension for the Generic Security Service Application 1227 Program Interface (GSS-API)", RFC 4401, February 2006. 1229 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1230 Kerberos V Generic Security Service Application Program 1231 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1233 [tls-unique] 1234 Zhu, L., "Registration of TLS unique channel binding 1235 (generic)", IANA http://www.iana.org/assignments/ 1236 channel-binding-types/tls-unique, July 2008. 1238 12.3. Informative References 1240 [I-D.altman-tls-channel-bindings] 1241 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1242 for TLS", draft-altman-tls-channel-bindings-07 (work in 1243 progress), October 2009. 1245 [I-D.ietf-sasl-crammd5-to-historic] 1246 Zeilenga, K., "CRAM-MD5 to Historic", 1247 draft-ietf-sasl-crammd5-to-historic-00 (work in progress), 1248 November 2008. 1250 [I-D.ietf-sasl-digest-to-historic] 1251 Melnikov, A., "Moving DIGEST-MD5 to Historic", 1252 draft-ietf-sasl-digest-to-historic-00 (work in progress), 1253 July 2008. 1255 [I-D.melnikov-sasl-scram-ldap] 1256 Melnikov, A., "LDAP schema for storing SCRAM secrets", 1257 draft-melnikov-sasl-scram-ldap-02 (work in progress), 1258 July 2009. 1260 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1261 "Remote Authentication Dial In User Service (RADIUS)", 1262 RFC 2865, June 2000. 1264 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 1265 Specification Version 2.0", RFC 2898, September 2000. 1267 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 1268 RFC 2945, September 2000. 1270 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1271 Requirements for Security", BCP 106, RFC 4086, June 2005. 1273 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 1274 (LDAP): Technical Specification Road Map", RFC 4510, 1275 June 2006. 1277 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 1278 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 1280 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1281 RFC 4949, August 2007. 1283 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1284 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1285 May 2008. 1287 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1288 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1290 [tls-server-end-point] 1291 Zhu, L., "Registration of TLS server end-point channel 1292 bindings", IANA http://www.iana.org/assignments/ 1293 channel-binding-types/tls-server-end-point, July 2008. 1295 Authors' Addresses 1297 Chris Newman 1298 Sun Microsystems 1299 1050 Lakes Drive 1300 West Covina, CA 91790 1301 USA 1303 Email: chris.newman@sun.com 1305 Abhijit Menon-Sen 1306 Oryx Mail Systems GmbH 1308 Email: ams@toroid.org 1310 Alexey Melnikov 1311 Isode Ltd 1313 Email: Alexey.Melnikov@isode.com 1315 Nicolas Williams 1316 Sun Microsystems 1317 5300 Riata Trace Ct 1318 Austin, TX 78727 1319 USA 1321 Email: Nicolas.Williams@sun.com