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