Internet Engineering Task Force (IETF) R. Shekh-Yusef, Ed.
Request for Comments: 7616 Avaya
Obsoletes: 2617 D. Ahrens
Category: Standards Track Independent
ISSN: 2070-1721 S. Bremer
Netzkonform
September 2015
Internet Engineering Task Force (IETF) R. Shekh-Yusef, Ed.
Request for Comments: 7616 Avaya
Obsoletes: 2617 D. Ahrens
Category: Standards Track Independent
ISSN: 2070-1721 S. Bremer
Netzkonform
September 2015
HTTP Digest Access Authentication
HTTP摘要访问身份验证
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.
超文本传输协议（HTTP）提供了一种简单的质询-响应身份验证机制，服务器可使用该机制质询客户端请求，客户端可使用该机制提供身份验证信息。本文档定义了可与HTTP身份验证机制一起使用的HTTP摘要身份验证方案。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7616.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7616.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Syntax Convention . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Digest Access Authentication Scheme . . . . . . . . . . . . . 5
3.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 5
3.2. Representation of Digest Values . . . . . . . . . . . . . 5
3.3. The WWW-Authenticate Response Header Field . . . . . . . 5
3.4. The Authorization Header Field . . . . . . . . . . . . . 9
3.4.1. Response . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2. A1 . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3. A2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.4. Username Hashing . . . . . . . . . . . . . . . . . . 12
3.4.5. Parameter Values and Quoted-String . . . . . . . . . 12
3.4.6. Various Considerations . . . . . . . . . . . . . . . 13
3.5. The Authentication-Info and Proxy-Authentication-Info
Header Fields . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Digest Operation . . . . . . . . . . . . . . . . . . . . 15
3.7. Security Protocol Negotiation . . . . . . . . . . . . . . 16
3.8. Proxy-Authenticate and Proxy-Authorization . . . . . . . 17
3.9. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18
3.9.1. Example with SHA-256 and MD5 . . . . . . . . . . . . 18
3.9.2. Example with SHA-512-256, Charset, and Userhash . . . 19
4. Internationalization Considerations . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Storing Passwords . . . . . . . . . . . . . . . . . . . . 21
5.3. Authentication of Clients Using Digest Authentication . . 22
5.4. Limited-Use Nonce Values . . . . . . . . . . . . . . . . 23
5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23
5.6. Weakness Created by Multiple Authentication Schemes . . . 24
5.7. Online Dictionary Attacks . . . . . . . . . . . . . . . . 24
5.8. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25
5.9. Chosen Plaintext Attacks . . . . . . . . . . . . . . . . 25
5.10. Precomputed Dictionary Attacks . . . . . . . . . . . . . 26
5.11. Batch Brute-Force Attacks . . . . . . . . . . . . . . . . 26
5.12. Parameter Randomness . . . . . . . . . . . . . . . . . . 26
5.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. Hash Algorithms for HTTP Digest Authentication . . . . . 27
6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Syntax Convention . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Digest Access Authentication Scheme . . . . . . . . . . . . . 5
3.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 5
3.2. Representation of Digest Values . . . . . . . . . . . . . 5
3.3. The WWW-Authenticate Response Header Field . . . . . . . 5
3.4. The Authorization Header Field . . . . . . . . . . . . . 9
3.4.1. Response . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2. A1 . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3. A2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.4. Username Hashing . . . . . . . . . . . . . . . . . . 12
3.4.5. Parameter Values and Quoted-String . . . . . . . . . 12
3.4.6. Various Considerations . . . . . . . . . . . . . . . 13
3.5. The Authentication-Info and Proxy-Authentication-Info
Header Fields . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Digest Operation . . . . . . . . . . . . . . . . . . . . 15
3.7. Security Protocol Negotiation . . . . . . . . . . . . . . 16
3.8. Proxy-Authenticate and Proxy-Authorization . . . . . . . 17
3.9. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18
3.9.1. Example with SHA-256 and MD5 . . . . . . . . . . . . 18
3.9.2. Example with SHA-512-256, Charset, and Userhash . . . 19
4. Internationalization Considerations . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Storing Passwords . . . . . . . . . . . . . . . . . . . . 21
5.3. Authentication of Clients Using Digest Authentication . . 22
5.4. Limited-Use Nonce Values . . . . . . . . . . . . . . . . 23
5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23
5.6. Weakness Created by Multiple Authentication Schemes . . . 24
5.7. Online Dictionary Attacks . . . . . . . . . . . . . . . . 24
5.8. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25
5.9. Chosen Plaintext Attacks . . . . . . . . . . . . . . . . 25
5.10. Precomputed Dictionary Attacks . . . . . . . . . . . . . 26
5.11. Batch Brute-Force Attacks . . . . . . . . . . . . . . . . 26
5.12. Parameter Randomness . . . . . . . . . . . . . . . . . . 26
5.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. Hash Algorithms for HTTP Digest Authentication . . . . . 27
6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.
HTTP提供了一种简单的质询-响应身份验证机制，服务器可使用该机制质询客户端请求，客户端可使用该机制提供身份验证信息。本文档定义了可与HTTP身份验证机制一起使用的HTTP摘要身份验证方案。
This document extends but is generally backward compatible with [RFC2617]. See Appendix A for the new capabilities introduced by this specification.
本文档进行了扩展，但通常向后兼容[RFC2617]。有关本规范引入的新功能，请参见附录A。
The details of the challenge-response authentication mechanism are specified in the "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235].
质询-响应认证机制的详细信息在“超文本传输协议（HTTP/1.1）：认证”[RFC7235]中指定。
The combination of this document with the definition of the "Basic" authentication scheme [RFC7617], "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields" [RFC7615], and "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235] obsolete [RFC2617].
本文档与“基本”身份验证方案[RFC7617]、“HTTP身份验证信息和代理身份验证信息响应头字段”[RFC7615]和“超文本传输协议（HTTP/1.1）：身份验证”[RFC7235]的定义相结合已过时[RFC2617]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
In the interest of clarity and readability, the extended parameters or the header fields and parameters in the examples in this document might be broken into multiple lines. Any line that is indented in this document is a continuation of the preceding line.
为了清晰易读，本文档示例中的扩展参数或标题字段和参数可能会分成多行。本文件中缩进的任何一行都是前一行的延续。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] and the ABNF List Extension of [RFC7230].
本规范使用[RFC5234]的扩充巴科斯诺尔形式（ABNF）符号和[RFC7230]的ABNF列表扩展。
The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value and might indicate that username hashing is supported. A valid response contains an unkeyed digest of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear, and the username can be hashed, depending on the indication received from the server. The username and password must be prearranged in some fashion not addressed by this document.
摘要方案基于一个简单的挑战-响应范式。摘要方案对使用nonce值提出质疑，并可能表示支持用户名哈希。有效响应包含用户名、密码、给定的nonce值、HTTP方法和请求的URI的未知摘要。这样，密码永远不会以明文形式发送，并且用户名可以散列，这取决于从服务器接收到的指示。用户名和密码必须以本文档未提及的方式预先安排。
An optional header field allows the server to specify the algorithm used to create the unkeyed digest or digest. This document adds SHA-256 and SHA-512/256 algorithms. To maintain backwards compatibility with [RFC2617], the MD5 algorithm is still supported but NOT RECOMMENDED.
可选的头字段允许服务器指定用于创建未命名摘要或摘要的算法。本文档添加了SHA-256和SHA-512/256算法。为了保持与[RFC2617]的向后兼容性，仍然支持MD5算法，但不推荐使用。
The size of the digest depends on the algorithm used. The bits in the digest are converted from the most significant to the least significant bit, four bits at a time, to the ASCII representation as follows. Each sequence of four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef; that is, binary 0000 is represented by the character '0', 0001 by '1' and so on up to the representation of 1111 as 'f'. If the MD5 algorithm is used to calculate the digest, then the MD5 digest will be represented as 32 hexadecimal characters, while SHA-256 and SHA-512/256 are represented as 64 hexadecimal characters.
摘要的大小取决于所使用的算法。摘要中的位从最高有效位转换为最低有效位，一次四位，转换为ASCII表示，如下所示。每一个四位序列由其熟悉的十六进制符号表示，这些符号来自字符0123456789abcdef；也就是说，二进制0000由字符“0”表示，0001由“1”表示，以此类推，直至1111表示为“f”。如果使用MD5算法计算摘要，则MD5摘要将表示为32个十六进制字符，而SHA-256和SHA-512/256将表示为64个十六进制字符。
If a server receives a request for an access-protected object, and an acceptable Authorization header field is not sent, the server responds with a "401 Unauthorized" status code and a WWW-Authenticate header field with Digest scheme as per the framework defined above. The value of the header field can include parameters from the following list:
如果服务器接收到访问保护对象的请求，并且未发送可接受的授权标头字段，则服务器将根据上述框架使用“401 Unauthorized”状态代码和带有摘要方案的WWW Authenticate标头字段进行响应。标题字段的值可以包括以下列表中的参数：
realm
领域
A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An
要显示给用户的字符串，以便用户知道使用哪个用户名和密码。此字符串应至少包含执行身份验证的主机的名称，并可能另外指示可能具有访问权限的用户集合。一
example is "registered_users@example.com". (See Section 2.2 of [RFC7235] for more details.)
例如“注册”_users@example.com". （详见[RFC7235]第2.2节。）
domain
领域
A quoted, space-separated list of URIs, as specified in [RFC3986], that define the protection space. If a URI is a path-absolute, it is relative to the canonical root URL. (See Section 2.2 of [RFC7235].) An absolute-URI in this list may refer to a different server than the web-origin [RFC6454]. The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a prefix (after both have been made absolute) MAY be assumed to be in the same protection space. If this parameter is omitted or its value is empty, the client SHOULD assume that the protection space consists of all URIs on the web-origin.
[RFC3986]中规定的一种引用的、以空格分隔的URI列表，用于定义保护空间。如果URI是绝对路径，则它是相对于规范根URL的。（参见[RFC7235]的第2.2节）此列表中的绝对URI可能指的是与web源[RFC6454]不同的服务器。客户端可以使用此列表来确定可以为其发送相同身份验证信息的URI集：可以假定在此列表中具有URI作为前缀的任何URI（在将两者都设置为绝对后）位于相同的保护空间中。如果省略此参数或其值为空，则客户端应假定保护空间由web源上的所有URI组成。
This parameter is not meaningful in Proxy-Authenticate header fields, for which the protection space is always the entire proxy; if present, it MUST be ignored.
此参数在代理身份验证标头字段中没有意义，因为保护空间始终是整个代理；如果存在，则必须忽略它。
nonce
暂时
A server-specified string which should be uniquely generated each time a 401 response is made. It is advised that this string be Base64 or hexadecimal data. Specifically, since the string is passed in the header field lines as a quoted string, the double-quote character is not allowed, unless suitably escaped.
服务器指定的字符串，应在每次401响应时唯一生成。建议该字符串为Base64或十六进制数据。特别是，由于字符串作为带引号的字符串在标题字段行中传递，因此不允许使用双引号字符，除非进行了适当的转义。
The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. A nonce might, for example, be constructed as the Base64 encoding of
nonce的内容取决于实现。实施的质量取决于一个好的选择。例如，nonce可以构造为的Base64编码
timestamp H(timestamp ":" ETag ":" secret-data)
timestamp H(timestamp ":" ETag ":" secret-data)
where timestamp is a server-generated time, which preferably includes micro- or nanoseconds, or other non-repeating values; ETag is the value of the HTTP ETag header field associated with the requested entity; and secret-data is data known only to the server. With a nonce of this form, a server would recalculate the hash portion after receiving the client authentication header field and reject the request if it did not match the nonce from that header field or if the timestamp value is not recent enough. In this way, the server can limit the time of the nonce's validity. The inclusion of the ETag prevents a replay request for an updated version of the resource. Including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that
其中时间戳是服务器生成的时间，其优选地包括微秒或纳秒或其他非重复值；ETag是与请求的实体关联的HTTP ETag头字段的值；机密数据是只有服务器知道的数据。对于这种形式的nonce，服务器将在接收到客户端身份验证头字段后重新计算哈希部分，如果请求与来自该头字段的nonce不匹配，或者如果时间戳值不够新，则拒绝该请求。通过这种方式，服务器可以限制nonce的有效时间。ETag的包含阻止了对资源更新版本的重播请求。将客户机的IP地址包含在nonce中，似乎可以为服务器提供将nonce的重用限制到与之相同的客户机的能力
originally got it. However, that would break because requests from a single user often go through different proxies. Also, IP address spoofing is not that hard.
原来是这样的。但是，这会中断，因为来自单个用户的请求通常通过不同的代理。此外，IP地址欺骗也不是那么难。
An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a timestamp for GET requests. For more details on the issues involved, see Section 5 of this document.
为了防止重播攻击，实现可能会选择不接受以前使用的nonce或以前使用的摘要。或者，实现可以选择对POST或PUT请求使用一次性nonce或摘要，对GET请求使用时间戳。有关所涉及问题的更多详细信息，请参阅本文件第5节。
The nonce is opaque to the client.
nonce对客户端是不透明的。
opaque
不透明的
A string of data, specified by the server, that SHOULD be returned by the client unchanged in the Authorization header field of subsequent requests with URIs in the same protection space. It is RECOMMENDED that this string be Base64 or hexadecimal data.
由服务器指定的数据字符串，客户端应在同一保护空间中具有URI的后续请求的授权标头字段中原封不动地返回该字符串。建议此字符串为Base64或十六进制数据。
stale
不新鲜的
A case-insensitive flag indicating that the previous request from the client was rejected because the nonce value was stale. If stale is true, the client may wish to simply retry the request with a new encrypted response, without re-prompting 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. If stale is false, or anything other than true, or the stale parameter is not present, the username and/or password are invalid, and new values MUST be obtained.
不区分大小写的标志，指示由于nonce值过时而拒绝了来自客户端的上一个请求。如果stale为true，则客户端可能希望使用新的加密响应重试请求，而不重新提示用户输入新的用户名和密码。只有当服务器收到nonce无效的请求时，才应将stale设置为true。如果stale为false，或者除true以外的任何值，或者stale参数不存在，则用户名和/或密码无效，必须获取新值。
algorithm
算法
A string indicating an algorithm used to produce the digest and an unkeyed digest. If this is not present, it is assumed to be "MD5". If the algorithm is not understood, the challenge SHOULD be ignored (and a different one used, if there is more than one).
一个字符串，指示用于生成摘要和未命名摘要的算法。如果不存在，则假定为“MD5”。如果不理解算法，则应忽略挑战（如果存在多个挑战，则使用不同的挑战）。
When used with the Digest mechanism, each one of the algorithms has two variants: Session variant and non-Session variant. The non-Session variant is denoted by "<algorithm>", e.g., "SHA-256", and the Session variant is denoted by "<algorithm>-sess", e.g., "SHA-256-sess".
当与摘要机制一起使用时，每种算法都有两种变体：会话变体和非会话变体。非会话变量由“<algorithm>”表示，例如“SHA-256”，会话变量由“<algorithm>-sess”表示，例如“SHA-256-sess”。
In this document, the string obtained by applying the digest algorithm to the data "data" with secret "secret" will be denoted by KD(secret, data), and the string obtained by applying the
在本文档中，通过将摘要算法应用于具有机密“secret”的数据“data”而获得的字符串将用KD（secret，data）表示，并且通过应用
unkeyed digest algorithm to the data "data" will be denoted H(data). KD stands for Keyed Digest, and the notation unq(X) means the value of the quoted-string X without the surrounding quotes and with quoting slashes removed.
数据“数据”的未注释摘要算法将表示为H（数据）。KD代表键控摘要，符号unq（X）表示带引号的字符串X的值，不带引号，并且删除了引号斜杠。
For "<algorithm>" and "<algorithm>-sess"
For "<algorithm>" and "<algorithm>-sess"
H(data) = <algorithm>(data)
H(data) = <algorithm>(data)
and
和
KD(secret, data) = H(concat(secret, ":", data))
KD(secret, data) = H(concat(secret, ":", data))
For example:
例如：
For the "SHA-256" and "SHA-256-sess" algorithms
对于“SHA-256”和“SHA-256-sess”算法
H(data) = SHA-256(data)
H(data) = SHA-256(data)
i.e., the digest is the "<algorithm>" of the secret concatenated with a colon concatenated with the data. The "<algorithm>-sess" is intended to allow efficient third-party authentication servers; for the difference in usage, see the description in Section 3.4.2.
i、 例如，摘要是秘密的“<algorithm>”与与数据连接的冒号连接。“<algorithm>-sess”旨在允许高效的第三方认证服务器；有关用法的差异，请参见第3.4.2节中的说明。
qop
生活质量
This parameter MUST be used by all implementations. It is a quoted string of one or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection. See the descriptions below for calculating the response parameter value for the application of this choice. Unrecognized options MUST be ignored.
所有实现都必须使用此参数。它是一个由一个或多个令牌组成的带引号的字符串，表示服务器支持的“保护质量”值。值“auth”表示身份验证；值“auth int”表示具有完整性保护的身份验证。请参阅下面的说明，以计算此选项应用程序的响应参数值。必须忽略无法识别的选项。
charset
字符集
This is an OPTIONAL parameter that is used by the server to indicate the encoding scheme it supports. The only allowed value is "UTF-8".
这是一个可选参数，服务器使用该参数指示其支持的编码方案。唯一允许的值是“UTF-8”。
userhash
用户哈希
This is an OPTIONAL parameter that is used by the server to indicate that it supports username hashing. Valid values are: "true" or "false". Default value is "false".
这是一个可选参数，服务器使用该参数指示它支持用户名哈希。有效值为：“真”或“假”。默认值为“false”。
For historical reasons, a sender MUST only generate the quoted string syntax values for the following parameters: realm, domain, nonce, opaque, and qop.
出于历史原因，发送方只能为以下参数生成带引号的字符串语法值：realm、domain、nonce、不透明和qop。
For historical reasons, a sender MUST NOT generate the quoted string syntax values for the following parameters: stale and algorithm.
出于历史原因，发送方不得为以下参数生成带引号的字符串语法值：stale和algorithm。
The client is expected to retry the request, passing an Authorization header field line with Digest scheme, which is defined according to the framework above. The values of the opaque and algorithm fields must be those supplied in the WWW-Authenticate response header field for the entity being requested.
客户机将重试该请求，并通过根据上述框架定义的摘要方案传递授权标头字段行。不透明字段和算法字段的值必须是所请求实体的WWW Authenticate response header字段中提供的值。
The request can include parameters from the following list:
请求可以包括以下列表中的参数：
response
回答
A string of the hex digits computed as defined below; it proves that the user knows a password.
按以下定义计算的十六进制数字串；它证明用户知道密码。
username
用户名
The user's name in the specified realm. The quoted string contains the name in plaintext or the hash code in hexadecimal notation. If the username contains characters not allowed inside the ABNF quoted-string production, the username* parameter can be used. Sending both username and username* in the same header option MUST be treated as an error.
指定领域中的用户名。带引号的字符串包含明文形式的名称或十六进制表示法形式的哈希代码。如果用户名包含ABNF引号字符串产品中不允许的字符，则可以使用username*参数。在同一标题选项中发送用户名和用户名*必须视为错误。
username*
用户名*
If the userhash parameter value is set "false" and the username contains characters not allowed inside the ABNF quoted-string production, the user's name can be sent with this parameter, using the extended notation defined in [RFC5987].
如果userhash参数值设置为“false”，并且用户名包含ABNF引号字符串产品中不允许的字符，则可以使用[RFC5987]中定义的扩展符号将用户名与此参数一起发送。
realm
领域
See "realm" definition in Section 3.3.
参见第3.3节中的“领域”定义。
uri
uri
The Effective Request URI (Section 5.5 of [RFC7230]) of the HTTP request; duplicated here because proxies are allowed to change the request target ("request-target", Section 3.1.1 of [RFC7230]) in transit.
HTTP请求的有效请求URI（RFC7230第5.5节）；此处重复，因为允许代理更改传输中的请求目标（“请求目标”，RFC7230第3.1.1节）。
qop
生活质量
Indicates what "quality of protection" the client has applied to the message. Its value MUST be one of the alternatives the server indicated it supports in the WWW-Authenticate header field. These values affect the computation of the response. Note that this is a single token, not a quoted list of alternatives as in WWW-Authenticate.
指示客户端已应用于消息的“保护质量”。其值必须是服务器在WWW Authenticate标头字段中指示其支持的备选方案之一。这些值会影响响应的计算。请注意，这是一个单独的令牌，而不是WWW认证中引用的备选方案列表。
cnonce
cnonce
This parameter MUST be used by all implementations. The cnonce value is an opaque quoted ASCII-only string value provided by the client and used by both client and server to avoid chosen plaintext attacks, to provide mutual authentication, and to provide some message integrity protection. See the descriptions below of the calculation of the rspauth and response values.
所有实现都必须使用此参数。cnonce值是客户端提供的一个不透明的带引号的ASCII纯字符串值，客户端和服务器都使用它来避免选择明文攻击，提供相互身份验证，并提供一些消息完整性保护。有关rspauth和响应值的计算，请参见下面的说明。
nc
数控
This parameter MUST be used by all implementations. The nc parameter stands for "nonce count". The nc value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this parameter is to allow the server to detect request replays by maintaining its own copy of this count -- if the same nc value is seen twice, then the request is a replay. See the description below of the construction of the response value.
所有实现都必须使用此参数。nc参数表示“nonce count”。nc值是客户端使用此请求中的nonce值发送的请求数（包括当前请求）的十六进制计数。例如，在响应给定nonce值而发送的第一个请求中，客户端发送“nc=00000001”。此参数的目的是允许服务器通过维护自己的此计数副本来检测请求重播——如果相同的nc值出现两次，则该请求为重播。有关响应值的构造，请参见下面的说明。
userhash
用户哈希
This OPTIONAL parameter is used by the client to indicate that the username has been hashed. Valid values are: "true" or "false". Default value is "false".
客户端使用此可选参数指示用户名已被哈希。有效值为：“真”或“假”。默认值为“false”。
For historical reasons, a sender MUST only generate the quoted string syntax for the following parameters: username, realm, nonce, uri, response, cnonce, and opaque.
出于历史原因，发送方只能为以下参数生成带引号的字符串语法：username、realm、nonce、uri、response、cnonce和不透明。
For historical reasons, a sender MUST NOT generate the quoted string syntax for the following parameters: algorithm, qop, and nc.
出于历史原因，发送方不得为以下参数生成带引号的字符串语法：algorithm、qop和nc。
If a parameter or its value is improper, or required parameters are missing, the proper response is a 4xx error code. If the response is invalid, then a login failure SHOULD be logged, since repeated login failures from a single client may indicate an attacker attempting to
如果参数或其值不正确，或缺少必需的参数，则正确的响应为4xx错误代码。如果响应无效，则应记录登录失败，因为来自单个客户端的重复登录失败可能表示攻击者试图
guess passwords. The server implementation SHOULD be careful with the information being logged so that it won't put a cleartext password (e.g., entered into the username field) into the log.
猜猜密码。服务器实现应该小心记录信息，以免将明文密码（例如，输入用户名字段）放入日志中。
The definition of the response above indicates the encoding for its value. The following definitions show how the value is computed.
上面的响应定义表示其值的编码。以下定义显示了如何计算该值。
If the qop value is "auth" or "auth-int":
如果qop值为“auth”或“auth int”：
response = <"> < KD ( H(A1), unq(nonce)
":" nc
":" unq(cnonce)
":" unq(qop)
":" H(A2)
) <">
response = <"> < KD ( H(A1), unq(nonce)
":" nc
":" unq(cnonce)
":" unq(qop)
":" H(A2)
) <">
See below for the definitions for A1 and A2.
A1和A2的定义见下文。
If the algorithm parameter's value is "<algorithm>", e.g., "SHA-256", then A1 is:
如果算法参数的值为“<algorithm>”，例如“SHA-256”，则A1为：
A1 = unq(username) ":" unq(realm) ":" passwd
A1 = unq(username) ":" unq(realm) ":" passwd
where
哪里
passwd = < user's password >
passwd = < user's password >
If the algorithm parameter's value is "<algorithm>-sess", e.g., "SHA-256-sess", then A1 is calculated using the nonce value provided in the challenge from the server, and cnonce value from the request by the client following receipt of a WWW-Authenticate challenge from the server. It uses the server nonce from that challenge, herein called nonce-prime, and the client nonce value from the response, herein called cnonce-prime, to construct A1 as follows:
如果算法参数的值为“<algorithm>-sess”，例如“SHA-256-sess”，则使用来自服务器的质询中提供的nonce值和客户端在从服务器接收WWW认证质询后的请求中的cnonce值来计算A1。它使用来自该质询的服务器nonce（此处称为nonce prime）和来自响应的客户端nonce值（此处称为cnonce prime）来构造A1，如下所示：
A1 = H( unq(username) ":" unq(realm) ":" passwd )
":" unq(nonce-prime) ":" unq(cnonce-prime)
A1 = H( unq(username) ":" unq(realm) ":" passwd )
":" unq(nonce-prime) ":" unq(cnonce-prime)
This creates a "session key" for the authentication of subsequent requests and responses that is different for each "authentication session", thus limiting the amount of material hashed with any one key. (Note: see further discussion of the authentication session in Section 3.6.) Because the server needs only use the hash of the user credentials in order to create the A1 value, this construction could
这将为后续请求和响应的身份验证创建一个“会话密钥”，该密钥对于每个“身份验证会话”都是不同的，从而限制使用任何一个密钥散列的内容量。（注意：请参阅第3.6节中对身份验证会话的进一步讨论。）因为服务器只需要使用用户凭据的散列就可以创建A1值，所以这种构造可以
be used in conjunction with a third-party authentication service so that the web server would not need the actual password value. The specification of such a protocol is beyond the scope of this specification.
与第三方身份验证服务结合使用，以便web服务器不需要实际的密码值。此类协议的规范超出了本规范的范围。
If the qop parameter's value is "auth" or is unspecified, then A2 is:
如果qop参数的值为“auth”或未指定，则A2为：
A2 = Method ":" request-uri
A2=方法“：”请求uri
If the qop value is "auth-int", then A2 is:
如果qop值为“auth int”，则A2为：
A2 = Method ":" request-uri ":" H(entity-body)
A2 = Method ":" request-uri ":" H(entity-body)
To protect the transport of the username from the client to the server, the server SHOULD set the userhash parameter with the value of "true" in the WWW-Authentication header field.
为了保护用户名从客户机到服务器的传输，服务器应在WWW身份验证标头字段中使用“true”值设置userhash参数。
If the client supports the userhash parameter, and the userhash parameter value in the WWW-Authentication header field is set to "true", then the client MUST calculate a hash of the username after any other hash calculation and include the userhash parameter with the value of "true" in the Authorization header field. If the client does not provide the username as a hash value or the userhash parameter with the value of "true", the server MAY reject the request.
如果客户端支持userhash参数，并且WWW身份验证标头字段中的userhash参数值设置为“true”，则客户端必须在任何其他哈希计算之后计算用户名的哈希，并在授权标头字段中包含值为“true”的userhash参数。如果客户端没有提供用户名作为散列值或userhash参数的值为“true”，则服务器可能会拒绝该请求。
The following is the operation that the client will perform to hash the username, using the same algorithm used to hash the credentials:
以下是客户端将使用用于散列凭据的相同算法对用户名进行散列的操作：
username = H( unq(username) ":" unq(realm) )
username = H( unq(username) ":" unq(realm) )
Note that the value of many of the parameters, such as username value, are defined as a "quoted-string". However, the "unq" notation indicates that surrounding quotation marks are removed in forming the string A1. Thus, if the Authorization header field includes the fields
请注意，许多参数的值（例如用户名值）都定义为“带引号的字符串”。然而，“unq”符号表示在形成字符串A1时去掉了周围的引号。因此，如果授权标头字段包括
username="Mufasa", realm="myhost@example.com"
username="Mufasa", realm="myhost@example.com"
and the user Mufasa has password "Circle Of Life", then H(A1) would be H(Mufasa:myhost@example.com:Circle Of Life) with no quotation marks in the digested string.
并且用户Mufasa拥有密码“Circle Of Life”，那么H（A1）将是H（Mufasa:myhost@example.com：生命周期）在摘要字符串中没有引号。
No white space is allowed in any of the strings to which the digest function H() is applied, unless that white space exists in the quoted strings or entity body whose contents make up the string to be digested. For example, the string A1 illustrated above must be
应用摘要函数H（）的任何字符串中都不允许有空格，除非引用的字符串或实体体中存在空格，其内容构成要摘要的字符串。例如，上面所示的字符串A1必须是
Mufasa:myhost@example.com:Circle Of Life
Mufasa:myhost@example.com:Circle Of Life
with no white space on either side of the colons, but with the white space between the words used in the password value. Likewise, the other strings digested by H() must not have white space on either side of the colons that delimit their fields, unless that white space was in the quoted strings or entity body being digested.
冒号两边都没有空格，但是密码值中使用的单词之间有空格。类似地，由H（）分解的其他字符串在分隔其字段的冒号两侧不得有空格，除非该空格位于被分解的引用字符串或实体正文中。
Also, note that if integrity protection is applied (qop=auth-int), the H(entity-body) is the hash of the entity body, not the message body -- it is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded header fields in each part of any multipart content-type.
另外，请注意，如果应用了完整性保护（qop=auth int），则H（实体体）是实体体的散列，而不是消息体——它是在发送方应用任何传输编码之前和接收方删除该编码之后计算的。请注意，这包括任何多部分内容类型的每个部分中的多部分边界和嵌入的标题字段。
The "Method" value is the HTTP request method, in US-ASCII letters, as specified in Section 3.1.1 of [RFC7230]. The "request-target" value is the request-target from the request line as specified in Section 3.1.1 of [RFC7230]. This MAY be "*", an "absolute-URI", or an "absolute-path" as specified in Section 2.7 of [RFC7230], but it MUST agree with the request-target. In particular, it MUST be an "absolute-URI" if the request-target is an "absolute-URI". The cnonce value is a client-chosen value whose purpose is to foil chosen plaintext attacks.
“方法”值是HTTP请求方法，以US-ASCII字母表示，如[RFC7230]第3.1.1节所述。“请求目标”值是[RFC7230]第3.1.1节规定的来自请求行的请求目标。这可能是“*”、“绝对URI”或[RFC7230]第2.7节中规定的“绝对路径”，但必须与请求目标一致。特别是，如果请求目标是“绝对URI”，则它必须是“绝对URI”。cnonce值是客户端选择的值，其目的是抵御选择的明文攻击。
The authenticating server MUST assure that the resource designated by the "uri" parameter is the same as the resource specified in the Request-Line; if they are not, the server SHOULD return a 400 Bad Request error. (Since this may be a symptom of an attack, server implementers may want to consider logging such errors.) The purpose of duplicating information from the request URL in this field is to deal with the possibility that an intermediate proxy may alter the client's Request-Line. This altered (but presumably semantically equivalent) request would not result in the same digest as that calculated by the client.
认证服务器必须确保“uri”参数指定的资源与请求行中指定的资源相同；如果不是，服务器应该返回400错误请求错误。（因为这可能是攻击的症状，服务器实现者可能想考虑记录这些错误。）从该字段中的请求URL复制信息的目的是处理中间代理可能改变客户端请求线的可能性。这个经过修改（但可能在语义上等价）的请求不会产生与客户端计算的摘要相同的摘要。
Implementers should be aware of how authenticated transactions need to interact with shared caches (see [RFC7234]).
实现者应该知道经过身份验证的事务需要如何与共享缓存交互（请参见[RFC7234]）。
3.5. The Authentication-Info and Proxy-Authentication-Info Header Fields
3.5. 身份验证信息和代理身份验证信息标头字段
The Authentication-Info header field and the Proxy-Authentication-Info header field [RFC7615] are generic fields that MAY be used by a server to communicate some information regarding the successful authentication of a client response.
“身份验证信息头”字段和“代理身份验证信息头”字段[RFC7615]是通用字段，服务器可以使用这些字段来传递有关成功验证客户端响应的一些信息。
The Digest Authentication scheme MAY add the Authentication-Info header field in the confirmation request and include parameters from the following list:
摘要认证方案可在确认请求中添加认证信息头字段，并包括以下列表中的参数：
nextnonce
下一次
The value of the nextnonce parameter is the nonce the server wishes the client to use for a future authentication response. The server MAY send the Authentication-Info header field with a nextnonce field as a means of implementing one-time nonces or otherwise changing nonces. If the nextnonce field is present, the client SHOULD use it when constructing the Authorization header field for its next request. Failure of the client to do so MAY result in a request to re-authenticate from the server with the "stale=true".
nextnonce参数的值是服务器希望客户端在将来的身份验证响应中使用的nonce。服务器可以发送带有nextnonce字段的认证信息报头字段，作为实现一次性nonce或以其他方式更改nonce的手段。如果存在NextOnce字段，则客户端在为其下一个请求构造授权标头字段时应使用该字段。如果客户端不这样做，可能会导致服务器请求使用“stale=true”重新验证。
Server implementations SHOULD carefully consider the performance implications of the use of this mechanism; pipelined requests will not be possible if every response includes a nextnonce parameter that MUST be used on the next request received by the server. Consideration SHOULD be given to the performance vs. security tradeoffs of allowing an old nonce value to be used for a limited time to permit request pipelining. Use of the nc parameter can retain most of the security advantages of a new server nonce without the deleterious effects on pipelining.
服务器实现应该仔细考虑使用该机制的性能影响；如果每个响应都包含服务器接收的下一个请求上必须使用的nextnonce参数，则管道化请求将不可能实现。应考虑允许在有限的时间内使用旧的nonce值以允许请求管道化的性能与安全权衡。nc参数的使用可以保留新服务器的大部分安全优势，而不会对管道产生有害影响。
qop
生活质量
Indicates the "quality of protection" options applied to the response by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection. The server SHOULD use the same value for the qop parameter in the response as was sent by the client in the corresponding request.
指示服务器应用于响应的“保护质量”选项。值“auth”表示身份验证；值“auth int”表示具有完整性保护的身份验证。服务器应在响应中使用与客户端在相应请求中发送的相同的qop参数值。
rspauth
瑞斯堡
The optional response digest in the rspauth parameter supports mutual authentication -- the server proves that it knows the user's secret, and with qop=auth-int also provides limited integrity protection of the response. The rspauth value is calculated as for the response in the Authorization header field, except that if qop is set to "auth" or is not specified in the Authorization header field for the request, A2 is
rspauth参数中的可选响应摘要支持相互身份验证——服务器证明它知道用户的秘密，并且使用qop=auth int还提供有限的响应完整性保护。rspauth值是针对授权标头字段中的响应计算的，但如果qop设置为“auth”或未在请求的授权标头字段中指定，则A2为
A2 = ":" request-uri
A2=“：”请求uri
and if "qop=auth-int", then A2 is
如果“qop=auth int”，则A2为
A2 = ":" request-uri ":" H(entity-body)
A2 = ":" request-uri ":" H(entity-body)
cnonce and nc
cnonce与nc
The cnonce value and nc value MUST be the ones for the client request to which this message is the response. The rspauth, cnonce, and nc parameters MUST be present if "qop=auth" or "qop=auth-int" is specified.
cnonce值和nc值必须是此消息响应的客户端请求的值。如果指定了“qop=auth”或“qop=auth int”，则rspauth、cnonce和nc参数必须存在。
The Authentication-Info header field is allowed in the trailer of an HTTP message transferred via chunked transfer coding.
通过分块传输编码传输的HTTP消息的尾部允许使用Authentication Info header字段。
For historical reasons, a sender MUST only generate the quoted string syntax for the following parameters: nextnonce, rspauth, and cnonce.
出于历史原因，发送方只能为以下参数生成带引号的字符串语法：nextnone、rspauth和cnonce。
For historical reasons, a sender MUST NOT generate the quoted string syntax for the following parameters: qop and nc.
出于历史原因，发送方不得为以下参数生成带引号的字符串语法：qop和nc。
For historical reasons, the nc value MUST be exactly 8 hexadecimal digits.
由于历史原因，nc值必须正好是8位十六进制数字。
Upon receiving the Authorization header field, the server MAY check its validity by looking up the password that corresponds to the submitted username. Then, the server MUST perform the same digest operation (e.g., MD5, SHA-256) performed by the client and compare the result to the given response value.
收到授权标头字段后，服务器可以通过查找与提交的用户名对应的密码来检查其有效性。然后，服务器必须执行客户端执行的相同摘要操作（例如，MD5、SHA-256），并将结果与给定的响应值进行比较。
Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header field can be verified.
请注意，HTTP服务器实际上不需要知道用户的明文密码。只要H（A1）对服务器可用，就可以验证授权标头字段的有效性。
The client response to a WWW-Authenticate challenge for a protection space starts an authentication session with that protection space. The authentication session lasts until the client receives another WWW-Authenticate challenge from any server in the protection space. A client SHOULD remember the username, password, nonce, nonce count, and opaque values associated with an authentication session to use to construct the Authorization header field in future requests within that protection space. The Authorization header field MAY be included preemptively; doing so improves server efficiency and avoids extra round trips for authentication challenges. The server MAY choose to accept the old Authorization header field information, even though the nonce value included might not be fresh. Alternatively, the server MAY return a 401 response with a new nonce value in the WWW-Authenticate header field, causing the client to retry the request; by specifying "stale=true" with this response, the server tells the client to retry with the new nonce, but without prompting for a new username and password.
对保护空间的WWW身份验证质询的客户端响应将启动与该保护空间的身份验证会话。身份验证会话将持续，直到客户端从保护空间中的任何服务器接收到另一个WWW身份验证质询。客户端应记住与身份验证会话相关联的用户名、密码、nonce、nonce计数和不透明值，以便在该保护空间内的未来请求中用于构造授权标头字段。授权报头字段可以优先包括；这样做可以提高服务器效率，并避免因身份验证问题而产生额外的往返。服务器可以选择接受旧的授权标头字段信息，即使包含的nonce值可能不是新的。或者，服务器可以在WWW-Authenticate报头字段中返回带有新nonce值的401响应，导致客户端重试该请求；通过在此响应中指定“stale=true”，服务器会告诉客户端使用新的nonce重试，但不会提示输入新的用户名和密码。
Because the client is required to return the value of the opaque parameter given to it by the server for the duration of a session, the opaque data can be used to transport authentication session state information. (Note that any such use can also be accomplished more easily and safely by including the state in the nonce.) For example, a server could be responsible for authenticating content that actually sits on another server. It would achieve this by having the first 401 response include a domain parameter whose value includes a URI on the second server, and an opaque parameter whose value contains the state information. The client will retry the request, at which time the server might respond with "HTTP Redirection" (Section 6.4 of [RFC7231]), pointing to the URI on the second server. The client will follow the redirection and pass an Authorization header field, including the <opaque> data.
由于客户端需要在会话期间返回服务器给它的不透明参数的值，因此不透明数据可用于传输身份验证会话状态信息。（请注意，通过将状态包含在nonce中，也可以更容易、更安全地完成任何此类使用。）例如，服务器可以负责验证实际位于另一台服务器上的内容。它将通过让第一个401响应包含一个域参数（其值包括第二个服务器上的URI）和一个不透明参数（其值包含状态信息）来实现这一点。客户端将重试该请求，此时服务器可能会响应“HTTP重定向”（[RFC7231]第6.4节），指向第二台服务器上的URI。客户端将遵循重定向并传递授权标头字段，包括<opaque>数据。
Proxies MUST be completely transparent in the Digest access authentication scheme. That is, they MUST forward the WWW-Authenticate, Authentication-Info, and Authorization header fields untouched. If a proxy wants to authenticate a client before a request is forwarded to the server, it can be done using the Proxy-Authenticate and Proxy-Authorization header fields described in Section 3.8 below.
摘要访问身份验证方案中的代理必须是完全透明的。也就是说，他们必须转发未触及的WWW身份验证、身份验证信息和授权头字段。如果代理希望在将请求转发到服务器之前对客户端进行身份验证，则可以使用下面第3.8节中描述的代理身份验证和代理授权标头字段来完成。
It is useful for a server to be able to know which security schemes a client is capable of handling.
服务器能够知道客户端能够处理哪些安全方案是很有用的。
It is possible that a server wants to require Digest as its authentication method, even if the server does not know that the
服务器可能需要摘要作为其身份验证方法，即使服务器不知道
client supports it. A client is encouraged to fail gracefully if the server specifies only authentication schemes it cannot handle.
客户机支持它。如果服务器仅指定它无法处理的身份验证方案，则鼓励客户端正常失败。
When a server receives a request to access a resource, the server might challenge the client by responding with "401 Unauthorized" response and include one or more WWW-Authenticate header fields. If the server responds with multiple challenges, then each one of these challenges MUST use a different digest algorithm. The server MUST add these challenges to the response in order of preference, starting with the most preferred algorithm, followed by the less preferred algorithm.
当服务器收到访问资源的请求时，服务器可能会通过响应“401 Unauthorized”响应并包含一个或多个WWW Authenticate标头字段来质询客户端。如果服务器响应多个质询，那么每个质询都必须使用不同的摘要算法。服务器必须按照优先顺序将这些挑战添加到响应中，首先是最优先的算法，然后是不太优先的算法。
This specification defines the following algorithms:
本规范定义了以下算法：
o SHA2-256 (mandatory to implement)
o SHA2-256（强制实施）
o SHA2-512/256 (as a backup algorithm)
o SHA2-512/256（作为备份算法）
o MD5 (for backward compatibility).
o MD5（用于向后兼容性）。
When the client receives the first challenge, it SHOULD use the first challenge it supports, unless a local policy dictates otherwise.
当客户端收到第一个质询时，它应该使用它支持的第一个质询，除非本地策略另有规定。
The Digest Authentication scheme can also be used for authenticating users to proxies, proxies to proxies, or proxies to origin servers by use of the Proxy-Authenticate and Proxy-Authorization header fields. These header fields are instances of the Proxy-Authenticate and Proxy-Authorization header fields specified in Sections 4.3 and 4.4 of the HTTP/1.1 specification [RFC7235], and their behavior is subject to restrictions described there. The transactions for proxy authentication are very similar to those already described. Upon receiving a request that requires authentication, the proxy/server MUST issue the "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header field. The digest-challenge used in the Proxy-Authenticate header field is the same as that for the WWW-Authenticate header field as defined above in Section 3.3.
摘要身份验证方案还可用于通过使用代理身份验证和代理授权头字段，将用户验证为代理、代理到代理或代理到源服务器。这些头字段是HTTP/1.1规范[RFC7235]第4.3节和第4.4节中指定的代理身份验证和代理授权头字段的实例，它们的行为受其中描述的限制。代理身份验证的事务与前面描述的事务非常相似。在接收到需要身份验证的请求后，代理/服务器必须发出带有“proxy authentication”头字段的“407 proxy authentication Required”响应。代理身份验证标头字段中使用的摘要质询与上文第3.3节中定义的WWW身份验证标头字段中使用的摘要质询相同。
The client/proxy MUST then reissue the request with a Proxy-Authorization header field, with parameters as specified for the Authorization header field in Section 3.4 above.
然后，客户机/代理必须使用代理授权标头字段重新发出请求，并使用上文第3.4节中为授权标头字段指定的参数。
On subsequent responses, the server sends Proxy-Authentication-Info with parameters the same as those for the Authentication-Info header field.
在后续响应中，服务器发送代理身份验证信息，其参数与身份验证信息头字段的参数相同。
Note that, in principle, a client could be asked to authenticate itself to both a proxy and an end-server, but never in the same response.
请注意，原则上，可以要求客户机向代理服务器和终端服务器进行身份验证，但决不能在同一响应中进行。
The following example assumes that an access-protected document is being requested from the server via a GET request. The URI of the document is "http://www.example.org/dir/index.html". Both client and server know that the username for this document is "Mufasa" and the password is "Circle of Life" (with one space between each of the three words).
以下示例假定正在通过GET请求从服务器请求受访问保护的文档。文档的URI为“http://www.example.org/dir/index.html". 客户机和服务器都知道此文档的用户名是“Mufasa”，密码是“Circle of Life”（三个单词之间各有一个空格）。
The first time the client requests the document, no Authorization header field is sent, so the server responds with:
客户机第一次请求文档时，不会发送任何授权标头字段，因此服务器响应为：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="http-auth@example.org",
qop="auth, auth-int",
algorithm=SHA-256,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
realm="http-auth@example.org",
qop="auth, auth-int",
algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="http-auth@example.org",
qop="auth, auth-int",
algorithm=SHA-256,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
realm="http-auth@example.org",
qop="auth, auth-int",
algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
The client can prompt the user for their username and password, after which it will respond with a new request, including the following Authorization header field if the client chooses MD5 digest:
客户机可以提示用户输入用户名和密码，之后将以新请求响应，如果客户机选择MD5 digest，则包括以下授权标头字段：
Authorization: Digest username="Mufasa",
realm="http-auth@example.org",
uri="/dir/index.html",
algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
nc=00000001,
cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
qop=auth,
response="8ca523f5e9506fed4657c9700eebdbec",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
Authorization: Digest username="Mufasa",
realm="http-auth@example.org",
uri="/dir/index.html",
algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
nc=00000001,
cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
qop=auth,
response="8ca523f5e9506fed4657c9700eebdbec",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
If the client chooses to use the SHA-256 algorithm for calculating the response, the client responds with a new request including the following Authorization header field:
如果客户机选择使用SHA-256算法来计算响应，则客户机将使用包括以下授权标头字段的新请求进行响应：
Authorization: Digest username="Mufasa",
realm="http-auth@example.org",
uri="/dir/index.html",
algorithm=SHA-256,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
nc=00000001,
cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
qop=auth,
response="753927fa0e85d155564e2e272a28d1802ca10daf449
6794697cf8db5856cb6c1",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
Authorization: Digest username="Mufasa",
realm="http-auth@example.org",
uri="/dir/index.html",
algorithm=SHA-256,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
nc=00000001,
cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
qop=auth,
response="753927fa0e85d155564e2e272a28d1802ca10daf449
6794697cf8db5856cb6c1",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
The following example assumes that an access-protected document is being requested from the server via a GET request. The URI for the request is "http://api.example.org/doe.json". Both client and server know the userhash of the username, support the UTF-8 character encoding scheme, and use the SHA-512-256 algorithm. The username for the request is a variation of "Jason Doe", where the 'a' actually is Unicode code point U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"), and the first 'o' is Unicode code point U+00F8 ("LATIN SMALL LETTER O WITH STROKE"), leading to the octet sequence using the UTF-8 encoding scheme:
以下示例假定正在通过GET请求从服务器请求受访问保护的文档。请求的URI为“http://api.example.org/doe.json". 客户端和服务器都知道用户名的userhash，支持UTF-8字符编码方案，并使用SHA-512-256算法。请求的用户名是“Jason Doe”的变体，其中“a”实际上是Unicode代码点U+00E4（“带分音符的拉丁小写字母a”），第一个“o”是Unicode代码点U+00F8（“带笔划的拉丁小写字母o”），导致使用UTF-8编码方案的八位字节序列：
J U+00E4 s U+00F8 n D o e 4A C3A4 73 C3B8 6E 20 44 6F 65
J U+00E4 s U+00F8 n D o e 4A C3A4 73 C3B8 6E 20 44 6F 65
The password is "Secret, or not?".
密码是“机密还是不机密？”。
The first time the client requests the document, no Authorization header field is sent, so the server responds with:
客户机第一次请求文档时，不会发送任何授权标头字段，因此服务器响应为：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="api@example.org",
qop="auth",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
charset=UTF-8,
userhash=true
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="api@example.org",
qop="auth",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
charset=UTF-8,
userhash=true
The client can prompt the user for the required credentials and send a new request with following Authorization header field:
客户端可以提示用户输入所需的凭据，并使用以下授权标头字段发送新请求：
Authorization: Digest
username="488869477bf257147b804c45308cd62ac4e25eb717
b12b298c79e62dcea254ec",
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
6c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=true
Authorization: Digest
username="488869477bf257147b804c45308cd62ac4e25eb717
b12b298c79e62dcea254ec",
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
6c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=true
If the client cannot provide a hashed username for any reason, the client can try a request with this Authorization header field:
如果客户端由于任何原因无法提供哈希用户名，则客户端可以尝试使用此授权标头字段的请求：
Authorization: Digest
username*=UTF-8''J%C3%A4s%C3%B8n%20Doe,
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
6c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=false
Authorization: Digest
username*=UTF-8''J%C3%A4s%C3%B8n%20Doe,
realm="api@example.org",
uri="/doe.json",
algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
nc=00000001,
cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v",
qop=auth,
response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d
6c861229025f607a79dd",
opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS",
userhash=false
In challenges, servers SHOULD use the "charset" authentication parameter (case-insensitive) to express the character encoding they expect the user agent to use when generating A1 (see Section 3.4.2) and username hashing (see Section 3.4.4).
在挑战中，服务器应该使用“charset”身份验证参数（不区分大小写）来表示它们希望用户代理在生成A1（参见第3.4.2节）和用户名哈希（参见第3.4.4节）时使用的字符编码。
The only allowed value is "UTF-8", to be matched case-insensitively (see Section 2.3 in [RFC2978]). It indicates that the server expects the username and password to be converted to Unicode Normalization Form C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets using the UTF-8 character encoding scheme [RFC3629].
唯一允许的值是“UTF-8”，不区分大小写匹配（见[RFC2978]第2.3节）。它表示服务器希望用户名和密码转换为Unicode规范化格式C（“NFC”，见[RFC5198]第3节），并使用UTF-8字符编码方案[RFC3629]编码为八位字节。
For the username, recipients MUST support all characters defined in the "UsernameCasePreserved" profile defined in Section 3.3 of [RFC7613], with the exception of the colon (":") character.
对于用户名，收件人必须支持[RFC7613]第3.3节中定义的“UsernameCasePreserved”配置文件中定义的所有字符，冒号（“：”）字符除外。
For the password, recipients MUST support all characters defined in the "OpaqueString" profile defined in Section 4.2 of [RFC7613].
对于密码，收件人必须支持[RFC7613]第4.2节中定义的“OpaqueString”配置文件中定义的所有字符。
If the user agent does not support the encoding indicated by the server, it can fail the request.
如果用户代理不支持服务器指示的编码，则可能导致请求失败。
When usernames cannot be sent hashed and include non-ASCII characters, clients can include the username* parameter instead (using the value encoding defined in [RFC5987]).
当用户名不能以散列方式发送且包含非ASCII字符时，客户端可以改为包含username*参数（使用[RFC5987]中定义的值编码）。
HTTP Digest Authentication, when used with human-memorable passwords, is vulnerable to dictionary attacks. Such attacks are much easier than cryptographic attacks on any widely used algorithm, including those that are no longer considered secure. In other words, algorithm agility does not make this usage any more secure.
HTTP摘要身份验证与人类记忆密码一起使用时，容易受到字典攻击。这种攻击比对任何广泛使用的算法（包括那些不再被认为是安全的算法）的加密攻击要容易得多。换句话说，算法敏捷性并不能使这种使用更加安全。
As a result, Digest Authentication SHOULD be used only with passwords that have a reasonable amount of entropy, e.g., 128-bit or more. Such passwords typically cannot be memorized by humans but can be used for automated web services.
因此，摘要身份验证应仅用于具有合理熵的密码，例如128位或更多。这样的密码通常不能被人记住，但可以用于自动web服务。
If Digest Authentication is being used, it SHOULD be over a secure channel like HTTPS [RFC2818].
如果使用摘要身份验证，则应通过HTTPS[RFC2818]等安全通道进行。
Digest Authentication requires that the authenticating agent (usually the server) store some data derived from the user's name and password in a "password file" associated with a given realm. Normally, this might contain pairs consisting of username and H(A1), where H(A1) is the digested value of the username, realm, and password as described above.
摘要身份验证要求身份验证代理（通常是服务器）将从用户名和密码派生的一些数据存储在与给定域关联的“密码文件”中。通常，这可能包含由用户名和H（A1）组成的对，其中H（A1）是如上所述的用户名、域和密码的摘要值。
The security implications of this are that if this password file is compromised, then an attacker gains immediate access to documents on the server using this realm. Unlike, say, a standard UNIX password file, this information needs not be decrypted in order to access documents in the server realm associated with this file. On the other hand, decryption, or more likely a brute-force attack, would be necessary to obtain the user's password. This is the reason that the
这样做的安全含义是，如果此密码文件被破坏，则攻击者可以立即使用此域访问服务器上的文档。与标准UNIX密码文件不同，访问与此文件关联的服务器域中的文档时，不需要解密此信息。另一方面，需要解密，或者更可能是暴力攻击来获取用户的密码。这就是为什么
realm is part of the digested data stored in the password file. It means that if one Digest Authentication password file is compromised, it does not automatically compromise others with the same username and password (though it does expose them to brute-force attack).
域是存储在密码文件中的摘要数据的一部分。这意味着，如果一个摘要身份验证密码文件被破坏，它不会自动破坏具有相同用户名和密码的其他文件（尽管它会使它们遭受暴力攻击）。
There are two important security consequences of this. First, the password file must be protected as if it contained unencrypted passwords, because, for the purpose of accessing documents in its realm, it effectively does.
这有两个重要的安全后果。首先，密码文件必须像包含未加密的密码一样受到保护，因为为了访问其领域中的文档，它实际上是这样做的。
A second consequence of this is that the realm string SHOULD be unique among all realms that any single user is likely to use. In particular, a realm string SHOULD include the name of the host doing the authentication. The inability of the client to authenticate the server is a weakness of Digest Authentication.
第二个结果是，领域字符串在任何单个用户可能使用的所有领域中都应该是唯一的。特别是，领域字符串应该包括进行身份验证的主机的名称。客户端无法对服务器进行身份验证是摘要身份验证的一个弱点。
Digest Authentication does not provide a strong authentication mechanism, when compared to public-key-based mechanisms, for example.
例如，与基于公钥的机制相比，摘要身份验证不提供强身份验证机制。
However, it is significantly stronger than, e.g., CRAM-MD5, which has been proposed for use with Lightweight Directory Access Protocol (LDAP) [RFC4513] and IMAP/POP (see [RFC2195]). It was intended to replace the much weaker and even more dangerous Basic mechanism.
然而，它比CRAM-MD5强得多，例如，CRAM-MD5已被提议用于轻型目录访问协议（LDAP）[RFC4513]和IMAP/POP（参见[RFC2195]）。它的目的是取代更加脆弱甚至危险的基本机制。
Digest Authentication offers no confidentiality protection beyond protecting the actual username and password. All of the rest of the request and response are available to an eavesdropper.
摘要身份验证除了保护实际用户名和密码外，不提供任何保密保护。所有其余的请求和响应都可供窃听者使用。
Digest Authentication offers only limited integrity protection for the messages in either direction. If the "qop=auth-int" mechanism is used, those parts of the message used in the calculation of the WWW-Authenticate and Authorization header field response parameter values (see Section 3.2 above) are protected. Most header fields and their values could be modified as a part of a man-in-the-middle attack.
摘要身份验证仅为两个方向的消息提供有限的完整性保护。如果使用“qop=auth int”机制，则在计算WWW认证和授权标头字段响应参数值（见上文第3.2节）时使用的消息部分将受到保护。大多数标题字段及其值都可以作为中间人攻击的一部分进行修改。
Many needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs, TLS is a more appropriate protocol. In particular, Digest Authentication cannot be used for any transaction requiring confidentiality protection. Nevertheless, many functions remain for which Digest Authentication is both useful and appropriate.
摘要身份验证无法满足安全HTTP事务的许多需求。对于这些需求，TLS是一种更合适的协议。特别是，摘要身份验证不能用于任何需要保密保护的事务。然而，许多功能仍然存在，摘要身份验证对它们既有用又合适。
The Digest scheme uses a server-specified nonce to seed the generation of the response value (as specified in Section 3.4.1 above). As shown in the example nonce in Section 3.3, the server is free to construct the nonce such that it MAY only be used from a particular client, for a particular resource, for a limited period of time or number of uses, or any other restrictions. Doing so strengthens the protection provided against, for example, replay attacks (see Section 5.5). However, it should be noted that the method chosen for generating and checking the nonce also has performance and resource implications. For example, a server MAY choose to allow each nonce value to be used only once by maintaining a record of whether or not each recently issued nonce has been returned and sending a next-nonce parameter in the Authentication-Info header field of every response. This protects against even an immediate replay attack, but it has a high cost due to checking nonce values; perhaps more important, it will cause authentication failures for any pipelined requests (presumably returning a stale nonce indication). Similarly, incorporating a request-specific element such as the ETag value for a resource limits the use of the nonce to that version of the resource and also defeats pipelining. Thus, it MAY be useful to do so for methods with side effects but have unacceptable performance for those that do not.
摘要方案使用服务器指定的nonce来种子生成响应值（如上文第3.4.1节所述）。如第3.3节中的示例nonce所示，服务器可以自由构造nonce，以便它只能从特定客户机、特定资源、有限的时间段或使用次数或任何其他限制中使用。这样做可以增强针对重播攻击等提供的保护（参见第5.5节）。但是，应该注意的是，为生成和检查nonce而选择的方法也会影响性能和资源。例如，服务器可以通过维护每个最近发出的nonce是否已返回的记录，并在每个响应的认证信息报头字段中发送下一个nonce参数，来选择允许每个nonce值仅使用一次。这可以防止即时重放攻击，但由于检查nonce值，因此成本较高；也许更重要的是，它会导致任何流水线请求的身份验证失败（可能会返回过时的nonce指示）。类似地，合并特定于请求的元素（如资源的ETag值）会将nonce的使用限制在该版本的资源上，并且还会破坏管道。因此，对于有副作用的方法，这样做可能是有用的，但对于没有副作用的方法，这样做的性能是不可接受的。
A replay attack against Digest Authentication would usually be pointless for a simple GET request since an eavesdropper would already have seen the only document he could obtain with a replay. This is because the URI of the requested document is digested in the client request, and the server will only deliver that document. By contrast, under Basic Authentication, once the eavesdropper has the user's password, any document protected by that password is open to him.
对于简单的GET请求，针对摘要身份验证的重播攻击通常毫无意义，因为窃听者可能已经看到了通过重播可以获得的唯一文档。这是因为请求文档的URI在客户机请求中进行了摘要处理，而服务器将只传递该文档。相反，在基本身份验证下，一旦窃听者拥有用户密码，受该密码保护的任何文档都对他开放。
Thus, for some purposes, it is necessary to protect against replay attacks. A good Digest implementation can do this in various ways. The server-created "nonce" value is implementation dependent, but if it contains a digest of the client IP, a timestamp, the resource ETag, and a private server key (as recommended above), then a replay attack is not simple. An attacker must convince the server that the request is coming from a false IP address and must cause the server to deliver the document to an IP address different from the address to which it believes it is sending the document. An attack can only succeed in the period before the timestamp expires. Digesting the client IP and timestamp in the nonce permits an implementation that does not maintain state between transactions.
因此，出于某些目的，有必要防止重播攻击。一个好的摘要实现可以通过多种方式实现这一点。服务器创建的“nonce”值取决于实现，但如果它包含客户端IP摘要、时间戳、资源ETag和专用服务器密钥（如上所述），则重播攻击并不简单。攻击者必须使服务器确信请求来自错误的IP地址，并且必须使服务器将文档发送到与其认为要将文档发送到的地址不同的IP地址。攻击只能在时间戳过期之前成功。在nonce中对客户机IP和时间戳进行摘要处理允许实现不维护事务之间的状态。
For applications where no possibility of replay attack can be tolerated, the server can use one-time nonce values that will not be honored for a second use. This requires the overhead of the server remembering which nonce values have been used until the nonce timestamp (and hence the digest built with it) has expired, but it effectively protects against replay attacks.
对于无法容忍重播攻击的应用程序，服务器可以使用一次性的nonce值，而这些值在第二次使用时将不会被接受。这需要服务器记住在nonce时间戳（以及由此生成的摘要）过期之前使用了哪些nonce值，但它可以有效地防止重播攻击。
An implementation must give special attention to the possibility of replay attacks with POST and PUT requests. Unless the server employs one-time or otherwise limited-use nonces and/or insists on the use of the integrity protection of "qop=auth-int", an attacker could replay valid credentials from a successful request with counterfeit data or other message body. Even with the use of integrity protection, most metadata in header fields is not protected. Proper nonce generation and checking provides some protection against replay of previously used valid credentials, but see Section 5.8.
实现必须特别注意使用POST和PUT请求重播攻击的可能性。除非服务器使用一次性或其他限制使用的nonce和/或坚持使用“qop=auth int”的完整性保护，否则攻击者可以使用伪造数据或其他消息体重播成功请求中的有效凭据。即使使用完整性保护，头字段中的大多数元数据也不受保护。正确的nonce生成和检查可以防止重播以前使用的有效凭据，但请参见第5.8节。
An HTTP/1.1 server MAY return multiple challenges with a 401 (Authenticate) response, and each challenge MAY use a different auth-scheme. A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge.
HTTP/1.1服务器可能返回带有401（身份验证）响应的多个质询，每个质询可能使用不同的身份验证方案。用户代理必须选择使用其理解的最强身份验证方案，并根据该质询向用户请求凭据。
When the server offers choices of authentication schemes using the WWW-Authenticate header field, the strength of the resulting authentication is only as good as that of the of the weakest of the authentication schemes. See Section 5.7 below for discussion of particular attack scenarios that exploit multiple authentication schemes.
当服务器使用WWW Authenticate标头字段提供身份验证方案的选择时，生成的身份验证的强度仅与最弱的身份验证方案的强度相同。有关利用多个身份验证方案的特定攻击场景的讨论，请参见下文第5.7节。
If the attacker can eavesdrop, then it can test any overheard nonce/ response pairs against a list of common words. Such a list is usually much smaller than the total number of possible passwords. The cost of computing the response for each password on the list is paid once for each challenge.
如果攻击者可以窃听，那么它可以根据常用词列表测试任何偷听的nonce/响应对。这样的列表通常比可能的密码总数小得多。为列表中的每个密码计算响应的成本为每个质询支付一次。
The server can mitigate this attack by not allowing users to select passwords that are in a dictionary.
服务器可以通过不允许用户选择字典中的密码来减轻此攻击。
Digest Authentication is vulnerable to man-in-the-middle (MITM) attacks, for example, from a hostile or compromised proxy. Clearly, this would present all the problems of eavesdropping. But, it also offers some additional opportunities to the attacker.
摘要身份验证容易受到中间人（MITM）攻击，例如来自恶意或受损代理的攻击。显然，这将带来窃听的所有问题。但是，它也为攻击者提供了一些额外的机会。
A possible man-in-the-middle attack would be to add a weak authentication scheme to the set of choices, hoping that the client will use one that exposes the user's credentials (e.g., password). For this reason, the client SHOULD always use the strongest scheme that it understands from the choices offered.
一种可能的中间人攻击是向选择集添加弱身份验证方案，希望客户端使用暴露用户凭据（例如密码）的方案。因此，客户应始终使用其从提供的选择中理解的最强方案。
An even better MITM attack would be to remove all offered choices, replacing them with a challenge that requests only Basic authentication, then uses the cleartext credentials from the Basic authentication to authenticate to the origin server using the stronger scheme it requested. A particularly insidious way to mount such a MITM attack would be to offer a "free" proxy caching service to gullible users.
更好的MITM攻击是删除所有提供的选项，替换为仅请求基本身份验证的质询，然后使用基本身份验证中的明文凭据使用其请求的更强方案向源服务器进行身份验证。装载此类MITM攻击的一种特别阴险的方法是向易受欺骗的用户提供“免费”代理缓存服务。
User agents should consider measures such as presenting a visual indication at the time of the credentials request of what authentication scheme is to be used, or remembering the strongest authentication scheme ever requested by a server and producing a warning message before using a weaker one. It might also be a good idea for the user agent to be configured to demand Digest authentication in general or from specific sites.
用户代理应该考虑诸如在使用什么认证方案的凭证请求时呈现视觉指示或记住服务器请求的最强认证方案并在使用较弱的消息之前产生警告消息之类的措施。将用户代理配置为一般要求摘要身份验证或从特定站点要求摘要身份验证也是一个好主意。
Or, a hostile proxy might spoof the client into making a request the attacker wanted rather than one the client wanted. Of course, this is still much harder than a comparable attack against Basic Authentication.
或者，恶意代理可能会欺骗客户端发出攻击者想要的请求，而不是客户端想要的请求。当然，这仍然比针对基本身份验证的类似攻击困难得多。
With Digest Authentication, a MITM or a malicious server can arbitrarily choose the nonce that the client will use to compute the response. This is called a "chosen plaintext" attack. The ability to choose the nonce is known to make cryptanalysis much easier.
通过摘要身份验证，MITM或恶意服务器可以任意选择客户端用于计算响应的nonce。这称为“选择明文”攻击。选择nonce的能力使密码分析变得更容易。
However, a method to analyze the one-way functions used by Digest using chosen plaintext is not currently known.
然而，目前还不知道使用所选明文分析摘要使用的单向函数的方法。
The countermeasure against this attack is for clients to use the cnonce parameter; this allows the client to vary the input to the hash in a way not chosen by the attacker.
针对这种攻击的对策是让客户端使用cnonce参数；这允许客户端以攻击者未选择的方式更改哈希的输入。
With Digest Authentication, if the attacker can execute a chosen plaintext attack, the attacker can precompute the response for many common words to a nonce of its choice and store a dictionary of response/password pairs. Such precomputation can often be done in parallel on many machines. It can then use the chosen plaintext attack to acquire a response corresponding to that challenge and just look up the password in the dictionary. Even if most passwords are not in the dictionary, some might be. Since the attacker gets to pick the challenge, the cost of computing the response for each password on the list can be amortized over finding many passwords. A dictionary with 100 million password/response pairs would take about 3.2 gigabytes of disk storage.
使用摘要身份验证，如果攻击者可以执行选择的明文攻击，则攻击者可以将许多常用词的响应预计算为其选择的一个临时值，并存储响应/密码对的字典。这种预计算通常可以在许多机器上并行完成。然后，它可以使用所选择的明文攻击获取对应于该质询的响应，并在字典中查找密码。即使大多数密码不在字典中，也可能有一些密码在字典中。由于攻击者可以选择挑战，因此计算列表中每个密码的响应的成本可以分摊到查找多个密码上。一个拥有1亿个密码/响应对的字典将占用大约32 GB的磁盘存储空间。
The countermeasure against this attack is for clients to use the cnonce parameter.
针对此攻击的对策是让客户端使用cnonce参数。
With Digest Authentication, a MITM can execute a chosen plaintext attack and can gather responses from many users to the same nonce. It can then find all the passwords within any subset of password space that would generate one of the nonce/response pairs in a single pass over that space. It also reduces the time to find the first password by a factor equal to the number of nonce/response pairs gathered. This search of the password space can often be done in parallel on many machines, and even a single machine can search large subsets of the password space very quickly -- reports exist of searching all passwords with six or fewer letters in a few hours.
通过摘要身份验证，MITM可以执行选择的明文攻击，并可以收集多个用户对同一时刻的响应。然后，它可以在密码空间的任何子集中找到所有密码，这些密码空间将在通过该空间的单个过程中生成一个nonce/response对。它还将查找第一个密码的时间缩短了一个因子，该因子等于收集的nonce/响应对的数量。这种对密码空间的搜索通常可以在许多机器上并行进行，即使是一台机器也可以非常快速地搜索密码空间的很大一部分——有报告称，在几个小时内用六个或更少的字母搜索所有密码。
The countermeasure against this attack is for clients to use the cnonce parameter.
针对此攻击的对策是让客户端使用cnonce参数。
The security of this protocol is critically dependent on the randomness of the randomly chosen parameters, such as client and server nonces. These should be generated by a strong random or properly seeded pseudorandom source (see [RFC4086]).
该协议的安全性在很大程度上取决于随机选择的参数的随机性，例如客户端和服务器的nonce。这些应该由强随机或正确播种的伪随机源生成（参见[RFC4086]）。
By modern cryptographic standards, Digest Authentication is weak. But, for a large range of purposes, it is valuable as a replacement for Basic Authentication. It remedies some, but not all, weaknesses of Basic Authentication. Its strength may vary depending on the implementation. In particular, the structure of the nonce (which is
根据现代密码标准，摘要认证很弱。但是，在很多情况下，它作为基本身份验证的替代品是很有价值的。它弥补了一些（但不是全部）基本身份验证的弱点。其强度可能因实施情况而异。特别是，nonce（即
dependent on the server implementation) may affect the ease of mounting a replay attack. A range of server options is appropriate since, for example, some implementations may be willing to accept the server overhead of one-time nonces or digests to eliminate the possibility of replay. Others may be satisfied with a nonce like the one recommended above, i.e., restricted to a single IP address and a single ETag or with a limited lifetime.
取决于服务器实现）可能会影响重播攻击的易用性。一系列服务器选项是合适的，因为，例如，一些实现可能愿意接受一次性nonce或digest的服务器开销，以消除重播的可能性。其他人可能会对上述建议的nonce感到满意，即，仅限于单个IP地址和单个ETag或具有有限的生存期。
The bottom line is that *any* compliant implementation will be relatively weak by cryptographic standards, but *any* compliant implementation will be far superior to Basic Authentication.
底线是*任何*兼容的实现在加密标准下都相对较弱，但*任何*兼容的实现都远远优于基本身份验证。
This specification creates a new IANA registry named "Hash Algorithms for HTTP Digest Authentication" under the existing "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" category. This registry lists the hash algorithms that can be used in HTTP Digest Authentication.
本规范在现有的“超文本传输协议（HTTP）摘要算法值”类别下创建了一个名为“HTTP摘要认证哈希算法”的新IANA注册表。此注册表列出了可用于HTTP摘要身份验证的哈希算法。
When registering a new hash algorithm, the following information MUST be provided:
注册新哈希算法时，必须提供以下信息：
Hash Algorithm
散列算法
The textual name of the hash algorithm.
哈希算法的文本名称。
Digest Size
摘要大小
The size of the algorithm's output in bits.
算法输出的大小（以位为单位）。
Reference
参考
A reference to the specification adding the algorithm to this registry.
对将算法添加到此注册表的规范的引用。
The update policy for this registry shall be Specification Required [RFC5226].
此注册表的更新策略应符合规范要求[RFC5226]。
The initial registry contains the following entries:
初始注册表包含以下条目：
+----------------+-------------+-----------+
| Hash Algorithm | Digest Size | Reference |
+----------------+-------------+-----------+
| "MD5" | 128 | RFC 7616 |
| "SHA-512-256" | 256 | RFC 7616 |
| "SHA-256" | 256 | RFC 7616 |
+----------------+-------------+-----------+
+----------------+-------------+-----------+
| Hash Algorithm | Digest Size | Reference |
+----------------+-------------+-----------+
| "MD5" | 128 | RFC 7616 |
| "SHA-512-256" | 256 | RFC 7616 |
| "SHA-256" | 256 | RFC 7616 |
+----------------+-------------+-----------+
Each one of the algorithms defined in the registry might have a "-sess" variant, e.g., MD5-sess, SHA-256-sess, etc.
注册表中定义的每种算法都可能有一个“-sess”变体，例如MD5 sess、SHA-256-sess等。
To clarify the purpose of the existing "HTTP Digest Algorithm Values" registry and to avoid confusion between the two registries, IANA has added the following description to the existing "HTTP Digest Algorithm Values" registry:
为了澄清现有“HTTP摘要算法值”注册表的用途并避免两个注册表之间的混淆，IANA在现有“HTTP摘要算法值”注册表中添加了以下说明：
This registry lists the algorithms that can be used when creating digests of an HTTP message body, as specified in RFC 3230.
此注册表列出了创建HTTP消息正文摘要时可以使用的算法，如RFC 3230中所指定的。
This specification updates the existing entry of the Digest scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" and adds a new reference to this specification.
本规范更新了“超文本传输协议（HTTP）认证方案注册表”中摘要方案的现有条目，并添加了对本规范的新引用。
Authentication Scheme Name: Digest
身份验证方案名称：摘要
Pointer to specification text: RFC 7616
指向规范文本的指针：RFC 7616
[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>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <http://www.rfc-editor.org/info/rfc2978>.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，DOI 10.17487/RFC2978，2000年10月<http://www.rfc-editor.org/info/rfc2978>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[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>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <http://www.rfc-editor.org/info/rfc5198>.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 5198，DOI 10.17487/RFC5198，2008年3月<http://www.rfc-editor.org/info/rfc5198>.
[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>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, <http://www.rfc-editor.org/info/rfc5987>.
[RFC5987]Reschke，J.，“超文本传输协议（HTTP）头字段参数的字符集和语言编码”，RFC 5987，DOI 10.17487/RFC5987，2010年8月<http://www.rfc-editor.org/info/rfc5987>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<http://www.rfc-editor.org/info/rfc6454>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[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>.
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, DOI 10.17487/RFC2195, September 1997, <http://www.rfc-editor.org/info/rfc2195>.
[RFC2195]Klensin，J.，Catoe，R.，和P.Krumviede，“简单质询/响应的IMAP/POP授权扩展”，RFC 2195，DOI 10.17487/RFC2195，1997年9月<http://www.rfc-editor.org/info/rfc2195>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, <http://www.rfc-editor.org/info/rfc2617>.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 2617，DOI 10.17487/RFC2617，1999年6月<http://www.rfc-editor.org/info/rfc2617>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, DOI 10.17487/RFC4513, June 2006, <http://www.rfc-editor.org/info/rfc4513>.
[RFC4513]Harrison，R.，Ed.“轻量级目录访问协议（LDAP）：身份验证方法和安全机制”，RFC 4513，DOI 10.17487/RFC4513，2006年6月<http://www.rfc-editor.org/info/rfc4513>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>.
[RFC7617]Reschke，J.“基本”HTTP认证方案”，RFC 7617，DOI 10.17487/RFC76172015年9月<http://www.rfc-editor.org/info/rfc7617>.
This document introduces the following changes:
本文档介绍了以下更改：
o Adds support for two new algorithms, SHA2-256 as mandatory and SHA2-512/256 as a backup, and defines the proper algorithm negotiation. The document keeps the MD5 algorithm support but only for backward compatibility.
o 添加了对两种新算法的支持，SHA2-256为强制算法，SHA2-512/256为备份算法，并定义了正确的算法协商。该文档保留了MD5算法支持，但只是为了向后兼容。
o Introduces the username hashing capability and the parameter associated with that, mainly for privacy reasons.
o 介绍用户名哈希功能以及与此相关的参数，主要是出于隐私原因。
o Adds various internationalization considerations that impact the A1 calculation and username and password encoding.
o 添加影响A1计算以及用户名和密码编码的各种国际化注意事项。
o Introduces a new IANA registry, "Hash Algorithms for HTTP Digest Authentication", that lists the hash algorithms that can be used in HTTP Digest Authentication.
o 介绍了一个新的IANA注册表“HTTP摘要身份验证的哈希算法”，其中列出了可用于HTTP摘要身份验证的哈希算法。
o Deprecates backward compatibility with RFC 2069.
o 反对与RFC 2069的向后兼容性。
Acknowledgments
致谢
To provide a complete description for the Digest mechanism and its operation, this document borrows text heavily from [RFC2617]. The authors of this document would like to thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on that specification.
为了提供摘要机制及其操作的完整描述，本文档大量借用了[RFC2617]中的文本。本文件的作者要感谢John Franks、Phillip M.Hallam Baker、Jeffery L.Hostetler、Scott D.Lawrence、Paul J.Leach、Ari Lootonen和Lawrence C.Stewart在该规范方面所做的工作。
Special thanks to Julian Reschke for his many reviews, comments, suggestions, and text provided to various areas in this document.
特别感谢Julian Reschke对本文件各个领域的评论、意见、建议和文本。
The authors would like to thank Stephen Farrell, Yoav Nir, Phillip Hallam-Baker, Manu Sporny, Paul Hoffman, Yaron Sheffer, Sean Turner, Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Martin Durst, Peter Saint-Andre, Michael Sweet, Daniel Stenberg, Brett Tate, Paul Leach, Ilari Liusvaara, Gary Mort, Alexey Melnikov, Benjamin Kaduk, Kathleen Moriarty, Francis Dupont, Hilarie Orman, and Ben Campbell for their careful review and comments.
作者要感谢斯蒂芬·法雷尔、约阿夫·尼尔、菲利普·哈拉姆·贝克、马努·斯波尼、保罗·霍夫曼、亚龙·谢弗、肖恩·特纳、杰夫·巴斯克维尔、埃里克·库珀、比约恩·霍尔曼、马丁·杜斯特、彼得·圣安德烈、迈克尔·斯威特、丹尼尔·斯滕伯格、布雷特·塔特、保罗·利奇、伊拉里·柳斯瓦拉、加里·莫特、亚历克西·梅尔尼科夫、本杰明·卡杜克、，凯瑟琳·莫里亚蒂、弗朗西斯·杜邦、希拉里·奥曼和本·坎贝尔感谢他们的仔细审查和评论。
The authors would like to thank Jonathan Stoke, Nico Williams, Harry Halpin, and Phil Hunt for their comments on the mailing list when discussing various aspects of this document.
作者感谢Jonathan Stoke、Nico Williams、Harry Halpin和Phil Hunt在讨论本文件各个方面时对邮件列表的评论。
The authors would like to thank Paul Kyzivat and Dale Worley for their careful review and feedback on some aspects of this document.
作者要感谢Paul Kyzivat和Dale Worley对本文件某些方面的仔细审查和反馈。
The authors would like to thank Barry Leiba for his help with the registry.
作者要感谢Barry Leiba对注册中心的帮助。
Authors' Addresses
作者地址
Rifaat Shekh-Yusef (editor) Avaya 250 Sidney Street Belleville, Ontario Canada
Rifaat Shekh Yusef（编辑）Avaya 250 Sidney Street Belleville，加拿大安大略省
Phone: +1-613-967-5267
Email: rifaat.ietf@gmail.com
Phone: +1-613-967-5267
Email: rifaat.ietf@gmail.com
David Ahrens Independent California United States
David Ahrens独立于美国加利福尼亚州
Email: ahrensdc@gmail.com
Email: ahrensdc@gmail.com
Sophie Bremer Netzkonform Germany
索菲·布雷默·内兹康德国
Email: sophie.bremer@netzkonform.de
Email: sophie.bremer@netzkonform.de