Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 7804 Isode Ltd
Category: Experimental March 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 7804 Isode Ltd
Category: Experimental March 2016
ISSN: 2070-1721
Salted Challenge Response HTTP Authentication Mechanism
salt质询响应HTTP认证机制
Abstract
摘要
This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.
本规范描述了一系列HTTP身份验证机制，称为Salted质询-响应身份验证机制（SCRAM），它提供了一种比受传输层安全性（TLS）保护的明文密码更健壮的身份验证机制并避免了早期受TLS保护的质询-响应身份验证机制带来的部署障碍。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7804.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7804.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. One Round-Trip Reauthentication . . . . . . . . . . . . . 10
6. Use of the Authentication-Info Header Field with SCRAM . . . 12
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. One Round-Trip Reauthentication . . . . . . . . . . . . . 10
6. Use of the Authentication-Info Header Field with SCRAM . . . 12
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
The 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 HTTP Digest challenge response mechanism presently on the Standards Track failed widespread deployment and has had only limited success.
Internet应用程序协议最广泛部署和使用的身份验证机制是通过传输层安全性（TLS）保护的通道传输明文密码。该机制存在一些重大的安全问题，可以通过使用受TLS保护的质询-响应身份验证机制来解决。不幸的是，目前在标准轨道上的HTTP摘要质询-响应机制未能广泛部署，成功率有限。
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 (see [RFC5802]). In particular, it addresses some of the issues identified with HTTP Digest, as described in [RFC6331], such as the complexity of implementation and protection of the whole authentication exchange in order to protect against certain man-in-the-middle attacks.
本规范描述了一系列认证机制，称为Salted质询-响应认证机制（SCRAM），它解决了比以往尝试更广泛地部署质询-响应机制所需的要求（参见[RFC5802]）。特别是，它解决了[RFC6331]中所述的HTTP摘要中确定的一些问题，例如实现的复杂性和整个身份验证交换的保护，以防止某些中间人攻击。
HTTP SCRAM is an adaptation of [RFC5802] for use in HTTP. The SCRAM data exchanged is identical to what is defined in [RFC5802]. This document also adds a 1 round-trip reauthentication mode.
HTTP紧急停堆是[RFC5802]的一种改编，用于HTTP。交换的紧急停堆数据与[RFC5802]中的定义相同。本文档还添加了1往返重新验证模式。
HTTP SCRAM provides the following protocol features:
HTTP紧急停堆提供以下协议功能：
o The authentication information stored in the authentication database is not sufficient by itself (without a dictionary attack) to impersonate the client. The information is salted to make it harder to do a pre-stored dictionary attack if the database is stolen.
o 存储在身份验证数据库中的身份验证信息本身（没有字典攻击）不足以模拟客户端。如果数据库被盗，则对信息进行腌制，使其更难进行预存储字典攻击。
o The server does not gain the ability to impersonate the client to other servers (with an exception for server-authorized proxies), unless it performs a dictionary attack.
o 服务器无法向其他服务器模拟客户端（服务器授权代理除外），除非它执行字典攻击。
o The mechanism permits the use of a server-authorized proxy without requiring that proxy to have super-user rights with the back-end server.
o 该机制允许使用服务器授权的代理，而无需该代理具有后端服务器的超级用户权限。
o Mutual authentication is supported, but only the client is named (i.e., the server has no name).
o 支持相互身份验证，但只命名客户端（即服务器没有名称）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Formal syntax is defined by [RFC5234] including the core rules defined in Appendix B of [RFC5234].
形式语法由[RFC5234]定义，包括[RFC5234]附录B中定义的核心规则。
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.
以“C:”开头的示例行由客户端发送，以“S:”开头的示例行由服务器发送。如果单个“C:”或“S:”标签适用于多行，则这些行之间的换行符仅用于编辑清晰性，不属于实际协议交换的一部分。
This document uses several terms defined in the "Internet Security Glossary" [RFC4949], 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.
本文档使用了“互联网安全词汇表”[RFC4949]中定义的几个术语，包括以下内容：身份验证、身份验证交换、身份验证信息、暴力、质询响应、加密哈希函数、字典攻击、窃听、哈希结果、密钥哈希、中间人、nonce、，单向加密功能、密码、重放攻击和salt。不熟悉这些术语的读者应使用该术语表作为参考。
Some clarifications and additional definitions follow:
以下是一些澄清和补充定义：
o 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 the ServerKey (as defined in the algorithm overview) for each supported cryptographic hash function.
o 身份验证信息：用于验证紧急停堆客户端声明的身份的信息。紧急停堆标识的身份验证信息包括每个支持的加密哈希函数的salt、迭代计数、StoredKey和ServerKey（如算法概述中所定义）。
o 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 lower-layer protocols such as PPP or 802.11x, the use of RADIUS [RFC2865] is more common.
o 身份验证数据库：用于查找与特定身份相关联的身份验证信息的数据库。对于应用程序协议，LDAPv3（参见[RFC4510]）经常用作身份验证数据库。对于较低层协议，如PPP或802.11x，使用RADIUS[RFC2865]更为常见。
o Base64: An encoding mechanism defined in Section 4 of [RFC4648] that converts an octet string input to a textual output string that can be easily displayed to a human. The use of base64 in SCRAM is restricted to the canonical form with no whitespace.
o Base64:[RFC4648]第4节中定义的一种编码机制，它将八位字节字符串输入转换为文本输出字符串，可以轻松地显示给用户。在紧急停堆中使用base64仅限于不带空格的规范形式。
o Octet: An 8-bit byte.
o 八位字节：一个8位字节。
o Octet string: A sequence of 8-bit bytes.
o 八位字节字符串：8位字节的序列。
o 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.
o Salt：在应用单向加密函数之前与密码组合的随机八位字节字符串。此值用于保护存储在身份验证数据库中的密码。
The pseudocode description of the algorithm uses the following notation:
算法的伪代码描述使用以下符号：
o ":=": The variable on the left-hand side represents the octet string resulting from the expression on the right-hand side.
o “：=”：左侧的变量表示由右侧表达式生成的八位字节字符串。
o "+": Octet string concatenation.
o “+”：八位字符串串联。
o "[ ]": A portion of an expression enclosed in "[" and "]" is optional in the result under some circumstances. See the associated text for a description of those circumstances.
o “[]”：在某些情况下，包含在“[”和“]”中的表达式的一部分在结果中是可选的。有关这些情况的说明，请参阅相关文本。
o Normalize(str): Apply the Preparation and Enforcement steps according to the OpaqueString profile (see [RFC7613]) to a UTF-8 [RFC3629] encoded "str". The resulting string is also in UTF-8. Note that implementations MUST either implement OpaqueString profile operations from [RFC7613] or disallow the use of non US-ASCII Unicode codepoints in "str". The latter is a particular case of compliance with [RFC7613].
o 规范化（str）：根据OpaqueString配置文件（参见[RFC7613]）将准备和实施步骤应用于UTF-8[RFC3629]编码的“str”。结果字符串也是UTF-8格式。请注意，实现必须从[RFC7613]实现OpaqueString配置文件操作，或者禁止在“str”中使用非US-ASCII Unicode码点。后者是符合[RFC7613]的特殊情况。
o 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 32 octets for SHA-256 and 20 octets for SHA-1 (see [RFC6234]).
o HMAC（key，str）：应用HMAC键控哈希算法（在[RFC2104]中定义），使用由“key”表示的八位字符串作为键，八位字符串“str”作为输入字符串。结果的大小是正在使用的哈希函数的哈希结果大小。例如，SHA-256为32个八位字节，SHA-1为20个八位字节（参见[RFC6234]）。
o 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.
o H（str）：将加密哈希函数应用于八位字节字符串“str”，从而生成一个八位字节字符串。结果的大小取决于正在使用的哈希函数的哈希结果大小。
o 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.
o 异或：应用异或操作将此运算符左侧的八位字节字符串与此运算符右侧的八位字节字符串组合起来。对于该用途，输出和两个输入的长度将相同。
o Hi(str, salt, i):
o 你好（str，salt，i）：
U1 := HMAC(str, salt + INT(1))
U2 := HMAC(str, U1)
...
Ui-1 := HMAC(str, Ui-2)
Ui := HMAC(str, Ui-1)
U1 := HMAC(str, salt + INT(1))
U2 := HMAC(str, U1)
...
Ui-1 := HMAC(str, Ui-2)
Ui := HMAC(str, Ui-1)
Hi := U1 XOR U2 XOR ... XOR Ui
嗨：=U1异或U2异或。。。异或用户界面
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.
其中，“i”是迭代计数，“+”是字符串串联运算符，INT（g）是整数g的四个八位编码，最重要的八位位组在前。
Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the Pseudorandom Function (PRF) and with dkLen == output length of HMAC() == output length of H().
Hi（）本质上是PBKDF2[RFC2898]，其中HMAC（）作为伪随机函数（PRF），dkLen==HMAC（）的输出长度==H（）的输出长度。
The following is a description of a full HTTP SCRAM authentication exchange. Note that this section omits some details, such as client and server nonces. See Section 5 for more details.
以下是完整HTTP紧急停堆身份验证交换的说明。请注意，本节省略了一些细节，例如客户端和服务器nonce。详见第5节。
To begin with, the SCRAM client is in possession of a username and password, both encoded in UTF-8 [RFC3629] (or a ClientKey/ServerKey, or SaltedPassword). It sends the username to the server, which retrieves the corresponding authentication information: a salt, a StoredKey, a ServerKey, and an iteration count ("i"). (Note that a server implementation may choose to use the same iteration count for all accounts.) 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:
首先，紧急停堆客户机拥有一个用户名和密码，均以UTF-8[RFC3629]（或ClientKey/ServerKey或SaltedPassword）编码。它将用户名发送到服务器，服务器检索相应的身份验证信息：salt、StoredKey、ServerKey和迭代计数（“i”）。（请注意，服务器实现可能会选择对所有帐户使用相同的迭代计数。）服务器将salt和迭代计数发送给客户端，然后客户端计算以下值并向服务器发送ClientProof：
Informative Note: Implementors are encouraged to create test cases that use both usernames and passwords with non-ASCII codepoints. In particular, it is useful to test codepoints whose Unicode Normalization Canonical Composition (NFC) and Unicode Normalization Form Compatibility Composition (NFKC) are different (see [Unicode-UAX15]). Some examples of such codepoints include Vulgar Fraction One Half (U+00BD) and Acute Accent (U+00B4).
信息性说明：鼓励实现者创建使用用户名和密码以及非ASCII代码点的测试用例。特别是，测试Unicode规范化规范组合（NFC）和Unicode规范化表单兼容性组合（NFKC）不同的代码点非常有用（请参见[Unicode-UAX15]）。这种代码点的一些例子包括粗俗的分数一半（U+00BD）和尖锐的重音（U+00B4）。
SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," +
server-first-message + "," +
client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof := ClientKey XOR ClientSignature
ServerKey := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage)
SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," +
server-first-message + "," +
client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof := ClientKey XOR ClientSignature
ServerKey := HMAC(SaltedPassword, "Server Key")
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.
服务器通过计算ClientSignature对客户端进行身份验证，使用ClientProof独占ORing恢复ClientKey，并通过应用哈希函数并将结果与StoredKey进行比较来验证ClientKey的正确性。如果ClientKey是正确的，这证明客户端可以访问用户的密码。
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, this proves that the server had access to the user's ServerKey.
类似地，客户端通过计算ServerSignature并将其与服务器发送的值进行比较来验证服务器。如果两者相等，则证明服务器可以访问用户的ServerKey。
For initial authentication, the AuthMessage is computed by concatenating decoded "data" attribute values from the authentication exchange. The format of each of these 3 decoded "data" attributes is defined in [RFC5802].
对于初始身份验证，通过连接来自身份验证交换的解码“数据”属性值来计算AuthMessage。[RFC5802]中定义了这3个解码“数据”属性的格式。
A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" followed by the uppercased name of the underlying hash function taken from the IANA "Hash Function Textual Names" registry (see <http://www.iana.org/assignments/hash-function-text-names>).
紧急停堆机制名称（身份验证方案）是一个字符串“SCRAM-”，后跟从IANA“哈希函数文本名称”注册表中获取的底层哈希函数的大写名称（请参阅<http://www.iana.org/assignments/hash-function-text-names>).
For interoperability, all HTTP clients and servers supporting SCRAM MUST implement the SCRAM-SHA-256 authentication mechanism, i.e., an authentication mechanism from the SCRAM family that uses the SHA-256 hash function as defined in [RFC7677].
为了实现互操作性，所有支持SCRAM的HTTP客户端和服务器必须实现SCRAM-SHA-256身份验证机制，即，使用[RFC7677]中定义的SHA-256哈希函数的SCRAM系列身份验证机制。
HTTP SCRAM is an HTTP Authentication mechanism whose client response (<credentials-scram>) and server challenge (<challenge-scram>) messages are text-based messages containing one or more attribute-value pairs separated by commas. The messages and their attributes are described below and defined in Section 7.
HTTP SCRAM是一种HTTP身份验证机制，其客户端响应（<credentials SCRAM>）和服务器质询（<challenge SCRAM>）消息是基于文本的消息，包含一个或多个由逗号分隔的属性值对。下文对消息及其属性进行了描述，并在第7节中进行了定义。
challenge-scram = scram-name [1*SP 1#auth-param] ; Complies with <challenge> ABNF from RFC 7235. ; Included in the WWW-Authenticate header field.
挑战紧急停堆=紧急停堆名称[1*SP 1#验证参数]；符合RFC 7235中的ABNF；包含在WWW-Authenticate标头字段中。
credentials-scram = scram-name [1*SP 1#auth-param] ; Complies with <credentials> from RFC 7235. ; Included in the Authorization header field.
凭证紧急停堆=紧急停堆名称[1*SP 1#验证参数]；符合RFC 7235中的<credentials>；包括在授权标头字段中。
scram-name = "SCRAM-SHA-256" / "SCRAM-SHA-1" / other-scram-name
; SCRAM-SHA-256 and SCRAM-SHA-1 are registered by this RFC.
;
; SCRAM-SHA-1 is registered for database compatibility
; with implementations of RFC 5802 (such as IMAP or Extensible
Messaging and Presence Protocol (XMPP)
; servers), but it is not recommended for new deployments.
scram-name = "SCRAM-SHA-256" / "SCRAM-SHA-1" / other-scram-name
; SCRAM-SHA-256 and SCRAM-SHA-1 are registered by this RFC.
;
; SCRAM-SHA-1 is registered for database compatibility
; with implementations of RFC 5802 (such as IMAP or Extensible
Messaging and Presence Protocol (XMPP)
; servers), but it is not recommended for new deployments.
other-scram-name = "SCRAM-" hash-name
; hash-name is a capitalized form of names from IANA.
; "Hash Function Textual Names" registry.
; Additional SCRAM names must be registered in both
; the IANA "SASL Mechanisms" registry
; and the IANA "HTTP Authentication Schemes" registry.
other-scram-name = "SCRAM-" hash-name
; hash-name is a capitalized form of names from IANA.
; "Hash Function Textual Names" registry.
; Additional SCRAM names must be registered in both
; the IANA "SASL Mechanisms" registry
; and the IANA "HTTP Authentication Schemes" registry.
This is a simple example of a SCRAM-SHA-256 authentication exchange (no support for channel bindings, as this feature is not currently supported by HTTP). Username 'user' and password 'pencil' are used. Note that long lines are folded for readability.
这是一个简单的SCRAM-SHA-256身份验证交换示例（不支持通道绑定，因为HTTP当前不支持此功能）。使用用户名“user”和密码“pencil”。请注意，为了便于阅读，长行是折叠的。
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com"
S: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com"
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K
C: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: SCRAM-SHA-256
sid=AAAABBBBCCCCDDDD,
data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK
S: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: SCRAM-SHA-256
sid=AAAABBBBCCCCDDDD,
data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
TUhnc3FtbWl6N0FuZFZRPQo=
C: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
TUhnc3FtbWl6N0FuZFZRPQo=
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
In the above example, the first client request contains a "data" attribute that base64 decodes as follows:
在上面的示例中，第一个客户端请求包含base64解码如下的“data”属性：
n,,n=user,r=rOprNGfwEbeRWgbNEkqO
n、 ，n=user，r=rOprNGfwEbeRWgbNEkqO
The server then responds with a "data" attribute that base64 decodes as follows:
然后，服务器使用base64解码的“数据”属性进行响应，如下所示：
r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soE
sUEjb6gQ==,i=4096
r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soE
sUEjb6gQ==,i=4096
The next client request contains a "data" attribute that base64 decodes as follows:
下一个客户端请求包含base64解码的“数据”属性，如下所示：
c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZap
WIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=
c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZap
WIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=
The final server response contains a "data" attribute that base64 decodes as follows:
最终的服务器响应包含一个“数据”属性，base64将其解码如下：
v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=
v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=
Note that in the example above, the client can also initiate SCRAM authentication without first being prompted by the server.
请注意，在上面的示例中，客户端也可以启动紧急停堆身份验证，而无需首先得到服务器的提示。
Initial "SCRAM-SHA-256" authentication starts with sending the Authorization request header field (defined by HTTP/1.1, Part 7 [RFC7235]) containing the "SCRAM-SHA-256" authentication scheme and the following attributes:
初始“SCRAM-SHA-256”身份验证从发送包含“SCRAM-SHA-256”身份验证方案和以下属性的授权请求标头字段（由HTTP/1.1第7部分[RFC7235]定义）开始：
o A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. As specified in [RFC7235], the "realm" attribute MUST NOT appear more than once. The "realm" attribute only appears in the first SCRAM message to the server and in the first SCRAM response from the server.
o 可以包括“realm”属性，以按照HTTP/1.1第7部分[RFC7235]中描述的方式指示保护范围。如[RFC7235]所述，“realm”属性不能出现多次。“领域”属性仅出现在发送给服务器的第一条紧急停堆消息和来自服务器的第一条紧急停堆响应中。
o The client also includes the "data" attribute that contains the base64-encoded "client-first-message" [RFC5802] containing:
o 客户端还包括“数据”属性，该属性包含base64编码的“客户端第一条消息”[RFC5802]，其中包含：
* a header consisting of a flag indicating whether channel binding is supported-but-not-used, not supported, or used. Note that this version of SCRAM doesn't support HTTP channel bindings, so this header always starts with "n"; otherwise, the message is invalid and authentication MUST fail.
* 由一个标志组成的标头，该标志指示是否支持但未使用、不支持或已使用通道绑定。请注意，此版本的紧急停堆不支持HTTP通道绑定，因此此标头始终以“n”开头；否则，消息无效，身份验证必须失败。
* SCRAM username and a random, unique "nonce" attribute.
* 紧急停堆用户名和随机、唯一的“nonce”属性。
In an HTTP response, the server sends the WWW-Authenticate header field containing a unique session identifier (the "sid" attribute) plus the "data" attribute containing the base64-encoded "server-first-message" [RFC5802]. The "server-first-message" contains the user's iteration count i, the user's salt, and the nonce with a concatenation of the client-specified one (taken from the "client-first-message") with a freshly generated server nonce.
在HTTP响应中，服务器发送包含唯一会话标识符（“sid”属性）和包含base64编码的“服务器第一条消息”[RFC5802]的“数据”属性的WWW Authenticate标头字段。“服务器第一条消息”包含用户的迭代计数i、用户的salt和nonce，其中包含客户机指定的一个（取自“客户机第一条消息”）与新生成的服务器nonce的串联。
The client then responds with another HTTP request with the Authorization header field, which includes the "sid" attribute received in the previous server response, together with the "data" attribute containing base64-encoded "client-final-message" data. The latter has the same nonce as in "server-first-message" and a ClientProof computed using the selected hash function (e.g., SHA-256) as explained earlier.
然后，客户机用另一个HTTP请求响应，该请求带有授权标头字段，该字段包括在上一个服务器响应中接收到的“sid”属性，以及包含base64编码的“客户机最终消息”数据的“data”属性。后者具有与“服务器第一条消息”中相同的nonce，并且如前所述，使用所选哈希函数（例如，SHA-256）计算ClientProof。
The server verifies the nonce and the proof, and, finally, it responds with a 200 HTTP response with the Authentication-Info header field [RFC7615] containing the "sid" attribute (as received from the client) and the "data" attribute containing the base64-encoded "server-final-message", concluding the authentication exchange.
服务器验证nonce和proof，最后，它使用包含“sid”属性（从客户端接收）的Authentication Info header字段[RFC7615]和包含base64编码的“server final message”的“data”属性的200 HTTP响应进行响应，从而结束身份验证交换。
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.
然后，客户机通过计算ServerSignature并将其与服务器发送的值进行比较来验证服务器。如果两个是不同的，则客户端必须考虑认证交换失败，并且可能不得不放弃连接。
If the server supports SCRAM reauthentication, the server sends in its initial HTTP response a WWW-Authenticate header field containing the "realm" attribute (as defined earlier), the "sr" attribute that contains the server part of the "r" attribute (see s-nonce in [RFC5802]), and an optional "ttl" attribute (which contains the "sr" value validity in seconds).
如果服务器支持紧急停堆重新身份验证，则服务器在其初始HTTP响应中发送一个包含“realm”属性（如前所述）、包含“r”属性的服务器部分的“sr”属性（参见[RFC5802]中的s-nonce）和可选的“ttl”属性（其中包含“sr”属性）的WWW Authenticate标头字段值（以秒为单位）。
If the client has authenticated to the same realm before (i.e., it remembers "i" and "s" attributes for the user from earlier authentication exchanges with the server), it can respond to that with "client-final-message". When constructing the "client-final-message", the client constructs the c-nonce part of the "r" attribute as on initial authentication and the s-nonce part as follows: s-nonce is a concatenation of nonce-count and the "sr" attribute (in that order). The nonce-count is a positive integer that is equal to the user's "i" attribute on first reauthentication and is incremented by 1 on each successful reauthentication.
如果客户机之前已经对同一领域进行了身份验证（即，它记住了用户在与服务器的早期身份验证交换中的“i”和“s”属性），则它可以使用“客户机最终消息”响应该属性。在构造“客户机最终消息”时，客户机在初始身份验证时构造“r”属性的c-nonce部分，s-nonce部分如下：s-nonce是nonce计数和“sr”属性（按该顺序）的串联。nonce计数是一个正整数，在第一次重新身份验证时等于用户的“i”属性，并且在每次成功重新身份验证时递增1。
The purpose of the nonce-count is to allow the server to detect request replays by maintaining its own copy of this count -- if the same nonce-count value is seen twice, then the request is a replay.
nonce计数的目的是允许服务器通过维护自己的该计数副本来检测请求重播——如果相同的nonce计数值出现两次，则该请求是重播。
If the server considers the s-nonce part of the "nonce" attribute (the "r" attribute) to still be valid (i.e., the nonce-count part is as expected (see above) and the "sr" part is still fresh), it will provide access to the requested resource (assuming the client hash verifies correctly, of course). However, if the server considers that the server part of the nonce is stale (for example, if the "sr" value is used after the "ttl" seconds), the server returns "401 Unauthorized" containing the SCRAM mechanism name with the following attributes: a new "sr", "stale=true", and an optional "ttl". The "stale" attribute signals to the client that there is no need to ask the user for the password.
如果服务器认为“nonce”属性（“r”属性）的s-nonce部分仍然有效（即，nonce count部分如预期的那样（见上文）而“sr”部分仍然是新的），它将提供对请求的资源的访问（当然，假设客户端哈希正确验证）。但是，如果服务器认为nonce的服务器部分过时（例如，如果在“ttl”秒之后使用“sr”值），则服务器返回“401 Unauthorized”，其中包含紧急停堆机制名称，并具有以下属性：新的“sr”、“stale=true”和可选的“ttl”。“stale”属性向客户端发出信号，表示无需向用户请求密码。
Formally, the "stale" attribute is defined as a flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE (case-insensitive), the client may wish to simply retry the request with a new encrypted response without reprompting the user for a new username and password. The server should only set stale to TRUE if it receives a request for which the nonce is invalid but with a valid digest for that nonce (indicating that the client knows the correct username/password). If stale is FALSE or anything other than TRUE, or the stale directive is not present, the username and/or password are invalid, and new values must be obtained.
在形式上，“stale”属性被定义为一个标志，表示由于nonce值是stale的，来自客户端的上一个请求被拒绝。如果stale为TRUE（不区分大小写），则客户端可能只希望使用新的加密响应重试请求，而无需为用户重新输入新的用户名和密码。只有当服务器接收到一个nonce无效但具有该nonce的有效摘要（指示客户端知道正确的用户名/密码）的请求时，才应将stale设置为TRUE。如果stale为FALSE或TRUE以外的任何值，或者stale指令不存在，则用户名和/或密码无效，必须获取新值。
When constructing AuthMessage (see Section 3) to be used for calculating client and server proofs, "client-first-message-bare" and "server-first-message" are reconstructed from data known to the client and the server.
在构造用于计算客户机和服务器证明的AuthMessage（参见第3节）时，“客户机第一条消息”和“服务器第一条消息”是根据客户机和服务器已知的数据重建的。
Reauthentication can look like this:
重新验证可以如下所示：
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com", sr=%hvYDpWUa2RaTC
AfuxFIlj)hNlF
SCRAM-SHA-256 realm="testrealm2@example.com", sr=AAABBBCCCDDD,
ttl=120
S: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com", sr=%hvYDpWUa2RaTC
AfuxFIlj)hNlF
SCRAM-SHA-256 realm="testrealm2@example.com", sr=AAABBBCCCDDD,
ttl=120
S: [...]
[The client authenticates as usual to realm "testrealm@example.com"] [Some time later, client decides to reauthenticate. It will use the cached "i" (4096) and "s" (W22ZaJ0SNY7soEsUEjb6gQ==) from earlier exchanges. It will use the nonce-value of 4096 together with the server advertised "sr" value as the server part of the "r".]
[客户端像往常一样对域进行身份验证”testrealm@example.com“][一段时间后，客户端决定重新验证。它将使用先前交换中缓存的“i”（4096）和“s”（W22ZaJ0SNY7soEsUEjb6gQ==）。它将使用4096的nonce值和服务器公布的“sr”值作为“r”的服务器部分。]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM
lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX
pqZk1IZ3NxbW1pejdBbmRWUT0K
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM
lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX
pqZk1IZ3NxbW1pejdBbmRWUT0K
C: [...]
C:[…]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
When used with SCRAM, the Authentication-Info header field is allowed in the trailer of an HTTP message transferred via chunked transfer-coding.
当与紧急停堆一起使用时，通过分块传输编码传输的HTTP消息的尾部中允许使用Authentication Info header字段。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
以下语法规范使用[RFC5234]中指定的增广巴科斯诺尔形式（ABNF）表示法。
ALPHA = <as defined in RFC 5234 Appendix B.1>
DIGIT = <as defined in RFC 5234 Appendix B.1>
ALPHA = <as defined in RFC 5234 Appendix B.1>
DIGIT = <as defined in RFC 5234 Appendix B.1>
base64-char = ALPHA / DIGIT / "/" / "+"
base64-char = ALPHA / DIGIT / "/" / "+"
base64-4 = 4base64-char
base64-4 = 4base64-char
base64-3 = 3base64-char "="
base64-3=3base64字符“=”
base64-2 = 2base64-char "=="
base64-2 = 2base64-char "=="
base64 = *base64-4 [base64-3 / base64-2]
base64 = *base64-4 [base64-3 / base64-2]
sr = "sr=" s-nonce ;; s-nonce is defined in RFC 5802.
sr=“sr=”s-nonce；；s-nonce在RFC 5802中定义。
data = "data=" base64
;; The "data" attribute value is base64-encoded
;; SCRAM challenge or response defined in
;; RFC 5802.
data = "data=" base64
;; The "data" attribute value is base64-encoded
;; SCRAM challenge or response defined in
;; RFC 5802.
ttl = "ttl=" 1*DIGIT ;; "sr" value validity in seconds. ;; No leading 0s.
ttl=“ttl=”1*位；；“sr”值有效期（秒）；；没有前导0。
reauth-s-nonce = nonce-count s-nonce
reauth-s-nonce = nonce-count s-nonce
nonce-count = posit-number
;; posit-number is defined in RFC 5802.
;; The initial value is taken from the "i"
;; attribute for the user and is incremented
;; by 1 on each successful reauthentication.
nonce-count = posit-number
;; posit-number is defined in RFC 5802.
;; The initial value is taken from the "i"
;; attribute for the user and is incremented
;; by 1 on each successful reauthentication.
sid = "sid=" token ;; See token definition in RFC 7235.
sid=“sid=”令牌；；请参阅RFC 7235中的令牌定义。
stale = "stale=" ( "true" / "false" )
stale = "stale=" ( "true" / "false" )
realm = "realm=" <as defined in RFC 7235>
realm = "realm=" <as defined in RFC 7235>
If the authentication exchange is performed without a strong session encryption (such as TLS with data confidentiality), then a passive eavesdropper can gain sufficient information to mount an offline dictionary or brute-force attack that 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. SCRAM allows the server/server administrator to increase the iteration count over time in order to slow down the above attacks. (Note that a server that is only in possession of StoredKey and ServerKey can't automatically increase the iteration count upon successful authentication. Such an increase would require resetting the user's password.) An external security layer with strong encryption will prevent these attacks.
如果在没有强会话加密（例如具有数据机密性的TLS）的情况下执行身份验证交换，则被动窃听者可以获得足够的信息来装载离线字典或暴力攻击，这些攻击可用于恢复用户的密码。此攻击所需的时间取决于选择的加密哈希函数、密码强度和服务器提供的迭代计数。紧急停堆允许服务器/服务器管理员随时间增加迭代次数，以减缓上述攻击。（请注意，仅拥有StoredKey和ServerKey的服务器无法在成功身份验证后自动增加迭代次数。这种增加需要重置用户密码。）具有强加密的外部安全层将防止这些攻击。
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 that protect against this attack are available (e.g., the Encrypted Key Exchange (EKE) class of mechanisms). RFC 2945 [RFC2945] is an example of such technology.
如果身份验证信息从身份验证数据库中被盗，则可以使用脱机字典或暴力攻击来恢复用户的密码。使用salt需要对每个密码进行单独的攻击，从而在一定程度上减轻了这种攻击。可以使用防止此攻击的身份验证机制（例如，加密密钥交换（EKE）类机制）。RFC 2945[RFC2945]就是这种技术的一个例子。
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.
如果攻击者从身份验证存储库获取身份验证信息，并在一个身份验证交换上进行窃听或模拟服务器，则攻击者可以使用相同的哈希函数、密码、迭代计数和salt将该用户模拟到提供紧急停堆访问的所有服务器。因此，使用随机生成的盐值非常重要。
SCRAM does not negotiate which hash function to use. Hash function negotiation is left to the HTTP authentication mechanism negotiation. It is important that clients be able to sort a locally available list of mechanisms by preference so that the client may pick the most preferred of a server's advertised mechanism list. This preference order is not specified here as it is a local matter. The preference order should include objective and subjective notions of mechanism cryptographic strength (e.g., SCRAM with SHA-256 should be preferred over SCRAM with SHA-1).
紧急停堆不会协商使用哪个哈希函数。哈希函数协商留给HTTP身份验证机制协商。重要的是，客户端能够按首选项对本地可用的机制列表进行排序，以便客户端可以从服务器的广告机制列表中选择最首选的机制。此处未指定此优先顺序，因为这是一个局部问题。优先顺序应包括机制加密强度的客观和主观概念（例如，使用SHA-256的紧急停堆应优先于使用SHA-1的紧急停堆）。
This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1 is registered for database compatibility with implementations of RFC 5802 (such as IMAP or XMPP servers) that want to also expose HTTP access to a related service, but it is not recommended for new deployments.
本文件建议对SHA-256哈希使用紧急停堆。SCRAM-SHA-1注册是为了与RFC 5802实现（如IMAP或XMPP服务器）的数据库兼容性，这些实现还希望公开对相关服务的HTTP访问，但不建议用于新部署。
A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value. In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).
恶意服务器可以通过发送较大的迭代计数值对客户端执行计算拒绝服务攻击。为了防止这种情况，客户机实现可以选择它愿意使用的最大迭代次数，并拒绝任何超过该阈值的值（在这种情况下，客户机当然必须通过身份验证）。
See [RFC4086] for more information about generating randomness.
有关生成随机性的更多信息，请参见[RFC4086]。
New mechanisms in the SCRAM family are registered according to the IANA procedure specified in [RFC5802].
紧急停堆系列中的新机制根据[RFC5802]中规定的IANA程序进行登记。
Note to future "SCRAM-" mechanism designers: Each new "SCRAM-" HTTP authentication mechanism MUST be explicitly registered with IANA and MUST comply with "SCRAM-" mechanism naming convention defined in Section 4 of this document.
未来“紧急停堆”机制设计者注意：每个新的“紧急停堆”HTTP认证机制必须向IANA明确注册，并且必须符合本文件第4节中定义的“紧急停堆”机制命名约定。
IANA has added the following entries to the "HTTP Authentication Schemes" registry defined in HTTP/1.1, Part 7 [RFC7235]:
IANA已将以下条目添加到HTTP/1.1第7部分[RFC7235]中定义的“HTTP身份验证方案”注册表中：
Authentication Scheme Name: SCRAM-SHA-256 Pointer to specification text: RFC 7804 Notes (optional): (none)
认证方案名称：SCRAM-SHA-256指向规范文本的指针：RFC 7804注释（可选）：（无）
Authentication Scheme Name: SCRAM-SHA-1 Pointer to specification text: RFC 7804 Notes (optional): (none)
认证方案名称：SCRAM-SHA-1规范文本指针：RFC 7804注释（可选）：（无）
The following design goals shaped this document. Note that some of the goals have changed since the initial draft version of the document.
以下设计目标形成了本文档。请注意，自文件初稿以来，一些目标已经发生了变化。
o The HTTP authentication mechanism has all modern features: support for internationalized usernames and passwords.
o HTTP身份验证机制具有所有现代功能：支持国际化用户名和密码。
o The protocol supports mutual authentication.
o 该协议支持相互认证。
o The authentication information stored in the authentication database is not sufficient by itself to impersonate the client.
o 存储在身份验证数据库中的身份验证信息本身不足以模拟客户端。
o The server does not gain the ability to impersonate the client to other servers (with an exception for server-authorized proxies), unless such other servers allow SCRAM authentication and use the same salt and iteration count for the user.
o 服务器无法向其他服务器模拟客户端（服务器授权代理除外），除非此类其他服务器允许紧急停堆身份验证并对用户使用相同的salt和迭代计数。
o The mechanism is extensible, but (hopefully) not over-engineered in this respect.
o 该机制是可扩展的，但（希望）在这方面没有过度设计。
o The mechanism is easier to implement than HTTP Digest in both clients and servers.
o 在客户端和服务器中，该机制比HTTP摘要更容易实现。
o The protocol supports 1 round-trip reauthentication.
o 该协议支持1次往返重新验证。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, <http://www.rfc-editor.org/info/rfc5802>.
[RFC5802]Newman，C.，Menon Sen，A.，Melnikov，A.，和N.Williams，“盐渍挑战响应认证机制（SCRAM）SASL和GSS-API机制”，RFC 5802，DOI 10.17487/RFC5802，2010年7月<http://www.rfc-editor.org/info/rfc5802>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.
[RFC7613]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 7613，DOI 10.17487/RFC7613，2015年8月<http://www.rfc-editor.org/info/rfc7613>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>.
[RFC7615]Reschke，J.，“HTTP身份验证信息和代理身份验证信息响应头字段”，RFC 7615，DOI 10.17487/RFC7615，2015年9月<http://www.rfc-editor.org/info/rfc7615>.
[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", RFC 7677, DOI 10.17487/RFC7677, November 2015, <http://www.rfc-editor.org/info/rfc7677>.
[RFC7677]Hansen，T.，“SCRAM-SHA-256和SCRAM-SHA-256-PLUS简单认证和安全层（SASL）机制”，RFC 7677，DOI 10.17487/RFC7677，2015年11月<http://www.rfc-editor.org/info/rfc7677>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, <http://www.rfc-editor.org/info/rfc2898>.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 2898，DOI 10.17487/RFC2898，2000年9月<http://www.rfc-editor.org/info/rfc2898>.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, DOI 10.17487/RFC2945, September 2000, <http://www.rfc-editor.org/info/rfc2945>.
[RFC2945]Wu，T，“SRP认证和密钥交换系统”，RFC 2945，DOI 10.17487/RFC2945，2000年9月<http://www.rfc-editor.org/info/rfc2945>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, DOI 10.17487/RFC4510, June 2006, <http://www.rfc-editor.org/info/rfc4510>.
[RFC4510]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC 4510，DOI 10.17487/RFC4510，2006年6月<http://www.rfc-editor.org/info/rfc4510>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, DOI 10.17487/RFC6331, July 2011, <http://www.rfc-editor.org/info/rfc6331>.
[RFC6331]梅尔尼科夫，A，“将摘要-MD5转化为历史”，RFC 6331DOI 10.17487/RFC63311911年7月<http://www.rfc-editor.org/info/rfc6331>.
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", June 2015, <http://www.unicode.org/reports/tr15/>.
[Unicode-UAX15]Unicode联盟，“Unicode标准附录#15：Unicode规范化表单”，2015年6月<http://www.unicode.org/reports/tr15/>.
Acknowledgements
致谢
This document benefited from discussions on the mailing lists for the HTTPAuth, SASL, and Kitten working groups. The author would like to specially thank the co-authors of [RFC5802] from which lots of text was copied.
本文件得益于HTTPAuth、SASL和Kitten工作组邮件列表的讨论。作者要特别感谢[RFC5802]的共同作者，他们从中复制了大量文本。
Thank you to Martin Thomson for the idea of adding the "ttl" attribute.
感谢Martin Thomson提出添加“ttl”属性的想法。
Thank you to Julian F. Reschke for corrections regarding use of the Authentication-Info header field.
感谢Julian F.Reschke对身份验证信息标题字段使用的更正。
A special thank you to Tony Hansen for doing an early implementation and providing extensive comments on the document.
特别感谢Tony Hansen尽早实施并对该文件提出了广泛的意见。
Thank you to Russ Housley, Stephen Farrell, Barry Leiba, and Tim Chown for doing detailed reviews of the document.
感谢Russ Housley、Stephen Farrell、Barry Leiba和Tim Chown对该文件进行了详细审查。
Author's Address
作者地址
Alexey Melnikov Isode Ltd
阿列克谢·梅尔尼科夫伊索德有限公司
Email: Alexey.Melnikov@isode.com
Email: Alexey.Melnikov@isode.com