From 96c5ea43fc90d4ae70b331883a025edcd5071b5c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Mon, 16 Feb 2009 18:37:06 +0000 Subject: [PATCH] x git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@24729 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-newman-auth-scram-09.txt | 1080 +++++++++++++++++ 1 file changed, 1080 insertions(+) create mode 100644 doc/standardisation/draft-newman-auth-scram-09.txt diff --git a/doc/standardisation/draft-newman-auth-scram-09.txt b/doc/standardisation/draft-newman-auth-scram-09.txt new file mode 100644 index 000000000..915b9adea --- /dev/null +++ b/doc/standardisation/draft-newman-auth-scram-09.txt @@ -0,0 +1,1080 @@ + + + + + + +Network Working Group Abhijit Menon-Sen +Internet-Draft Oryx Mail Systems GmbH +Intended Status: Proposed Standard Chris Newman +Expires: August 2009 Sun Microsystems + Alexey Melnikov + Isode Ltd + February 15, 2009 + + + Salted Challenge Response (SCRAM) SASL Mechanism + + draft-newman-auth-scram-09.txt + + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with + the provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- + Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft expires in July 2009. + + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with + respect to this document. + + + +Menon-Sen & Co Expires August 2009 FF[Page 1] + + + + + +Internet-draft February 2009 + + +Abstract + + The secure authentication mechanism most widely deployed and used by + Internet application protocols is the transmission of clear-text + passwords over a channel protected by Transport Layer Security + (TLS). There are some significant security concerns with that + mechanism, which could be addressed by the use of a challenge + response authentication mechanism protected by TLS. Unfortunately, + the challenge response mechanisms presently on the standards track + all fail to meet requirements necessary for widespread deployment, + and have had success only in limited use. + + This specification describes a family of authentication mechanisms + called the Salted Challenge Response Authentication Mechanism + (SCRAM), which addresses the security concerns and meets the + deployability requirements. When used in combination with TLS or an + equivalent security layer, a mechanism from this family could + improve the status-quo for application protocol authentication and + provide a suitable choice for a mandatory-to-implement mechanism for + future application protocol standards. + + +1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Formal syntax is defined by [RFC5234] including the core rules + defined in Appendix B of [RFC5234]. + + Example lines prefaced by "C:" are sent by the client and ones + prefaced by "S:" by the server. If a single "C:" or "S:" label + applies to multiple lines, then the line breaks between those lines + are for editorial clarity only, and are not part of the actual + protocol exchange. + + +1.1. Terminology + + This document uses several terms defined in [RFC4949] ("Internet + Security Glossary") including the following: authentication, + authentication exchange, authentication information, brute force, + challenge-response, cryptographic hash function, dictionary attack, + eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, + one-way encryption function, password, replay attack and salt. + Readers not familiar with these terms should use that glossary as a + reference. + + + +Menon-Sen & Co Expires August 2009 FF[Page 2] + + + + + +Internet-draft February 2009 + + + Some clarifications and additional definitions follow: + + - Authentication information: Information used to verify an identity + claimed by a SCRAM client. The authentication information for a + SCRAM identity consists of salt, iteration count, the "StoredKey" + and "ServerKey" (as defined in the algorithm overview) for each + supported cryptographic hash function. + + - Authentication database: The database used to look up the + authentication information associated with a particular identity. + For application protocols, LDAPv3 (see [RFC4510]) is frequently + used as the authentication database. For network-level protocols + such as PPP or 802.11x, the use of RADIUS is more common. + + - Base64: An encoding mechanism defined in [RFC4648] which converts + an octet string input to a textual output string which can be + easily displayed to a human. The use of base64 in SCRAM is + restricted to the canonical form with no whitespace. + + - Octet: An 8-bit byte. + + - Octet string: A sequence of 8-bit bytes. + + - Salt: A random octet string that is combined with a password + before applying a one-way encryption function. This value is used + to protect passwords that are stored in an authentication + database. + + +1.2. Notation + + The pseudocode description of the algorithm uses the following + notations: + + - ":=": The variable on the left hand side represents the octet + string resulting from the expression on the right hand side. + + - "+": Octet string concatenation. + + - "[ ]": A portion of an expression enclosed in "[" and "]" may not + be included in the result under some circumstances. See the + associated text for a description of those circumstances. + + - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in + [RFC2104]) using the octet string represented by "key" as the key + and the octet string "str" as the input string. The size of the + result is the hash result size for the hash function in use. For + example, it is 20 octets for SHA-1 (see [RFC3174]). + + + +Menon-Sen & Co Expires August 2009 FF[Page 3] + + + + + +Internet-draft February 2009 + + + - H(str): Apply the cryptographic hash function to the octet string + "str", producing an octet string as a result. The size of the + result depends on the hash result size for the hash function in + use. + + - XOR: Apply the exclusive-or operation to combine the octet string + on the left of this operator with the octet string on the right of + this operator. The length of the output and each of the two inputs + will be the same for this use. + + - Hi(str, salt): + + U0 := HMAC(str, salt || INT(1)) + U1 := HMAC(str, U0) + U2 := HMAC(str, U1) + ... + Ui-1 := HMAC(str, Ui-2) + Ui := HMAC(str, Ui-1) + + Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui + where "i" is the iteration count, "||" is the string concatenation + operator and INT(g) is a four-octet encoding of the integer g, + most significant octet first. + + This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and + with dkLen == output length of HMAC() == output length of H(). + + + +2. Introduction + + This specification describes a family of authentication mechanisms + called the Salted Challenge Response Authentication Mechanism + (SCRAM) which addresses the requirements necessary to deploy a + challenge-response mechanism more widely than past attempts. When + used in combination with Transport Layer Security (TLS, see [TLS]) + or an equivalent security layer, a mechanism from this family could + improve the status-quo for application protocol authentication and + provide a suitable choice for a mandatory-to-implement mechanism for + future application protocol standards. + + For simplicity, this family of mechanism does not presently include + negotiation of a security layer. It is intended to be used with an + external security layer such as that provided by TLS or SSH. + + SCRAM provides the following protocol features: + + - The authentication information stored in the authentication + + + +Menon-Sen & Co Expires August 2009 FF[Page 4] + + + + + +Internet-draft February 2009 + + + database is not sufficient by itself to impersonate the client. + The information is salted to prevent a pre-stored dictionary + attack if the database is stolen. + + - The server does not gain the ability to impersonate the client to + other servers (with an exception for server-authorized proxies). + + - The mechanism permits the use of a server-authorized proxy without + requiring that proxy to have super-user rights with the back-end + server. + + - A standard attribute is defined to enable storage of the + authentication information in LDAPv3 (see [RFC4510]). + + - Both the client and server can be authenticated by the protocol. + + For an in-depth discussion of why other challenge response + mechanisms are not considered sufficient, see appendix A. For more + information about the motivations behind the design of this + mechanism, see appendix B. + + Comments regarding this draft may be sent either to the ietf- + sasl@imc.org mailing list or to the authors. + + +3. SCRAM Algorithm Overview + + Note that this section omits some details, such as client and server + nonces. See Section 5 for more details. + + To begin with, the client is in possession of a username and + password. It sends the username to the server, which retrieves the + corresponding authentication information, i.e. a salt, StoredKey, + ServerKey and the iteration count i. (Note that a server + implementation may chose to use the same iteration count for all + account.) The server sends the salt and the iteration count to the + client, which then computes the following values and sends a + ClientProof to the server: + + SaltedPassword := Hi(password, salt) + ClientKey := H(SaltedPassword) + StoredKey := H(ClientKey) + AuthMessage := client-first-message + "," + + server-first-message + "," + + final-client-message-without-proof + ClientSignature := HMAC(StoredKey, AuthMessage) + ClientProof := ClientKey XOR ClientSignature + ServerKey := HMAC(SaltedPassword, salt) + + + +Menon-Sen & Co Expires August 2009 FF[Page 5] + + + + + +Internet-draft February 2009 + + + ServerSignature := HMAC(ServerKey, AuthMessage) + + The server authenticates the client by computing the + ClientSignature, exclusive-ORing that with the ClientProof to + recover the ClientKey and verifying the correctness of the ClientKey + by applying the hash function and comparing the result to the + StoredKey. If the ClientKey is correct, this proves that the client + has access to the user's password. + + Similarly, the client authenticates the server by computing the + ServerSignature and comparing it to the value sent by the server. + If the two are equal, it proves that the server had access to the + user's ServerKey. + + The AuthMessage is computed by concatenating messages from the + authentication exchange. The format of these messages is defined in + the Formal Syntax section. + + +4. SCRAM mechanism names + + A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the + uppercased name of the underlying hashed function taken from the + IANA "Hash Function Textual Names" registry (see + http://www.iana.org). + + For interoperability, all SCRAM clients and servers MUST implement + the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an + authentication mechanism from the SCRAM family that uses the SHA-1 + hash function as defined in [RFC3174]. + + +5. SCRAM Authentication Exchange + + SCRAM is a text protocol where the client and server exchange + messages containing one or more attribute-value pairs separated by + commas. Each attribute has a one-letter name. The messages and their + attributes are described in section 5.1, and defined in the Formal + Syntax section. + + This is a simple example of a SCRAM-HMAC-SHA-1 authentication + exchange: + C: n=Chris Newman,r=ClientNonce + S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 + C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 + S: v=WxPv/siO5l+qxN4 + + With channel-binding data sent by the client this might look like this: + + + +Menon-Sen & Co Expires August 2009 FF[Page 6] + + + + + +Internet-draft February 2009 + + + C: n=Chris Newman,r=ClientNonce + S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 + C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 + S: v=WxPv/siO5l+qxN4 + + <> + + First, the client sends a message containing the username, and a + random, unique nonce. In response, the server sends the user's + iteration count i, the user's salt, and appends its own nonce to the + client-specified one. The client then responds with the same nonce + and a ClientProof computed using the selected hash function as + explained earlier. In this step the client can also include an + optional authorization identity. The server verifies the nonce and + the proof, verifies that the authorization identity (if supplied by + the client in the second message) is authorized to act as the + authentication identity, and, finally, it responds with a + ServerSignature, concluding the authentication exchange. The client + then authenticates the server by computing the ServerSignature and + comparing it to the value sent by the server. If the two are + different, the client MUST consider the authentication exchange to + be unsuccessful and it might have to drop the connection. + + +5.1 SCRAM attributes + + This section describes the permissible attributes, their use, and + the format of their values. All attribute names are single US-ASCII + letters and are case-sensitive. + + - a: This optional attribute specifies an authorization identity. A + client may include it in its second message to the server if it + wants to authenticate as one user, but subsequently act as a + different user. This is typically used by an administrator to + perform some management task on behalf of another user, or by a + proxy in some situations. + + Upon the receipt of this value the server verifies its correctness + according to the used SASL protocol profile. Failed verification + results in failed authentication exchange. + + If this attribute is omitted (as it normally would be), or + specified with an empty value, the authorization identity is + assumed to be derived from the username specified with the + (required) "n" attribute. + + The server always authenticates the user specified by the "n" + attribute. If the "a" attribute specifies a different user, the + + + +Menon-Sen & Co Expires August 2009 FF[Page 7] + + + + + +Internet-draft February 2009 + + + server associates that identity with the connection after + successful authentication and authorization checks. + + The syntax of this field is the same as that of the "n" field with + respect to quoting of '=' and ','. + + - n: This attribute specifies the name of the user whose password is + used for authentication. A client must include it in its first + message to the server. If the "a" attribute is not specified + (which would normally be the case), this username is also the + identity which will be associated with the connection subsequent + to authentication and authorization. + + Before sending the username to the server, the client MUST prepare + the username using the "SASLPrep" profile [SASLPrep] of the + "stringprep" algorithm [RFC3454]. If the preparation of the + username fails or results in an empty string, the client SHOULD + abort the authentication exchange (*). + + (*) An interactive client can request a repeated entry of the + username value. + + Upon receipt of the username by the server, the server SHOULD + prepare it using the "SASLPrep" profile [SASLPrep] of the + "stringprep" algorithm [RFC3454]. If the preparation of the + username fails or results in an empty string, the server SHOULD + abort the authentication exchange. + + The characters ',' or '=' in usernames are sent as '=2C' and '=3D' + respectively. If the server receives a username which contains '=' + not followed by either '2C' or '3D', then the server MUST fail the + authentication. + + - m: This attribute is reserved for future extensibility. In this + version of SCRAM, its presence in a client or a server message + MUST cause authentication failure when the attribute is parsed by + the other end. + + - r: This attribute specifies a sequence of random printable + characters excluding ',' which forms the nonce used as input to + the hash function. No quoting is applied to this string (unless + the binding of SCRAM to a particular protocol states otherwise). + As described earlier, the client supplies an initial value in its + first message, and the server augments that value with its own + nonce in its first response. It is important that this be value + different for each authentication. The client MUST verify that the + initial part of the nonce used in subsequent messages is the same + as the nonce it initially specified. The server MUST verify that + + + +Menon-Sen & Co Expires August 2009 FF[Page 8] + + + + + +Internet-draft February 2009 + + + the nonce sent by the client in the second message is the same as + the one sent by the server in its first message. + + - c: This optional attribute specifies base64-encoded channel- + binding data. It is sent by the client in the second step. If + specified by the client, if the server supports the specified + channel binding type and if the server can't verify it, then the + server MUST fail the authentication exchange. Whether this + attribute is included, and the meaning and contents of the + channel-binding data depends on the external security layer in + use. This is necessary to detect a man-in-the-middle attack on the + security layer. + + - s: This attribute specifies the base64-encoded salt used by the + server for this user. It is sent by the server in its first + message to the client. + + - i: This attribute specifies an iteration count for the selected + hash function and user, and must be sent by the server along with + the user's salt. + + For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash + iteration-count of at least 128. + + - p: This attribute specifies a base64-encoded ClientProof. The + client computes this value as described in the overview and sends + it to the server. + + - v: This attribute specifies a base64-encoded ServerSignature. It + is sent by the server in its final message, and may be used by the + client to verify that the server has access to the user's + authentication information. This value is computed as explained in + the overview. + + +6. Formal Syntax + + The following syntax specification uses the Augmented Backus-Naur + Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" + and "UTF8-4" non-terminal are defined in [UTF-8]. + + generic-message = attr-val *("," attr-val) + ;; Generic syntax of any server challenge + ;; or client response + + attr-val = ALPHA "=" value + + value = *(value-char) + + + +Menon-Sen & Co Expires August 2009 FF[Page 9] + + + + + +Internet-draft February 2009 + + + value-safe-char = %01-2B / %2D-3C / %3E-7F / + UTF8-2 / UTF-3 / UTF8-4 + ;; UTF8-char except NUL, "=", and ",". + + value-char = value-safe-char / "=" + + base64-char = ALPHA / DIGIT / "/" / "+" + + base64-4 = 4*4(base64-char) + + base64-3 = 3*3(base64-char) "=" + + base64-2 = 2*2(base64-char) "==" + + base64 = *(base64-4) [base64-3 / base64-2] + + posit-number = (%x31-39) *DIGIT + ;; A positive number + + saslname = 1*(value-safe-char / "=2C" / "=3D") + ;; Conforms to + + authzid = "a=" saslname + ;; Protocol specific. + + username = "n=" saslname + ;; Usernames are prepared using SASLPrep. + + reserved-mext = "m=" 1*(value-char) + ;; Reserved for signalling mandatory extensions. + ;; The exact syntax will be defined in + ;; the future. + + channel-binding = "c=" base64 + + proof = "p=" base64 + + nonce = "r=" c-nonce [s-nonce] + ;; Second part provided by server. + + c-nonce = value + + s-nonce = value + + salt = "s=" base64 + + verifier = "v=" base64 + ;; base-64 encoded ServerSignature. + + + +Menon-Sen & Co Expires August 2009 FF[Page 10] + + + + + +Internet-draft February 2009 + + + iteration-count = "i=" posit-number + ;; A positive number + + client-first-message = + [reserved-mext ","] username "," nonce ["," + extensions] + + server-first-message = + [reserved-mext ","] nonce "," salt "," + iteration-count ["," extensions] + + client-final-message-without-proof = + [authzid ","] [channel-binding ","] nonce ["," + extensions] + + client-final-message = + client-final-message-without-proof "," proof + + server-final-message = + verifier ["," extensions] + + extensions = attr-val *("," attr-val) + ;; All extensions are optional, + ;; i.e. unrecognized attributes + ;; not defined in this document + ;; MUST be ignored. + + +7. Security Considerations + + If the authentication exchange is performed without a strong + security layer, then a passive eavesdropper can gain sufficient + information to mount an offline dictionary or brute-force attack + which can be used to recover the user's password. The amount of time + necessary for this attack depends on the cryptographic hash function + selected, the strength of the password and the iteration count + supplied by the server. An external security layer with strong + encryption will prevent this attack. + + If the external security layer used to protect the SCRAM exchange + uses an anonymous key exchange, then the SCRAM channel binding + mechanism can be used to detect a man-in-the-middle attack on the + security layer and cause the authentication to fail as a result. + However, the man-in-the-middle attacker will have gained sufficient + information to mount an offline dictionary or brute-force attack. + For this reason, SCRAM includes the ability to increase the + iteration count over time. + + + + +Menon-Sen & Co Expires August 2009 FF[Page 11] + + + + + +Internet-draft February 2009 + + + If the authentication information is stolen from the authentication + database, then an offline dictionary or brute-force attack can be + used to recover the user's password. The use of salt mitigates this + attack somewhat by requiring a separate attack on each password. + Authentication mechanisms which protect against this attack are + available (e.g., the EKE class of mechanisms), but the patent + situation is presently unclear. + + If an attacker obtains the authentication information from the + authentication repository and either eavesdrops on one + authentication exchange or impersonates a server, the attacker gains + the ability to impersonate that user to all servers providing SCRAM + access using the same hash function, password, iteration count and + salt. For this reason, it is important to use randomly-generated + salt values. + + If the server detects (from the value of the client-specified "h" + attribute) that both endpoints support a stronger hash function that + the one the client actually chooses to use, then it SHOULD treat + this as a downgrade attack and reject the authentication attempt. + + A hostile server can perform a computational denial-of-service + attack on clients by sending a big iteration count value. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Menon-Sen & Co Expires August 2009 FF[Page 12] + + + + + +Internet-draft February 2009 + + +8. IANA considerations + + IANA is requested to add the following entry to the SASL Mechanism + registry established by [RFC4422]: + + To: iana@iana.org + Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1 + + SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1 + Security considerations: Section 7 of [RFCXXXX] + Published specification (optional, recommended): [RFCXXXX] + Person & email address to contact for further information: + IETF SASL WG + Intended usage: COMMON + Owner/Change controller: IESG + Note: + + Note that even though this document defines a family of SCRAM-HMAC + mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in + the SASL Mechanisms registry. IANA is requested to prevent future + registrations of SASL mechanisms starting with SCRAM-HMAC- without + consulting the SASL mailing list first. + + Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC + SASL mechanism MUST be explicitly registered with IANA and MUST + comply with SCRAM-HMAC mechanism naming convention defined in + Section 4 of this document. + + + +9. Acknowedgements + + The authors would like to thank Dave Cridland for his contributions + to this document. + + +10. Normative References + + [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, SJD, October 2006. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for + Message Authentication", IBM, February 1997. + + [RFC2119] Bradner, "Key words for use in RFCs to Indicate + + + +Menon-Sen & Co Expires August 2009 FF[Page 13] + + + + + +Internet-draft February 2009 + + + Requirement Levels", RFC 2119, Harvard University, March + 1997. + + [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC + 3174, Motorola, September 2001 + + [RFC5234] Crocker, Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 5234, January 2008. + + [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security + Layer (SASL)", RFC 4422, Isode Limited, June 2006. + + [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user + names and passwords", RFC 4013, February 2005. + + [RFC3454] Hoffman, P., Blanchet, M., "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + + +11. Informative References + + [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension + for Simple Challenge/Response", RFC 2195, MCI, September + 1997. + + [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", + RFC 2202, IBM, September 1997 + + [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography + Specification Version 2.0", RFC 2898, September 2000. + + [TLS] Dierks, Rescorla, "The Transport Layer Security (TLS) + Protocol, Version 1.2", RFC 5246, August 2008. + + [RFC4949] Shirey, "Internet Security Glossary, Version 2", RFC + 4949, FYI 0036, August 2007. + + [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for + Security", RFC 4086, BCP 0106, Motorola Laboratories, + June 2005. + + [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP): + Technical Specification Road Map", RFC 4510, June 2006. + + [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication + as a SASL Mechanism", RFC 2831, May 2000. <> + + [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in + progress, draft-ietf-sasl-digest-to-historic-00.txt, July + 2008 + + [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress, + draft-ietf-sasl-crammd5-to-historic-00.txt, November + 2008. + + [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security + Layer (SASL) Mechanism" RFC 4616, August 2006. + + +12. Authors' Addresses + + Abhijit Menon-Sen + Oryx Mail Systems GmbH + + Email: ams@oryx.com + + + Alexey Melnikov + Isode Ltd + + EMail: Alexey.Melnikov@isode.com + + + Chris Newman + Sun Microsystems + 1050 Lakes Drive + West Covina, CA 91790 + USA + + Email: chris.newman@sun.com + + +Appendix A: Other Authentication Mechanisms + + The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex + to implement and test, and thus has poor interoperability. The + security layer is often not implemented, and almost never used; + everyone uses TLS instead. For a more complete list of problems + with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST- + HISTORIC]. + + The CRAM-MD5 SASL mechanism, while widely deployed has also some + problems, in particular it is missing some modern SASL features such + + + +Menon-Sen & Co Expires August 2009 FF[Page 15] + + + + + +Internet-draft February 2009 + + + as support for internationalized usernames and passwords, support + for passing of authorization identity, support for channel bindings. + It also doesn't support server authentication. For a more complete + list of problems with CRAM-MD5 see [CRAM-HISTORIC]. + + The PLAIN [PLAIN] SASL mechanism allows a malicious server or + eavesdropper to impersonate the authenticating user to any other + server for which the user has the same password. It also sends the + password in the clear over the network, unless TLS is used. Server + authentication is not supported. + + +Appendix B: Design Motivations + + The following design goals shaped this document. Note that some of + the goals have changed since the initial version of the document. + + The SASL mechanism has all modern SASL features: support for + internationalized usernames and passwords, support for passing of + authorization identity, support for channel bindings. + + Both the client and server can be authenticated by the protocol. + + The authentication information stored in the authentication + database is not sufficient by itself to impersonate the client. + + <> + + The mechanism is extensible, but [hopefully] not overengineered in + this respect. + + Easier to implement than DIGEST-MD5 in both clients and servers. + + +Appendix C: SCRAM Examples + + <> + + + + + + + + + + + + +Menon-Sen & Co Expires August 2009 FF[Page 16] + + + + + +Internet-draft February 2009 + + + (RFC Editor: Please delete everything after this point) + + +Open Issues + + - The appendices need to be written. + + - Should the server send a base64-encoded ServerSignature for the + value of the "v" attribute, or should it compute a ServerProof the + way the client computes a ClientProof? + + +Changes since -07 + + Updated References. + + Clarified purpose of the m= attribute. + + Fixed a problem with authentication/authorization identity's ABNF + not allowing for some characters. + + Updated ABNF for nonce to show client-generated and server-generated + parts. + + Only register SCRAM-HMAC-SHA-1 with IANA and require explicit + registrations of all other SCRAM-HMAC- mechanisms. + + + +Changes since -06 + + Removed hash negotiation from SCRAM and turned it into a family of + SASL mechanisms. + + Start using "Hash Function Textual Names" IANA registry for SCRAM + mechanism naming. + + Fixed definition of Hi(str, salt) to be consistent with [RFC2898]. + + Clarified extensibility of SCRAM: added m= attribute (for future + mandatory extensions) and specified that all unrecognized + attributes must be ignored. + + + +Changes since -05 + + Changed the mandatory to implement hash algorithm to SHA-1 (as per + + + +Menon-Sen & Co Expires August 2009 FF[Page 17] + + + + + +Internet-draft February 2009 + + + WG consensus). + + Added text about use of SASLPrep for username + canonicalization/validation. + + Clarified that authorization identity is canonicalized/verified + according to SASL protocol profile. + + Clarified that iteration count is per-user. + + Clarified how clients select the authentication function. + + Added IANA registration for the new mechanism. + + Added missing normative references (UTF-8, SASLPrep). + + Various editorial changes based on comments from Hallvard B + Furuseth, Nico William and Simon Josefsson. + + + +Changes since -04 + + - Update Base64 and Security Glossary references. + + - Add Formal Syntax section. + + - Don't bother with "v=". + + - Make MD5 mandatory to implement. Suggest i=128. + + + +Changes since -03 + + - Seven years have passed, in which it became clear that DIGEST-MD5 + suffered from unacceptably bad interoperability, so SCRAM-MD5 is + now back from the dead. + + - Be hash agnostic, so MD5 can be replaced more easily. + + - General simplification. + + + + + + + + + +Menon-Sen & Co Expires August 2009 FF[Page 18] + +