Network Working Group J. Franks
Request for Comments: 2617 Northwestern University
Obsoletes: 2069 P. Hallam-Baker
Category: Standards Track Verisign, Inc.
J. Hostetler
AbiSource, Inc.
S. Lawrence
Agranat Systems, Inc.
P. Leach
Microsoft Corporation
A. Luotonen
Netscape Communications Corporation
L. Stewart
Open Market, Inc.
June 1999
Network Working Group J. Franks
Request for Comments: 2617 Northwestern University
Obsoletes: 2069 P. Hallam-Baker
Category: Standards Track Verisign, Inc.
J. Hostetler
AbiSource, Inc.
S. Lawrence
Agranat Systems, Inc.
P. Leach
Microsoft Corporation
A. Luotonen
Netscape Communications Corporation
L. Stewart
Open Market, Inc.
June 1999
HTTP Authentication: Basic and Digest Access Authentication
HTTP身份验证：基本和摘要访问身份验证
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
"HTTP/1.0", includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.
“HTTP/1.0”包括基本访问身份验证方案的规范。此方案不被视为用户身份验证的安全方法（除非与某些外部安全系统（如SSL[5]），因为用户名和密码以明文形式通过网络传递。
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
本文档还提供了HTTP身份验证框架、原始基本身份验证方案和基于加密哈希的方案（称为“摘要访问身份验证”）的规范。因此，其也旨在替代RFC 2069[6]。由于自发布以来发现的问题，RFC 2069规定的一些可选元素已从本规范中删除；为了兼容性，添加了其他新元素，这些新元素是可选的，但强烈建议使用。
Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.
与Basic类似，摘要访问认证验证通信双方是否知道共享秘密（密码）；与Basic不同，这种验证可以在不发送明文密码的情况下完成，这是Basic最大的弱点。与大多数其他身份验证协议一样，最大的风险来源通常不在核心协议本身，而是在围绕其使用的策略和程序中。
Table of Contents
目录
1 Access Authentication................................ 3
1.1 Reliance on the HTTP/1.1 Specification............ 3
1.2 Access Authentication Framework................... 3
2 Basic Authentication Scheme.......................... 5
3 Digest Access Authentication Scheme.................. 6
3.1 Introduction...................................... 6
3.1.1 Purpose......................................... 6
3.1.2 Overall Operation............................... 6
3.1.3 Representation of digest values................. 7
3.1.4 Limitations..................................... 7
3.2 Specification of Digest Headers................... 7
3.2.1 The WWW-Authenticate Response Header............ 8
3.2.2 The Authorization Request Header................ 11
3.2.3 The Authentication-Info Header.................. 15
3.3 Digest Operation.................................. 17
3.4 Security Protocol Negotiation..................... 18
3.5 Example........................................... 18
3.6 Proxy-Authentication and Proxy-Authorization...... 19
4 Security Considerations.............................. 19
4.1 Authentication of Clients using Basic
Authentication.................................... 19
4.2 Authentication of Clients using Digest
Authentication.................................... 20
4.3 Limited Use Nonce Values.......................... 21
4.4 Comparison of Digest with Basic Authentication.... 22
4.5 Replay Attacks.................................... 22
4.6 Weakness Created by Multiple Authentication
Schemes........................................... 23
4.7 Online dictionary attacks......................... 23
4.8 Man in the Middle................................. 24
4.9 Chosen plaintext attacks.......................... 24
4.10 Precomputed dictionary attacks.................... 25
4.11 Batch brute force attacks......................... 25
4.12 Spoofing by Counterfeit Servers................... 25
4.13 Storing passwords................................. 26
4.14 Summary........................................... 26
5 Sample implementation................................ 27
6 Acknowledgments...................................... 31
1 Access Authentication................................ 3
1.1 Reliance on the HTTP/1.1 Specification............ 3
1.2 Access Authentication Framework................... 3
2 Basic Authentication Scheme.......................... 5
3 Digest Access Authentication Scheme.................. 6
3.1 Introduction...................................... 6
3.1.1 Purpose......................................... 6
3.1.2 Overall Operation............................... 6
3.1.3 Representation of digest values................. 7
3.1.4 Limitations..................................... 7
3.2 Specification of Digest Headers................... 7
3.2.1 The WWW-Authenticate Response Header............ 8
3.2.2 The Authorization Request Header................ 11
3.2.3 The Authentication-Info Header.................. 15
3.3 Digest Operation.................................. 17
3.4 Security Protocol Negotiation..................... 18
3.5 Example........................................... 18
3.6 Proxy-Authentication and Proxy-Authorization...... 19
4 Security Considerations.............................. 19
4.1 Authentication of Clients using Basic
Authentication.................................... 19
4.2 Authentication of Clients using Digest
Authentication.................................... 20
4.3 Limited Use Nonce Values.......................... 21
4.4 Comparison of Digest with Basic Authentication.... 22
4.5 Replay Attacks.................................... 22
4.6 Weakness Created by Multiple Authentication
Schemes........................................... 23
4.7 Online dictionary attacks......................... 23
4.8 Man in the Middle................................. 24
4.9 Chosen plaintext attacks.......................... 24
4.10 Precomputed dictionary attacks.................... 25
4.11 Batch brute force attacks......................... 25
4.12 Spoofing by Counterfeit Servers................... 25
4.13 Storing passwords................................. 26
4.14 Summary........................................... 26
5 Sample implementation................................ 27
6 Acknowledgments...................................... 31
7 References........................................... 31
8 Authors' Addresses................................... 32
9 Full Copyright Statement............................. 34
7 References........................................... 31
8 Authors' Addresses................................... 32
9 Full Copyright Statement............................. 34
1 Access Authentication
1访问认证
This specification is a companion to the HTTP/1.1 specification [2]. It uses the augmented BNF section 2.1 of that document, and relies on both the non-terminals defined in that document and other aspects of the HTTP/1.1 specification.
本规范是HTTP/1.1规范的配套规范[2]。它使用了该文档的增广BNF第2.1节，并依赖于该文档中定义的非终端和HTTP/1.1规范的其他方面。
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. It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
HTTP提供了一种简单的质询-响应身份验证机制，服务器可使用该机制质询客户端请求，客户端可使用该机制提供身份验证信息。它使用一个可扩展的不区分大小写的令牌来标识身份验证方案，然后是一个逗号分隔的属性值对列表，其中包含通过该方案实现身份验证所需的参数。
auth-scheme = token auth-param = token "=" ( token | quoted-string )
认证方案=令牌认证参数=令牌“=”（令牌|带引号的字符串）
The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and MUST include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
401（未经授权）响应消息由源服务器用于质疑用户代理的授权。此响应必须包括WWW Authenticate标头字段，该字段至少包含一个适用于请求的资源的质询。代理使用407（需要代理身份验证）响应消息来质询客户端的授权，并且必须包括代理身份验证头字段，该字段至少包含一个适用于所请求资源的代理的质询。
challenge = auth-scheme 1*SP 1#auth-param
challenge = auth-scheme 1*SP 1#auth-param
Note: User agents will need to take special care in parsing the WWW-Authenticate or Proxy-Authenticate header field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters.
注意：如果WWW Authenticate或Proxy Authenticate标头字段值包含多个质询，或者如果提供了多个WWW Authenticate标头字段，则用户代理在解析该字段时需要特别小心，因为质询的内容本身可能包含以逗号分隔的身份验证参数列表。
The authentication parameter realm is defined for all authentication schemes:
为所有身份验证方案定义了身份验证参数域：
realm = "realm" "=" realm-value realm-value = quoted-string
realm=“realm”“=”领域值领域值=带引号的字符串
The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.
发出质询的所有身份验证方案都需要realm指令（不区分大小写）。域值（区分大小写）与被访问服务器的规范根URL（abs_路径为空的服务器的绝对URI；请参见[2]的第5.1.2节）一起定义保护空间。这些领域允许将服务器上受保护的资源划分为一组保护空间，每个空间都有自己的身份验证方案和/或授权数据库。领域值是一个字符串，通常由源服务器分配，它可能具有特定于身份验证方案的附加语义。请注意，同一身份验证方案可能存在多个挑战，但领域不同。
A user agent that wishes to authenticate itself with an origin server--usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy--usually, but not necessarily, after receiving a 407 (Proxy Authentication Required)--MAY do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication information of the client for the realm of the resource being requested. The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based upon that challenge.
希望向源服务器进行身份验证的用户代理（通常，但不一定，在收到401（未经授权）后）可以通过在请求中包含授权标头字段来进行身份验证。希望使用代理对自己进行身份验证的客户机（通常，但不一定，在收到407（需要代理身份验证）后）可以通过在请求中包含代理授权头字段来进行身份验证。Authorization字段值和Proxy Authorization字段值都由包含所请求资源领域的客户端身份验证信息的凭据组成。用户代理必须选择使用其中一个具有其理解的最强身份验证方案的挑战，并根据该挑战向用户请求凭据。
credentials = auth-scheme #auth-param
凭证=验证方案#验证参数
Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only include Basic if it is minimally acceptable.
请注意，许多浏览器将只识别Basic，并要求它是第一个提交的身份验证方案。只有在最低限度可接受的情况下，服务器才应包含Basic。
The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server.
保护空间确定可以自动应用凭据的域。如果先前的请求已被授权，则在由认证方案、参数和/或用户偏好确定的一段时间内，相同的凭证可用于该保护空间内的所有其他请求。除非身份验证方案另有定义，否则单个保护空间不能扩展到其服务器的范围之外。
If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a
如果源服务器不希望接受随请求发送的凭据，则应返回401（未经授权）响应。响应必须包括WWW Authenticate标头字段，该字段至少包含一个（可能是新的）适用于请求的资源的质询。如果代理不接受随请求发送的凭据，则应返回407（需要代理身份验证）。响应必须包括一个代理身份验证标头字段，其中包含
(possibly new) challenge applicable to the proxy for the requested resource.
适用于所请求资源的代理的（可能是新的）质询。
The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification.
HTTP协议不限制应用程序使用这种简单的质询-响应机制进行访问身份验证。可以使用额外的机制，例如在传输级别或通过消息封装进行加密，并使用额外的头字段指定身份验证信息。但是，本规范未定义这些附加机制。
Proxies MUST be completely transparent regarding user agent authentication by origin servers. That is, they must forward the WWW-Authenticate and Authorization headers untouched, and follow the rules found in section 14.8 of [2]. Both the Proxy-Authenticate and the Proxy-Authorization header fields are hop-by-hop headers (see section 13.5.1 of [2]).
对于源服务器的用户代理身份验证，代理必须是完全透明的。也就是说，他们必须转发未触及的WWW身份验证和授权头，并遵循[2]第14.8节中的规则。代理验证和代理授权标头字段均为逐跳标头（见[2]第13.5.1节）。
2 Basic Authentication Scheme
2基本认证方案
The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.
“基本”身份验证方案基于这样一种模型，即客户端必须使用每个领域的用户ID和密码对自己进行身份验证。领域值应被视为不透明字符串，只能与该服务器上的其他领域进行平等性比较。只有当服务器能够验证请求URI的保护空间的用户ID和密码时，才会为请求提供服务。没有可选的身份验证参数。
For Basic, the framework above is utilized as follows:
对于Basic，使用上述框架如下：
challenge = "Basic" realm credentials = "Basic" basic-credentials
challenge=“Basic”realm credentials=“Basic”基本凭据
Upon receipt of an unauthorized request for a URI within the protection space, the origin server MAY respond with a challenge like the following:
在收到对保护空间内的URI的未经授权的请求后，源服务器可能会响应如下质询：
WWW-Authenticate: Basic realm="WallyWorld"
WWW-Authenticate:Basic-realm=“WallyWorld”
where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI. A proxy may respond with the same challenge using the Proxy-Authenticate header field.
其中，“WallyWorld”是服务器分配的字符串，用于标识请求URI的保护空间。代理可以使用proxy Authenticate标头字段响应相同的质询。
To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials.
为了接收授权，客户机在凭证中的base64[7]编码字符串中发送用户ID和密码，以单个冒号（“：”）字符分隔。
basic-credentials = base64-user-pass
base64-user-pass = <base64 [4] encoding of user-pass,
basic-credentials = base64-user-pass
base64-user-pass = <base64 [4] encoding of user-pass,
except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
Userids might be case sensitive.
用户标识可能区分大小写。
If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:
如果用户代理希望发送用户ID“Aladdin”和密码“open sesame”，它将使用以下标题字段：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server. See section 4 for security considerations associated with Basic authentication.
客户机应假定位于请求URI路径字段中最后一个符号元素深度或更深的所有路径也在由当前质询的基本领域值指定的保护空间内。客户端可以在不接收来自服务器的另一个质询的情况下，先发制人地发送相应的授权报头以及对该空间中的资源的请求。类似地，当客户机向代理发送请求时，它可以重用代理授权标头字段中的用户标识和密码，而无需从代理服务器接收另一个质询。有关与基本身份验证相关的安全注意事项，请参见第4节。
3 Digest Access Authentication Scheme
3摘要访问认证方案
The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme[1]. That scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network in an unencrypted form. This section provides the specification for a scheme that does not send the password in cleartext, referred to as "Digest Access Authentication".
被称为“HTTP/1.0”的协议包括基本访问认证方案的规范[1]。该方案不被认为是一种安全的用户身份验证方法，因为用户名和密码是以未加密的形式通过网络传递的。本节提供了不以明文形式发送密码的方案的规范，称为“摘要访问身份验证”。
The Digest Access Authentication scheme is not intended to be a complete answer to the need for security in the World Wide Web. This scheme provides no encryption of message content. The intent is simply to create an access authentication method that avoids the most serious flaws of Basic authentication.
摘要访问认证方案并不是为了完全满足万维网的安全需求。此方案不提供消息内容的加密。其目的只是创建一种访问身份验证方法，以避免基本身份验证的最严重缺陷。
Like Basic Access Authentication, the Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value. A valid response contains a checksum (by
与基本访问认证一样，摘要方案基于简单的质询-响应范式。摘要方案挑战使用nonce值。有效响应包含校验和（通过
default, the MD5 checksum) 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. Just as with the Basic scheme, the username and password must be prearranged in some fashion not addressed by this document.
默认情况下，用户名、密码、给定的nonce值、HTTP方法和请求的URI的MD5校验和）。这样，密码永远不会以明文形式发送。与基本方案一样，用户名和密码必须以本文档未提及的方式预先安排。
An optional header allows the server to specify the algorithm used to create the checksum or digest. By default the MD5 algorithm is used and that is the only algorithm described in this document.
可选标头允许服务器指定用于创建校验和或摘要的算法。默认情况下使用MD5算法，这是本文档中描述的唯一算法。
For the purposes of this document, an MD5 digest of 128 bits is represented as 32 ASCII printable characters. The bits in the 128 bit digest are converted from most significant to least significant bit, four bits at a time to their ASCII presentation as follows. Each four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef. That is, binary 0000 gets represented by the character '0', 0001, by '1', and so on up to the representation of 1111 as 'f'.
在本文档中，128位的MD5摘要表示为32个ASCII可打印字符。128位摘要中的位从最高有效位转换为最低有效位，一次四位转换为ASCII表示，如下所示。每四位由字符0123456789abcdef中熟悉的十六进制表示法表示。也就是说，二进制0000由字符“0”、0001、1等表示，直至1111表示为“f”。
The Digest authentication scheme described in this document suffers from many known limitations. It is intended as a replacement for Basic authentication and nothing more. It is a password-based system and (on the server side) suffers from all the same problems of any password system. In particular, no provision is made in this protocol for the initial secure arrangement between user and server to establish the user's password.
本文档中描述的摘要身份验证方案存在许多已知的限制。它旨在取代基本身份验证，仅此而已。它是一个基于密码的系统，并且（在服务器端）遭受与任何密码系统相同的问题。特别是，本协议没有规定用户和服务器之间建立用户密码的初始安全安排。
Users and implementors should be aware that this protocol is not as secure as Kerberos, and not as secure as any client-side private-key scheme. Nevertheless it is better than nothing, better than what is commonly used with telnet and ftp, and better than Basic authentication.
用户和实现者应该知道，该协议不如Kerberos安全，也不如任何客户端私钥方案安全。尽管如此，它还是比什么都没有好，比telnet和ftp的常用功能好，比基本身份验证好。
The Digest Access Authentication scheme is conceptually similar to the Basic scheme. The formats of the modified WWW-Authenticate header line and the Authorization header line are specified below. In addition, a new header, Authentication-Info, is specified.
摘要访问认证方案在概念上类似于基本方案。下面指定了修改后的WWW-Authenticate头行和授权头行的格式。此外，还指定了一个新的标头，即身份验证信息。
If a server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code, and a WWW-Authenticate header as per the framework defined above, which for the digest scheme is utilized as follows:
如果服务器接收到访问保护对象的请求，且未发送可接受的授权标头，则服务器将根据上述定义的框架，以“401 Unauthorized”状态代码和WWW Authenticate标头进行响应，摘要方案使用该标头，如下所示：
challenge = "Digest" digest-challenge
挑战=“摘要”摘要挑战
digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] )
摘要挑战=1#（领域|[domain]|当前|[不透明]|[stale]|[algorithm]|[qop选项]|[auth param]）
domain = "domain" "=" <"> URI ( 1*SP URI ) <">
URI = absoluteURI | abs_path
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
opaque = "opaque" "=" quoted-string
stale = "stale" "=" ( "true" | "false" )
algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" |
token )
qop-options = "qop" "=" <"> 1#qop-value <">
qop-value = "auth" | "auth-int" | token
domain = "domain" "=" <"> URI ( 1*SP URI ) <">
URI = absoluteURI | abs_path
nonce = "nonce" "=" nonce-value
nonce-value = quoted-string
opaque = "opaque" "=" quoted-string
stale = "stale" "=" ( "true" | "false" )
algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" |
token )
qop-options = "qop" "=" <"> 1#qop-value <">
qop-value = "auth" | "auth-int" | token
The meanings of the values of the directives used above are as follows:
上述指令值的含义如下：
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 might be "registered_users@gotham.news.com".
域将显示给用户的字符串，以便他们知道使用哪个用户名和密码。此字符串应至少包含执行身份验证的主机的名称，并可能另外指示可能具有访问权限的用户集合。例如，“注册”_users@gotham.news.com".
domain A quoted, space-separated list of URIs, as specified in RFC XURI [7], that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL (see section 1.2 above) of the server being accessed. An absoluteURI in this list may refer to a different server than the one being accessed. 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 directive is omitted or its value is empty, the client should assume that the protection space consists of all URIs on the responding server.
域一个引用的、以空间分隔的URI列表，如RFC XURI[7]中所述，用于定义保护空间。如果URI是abs_路径，那么它是相对于被访问服务器的规范根URL（参见上面的1.2节）的。此列表中的绝对URI可能指的是与正在访问的服务器不同的服务器。客户端可以使用此列表来确定可以为其发送相同身份验证信息的URI集：可以假定在此列表中具有URI作为前缀的任何URI（在将两者都设置为绝对后）位于相同的保护空间中。如果省略此指令或其值为空，则客户端应假定保护空间由响应服务器上的所有URI组成。
This directive is not meaningful in Proxy-Authenticate headers, for which the protection space is always the entire proxy; if present it should be ignored.
此指令在代理身份验证头中没有意义，因为保护空间始终是整个代理；如果存在，则应忽略它。
nonce A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that this string be base64 or hexadecimal data. Specifically, since the string is passed in the header lines as a quoted string, the double-quote character is not allowed.
nonce服务器指定的数据字符串，每次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 base 64 encoding of
nonce的内容取决于实现。实施的质量取决于一个好的选择。例如，nonce可以构造为的基64编码
time-stamp H(time-stamp ":" ETag ":" private-key)
time-stamp H(time-stamp ":" ETag ":" private-key)
where time-stamp is a server-generated time or other non-repeating value, ETag is the value of the HTTP ETag header associated with the requested entity, and private-key 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 and reject the request if it did not match the nonce from that header or if the time-stamp 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. (Note: 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 originally got it. However, that would break proxy farms, where requests from a single user often go through different proxies in the farm. Also, IP address spoofing is not that hard.)
其中，时间戳是服务器生成的时间或其他非重复值，ETag是与请求实体关联的HTTP ETag头的值，私钥是仅服务器知道的数据。对于这种形式的nonce，服务器将在接收到客户端身份验证标头后重新计算哈希部分，如果请求与来自该标头的nonce不匹配，或者如果时间戳值不够新，则拒绝该请求。通过这种方式，服务器可以限制nonce的有效时间。ETag的包含阻止了对资源更新版本的重播请求。（注意：将客户机的IP地址包含在nonce中似乎可以让服务器将nonce的重用限制在最初获得它的同一客户机上。但是，这会破坏代理服务器场，其中来自单个用户的请求通常通过服务器场中的不同代理。此外，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 time-stamp for GET requests. For more details on the issues involved see section 4. of this document.
为了防止重播攻击，实现可能会选择不接受以前使用的nonce或以前使用的摘要。或者，实现可以选择对POST或PUT请求使用一次性nonce或digest，对GET请求使用时间戳。有关所涉及问题的更多详细信息，请参见第4节。本文件的附件。
The nonce is opaque to the client.
nonce对客户端是不透明的。
opaque A string of data, specified by the server, which should be returned by the client unchanged in the Authorization header 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 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为TRUE（不区分大小写），则客户端可能只希望使用新的加密响应重试请求，而无需为用户重新输入新的用户名和密码。只有当服务器接收到一个nonce无效但具有该nonce的有效摘要（指示客户端知道正确的用户名/密码）的请求时，才应将stale设置为TRUE。如果stale为FALSE，或者除TRUE以外的任何值，或者stale指令不存在，则用户名和/或密码无效，必须获取新值。
algorithm A string indicating a pair of algorithms used to produce the digest and a checksum. 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”。如果不理解算法，则应忽略挑战（如果存在多个挑战，则使用不同的挑战）。
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 checksum algorithm to the data "data" will be denoted H(data). The notation unq(X) means the value of the quoted-string X without the surrounding quotes.
在本文件中，通过将摘要算法应用于具有机密“secret”的数据“data”而获得的字符串将用KD（secret，data）表示，通过将校验和算法应用于数据“data”而获得的字符串将用H（data）表示。符号unq（X）表示带引号的字符串X的值，不带引号。
For the "MD5" and "MD5-sess" algorithms
对于“MD5”和“MD5 sess”算法
H(data) = MD5(data)
H(data) = MD5(data)
and
和
KD(secret, data) = H(concat(secret, ":", data))
KD(secret, data) = H(concat(secret, ":", data))
i.e., the digest is the MD5 of the secret concatenated with a colon concatenated with the data. The "MD5-sess" algorithm is intended to allow efficient 3rd party authentication servers; for the difference in usage, see the description in section 3.2.2.2.
i、 例如，摘要是与数据连接的冒号连接的秘密的MD5。“MD5 sess”算法旨在允许高效的第三方认证服务器；有关用法的差异，请参见第3.2.2.2节中的说明。
qop-options This directive is optional, but is made so only for backward compatibility with RFC 2069 [6]; it SHOULD be used by all implementations compliant with this version of the Digest scheme. If present, 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
qop选项本指令是可选的，但仅用于与RFC 2069[6]的向后兼容性；所有符合此版本摘要方案的实现都应该使用它。如果存在，它是一个由一个或多个令牌组成的带引号的字符串，表示服务器支持的“保护质量”值。值“auth”表示身份验证；值“auth int”表示具有完整性保护的身份验证；见
descriptions below for calculating the response directive value for the application of this choice. Unrecognized options MUST be ignored.
下面介绍如何计算此选项应用程序的响应指令值。必须忽略无法识别的选项。
auth-param This directive allows for future extensions. Any unrecognized directive MUST be ignored.
auth param此指令允许将来扩展。必须忽略任何无法识别的指令。
The client is expected to retry the request, passing an Authorization header line, which is defined according to the framework above, utilized as follows.
客户机将重试请求，传递授权头行，授权头行根据上述框架定义，使用如下。
credentials = "Digest" digest-response digest-response = 1#( username | realm | nonce | digest-uri | response | [ algorithm ] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param] )
credentials=“Digest”Digest response Digest response=1#（用户名| realm | nonce |摘要uri |响应|[算法]|[cnonce]|[不透明]|[message qop]|[nonce count]|[auth param]）
username = "username" "=" username-value
username-value = quoted-string
digest-uri = "uri" "=" digest-uri-value
digest-uri-value = request-uri ; As specified by HTTP/1.1
message-qop = "qop" "=" qop-value
cnonce = "cnonce" "=" cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" "=" nc-value
nc-value = 8LHEX
response = "response" "=" request-digest
request-digest = <"> 32LHEX <">
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
username = "username" "=" username-value
username-value = quoted-string
digest-uri = "uri" "=" digest-uri-value
digest-uri-value = request-uri ; As specified by HTTP/1.1
message-qop = "qop" "=" qop-value
cnonce = "cnonce" "=" cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" "=" nc-value
nc-value = 8LHEX
response = "response" "=" request-digest
request-digest = <"> 32LHEX <">
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
The values of the opaque and algorithm fields must be those supplied in the WWW-Authenticate response header for the entity being requested.
不透明字段和算法字段的值必须是被请求实体的WWW Authenticate响应头中提供的值。
response A string of 32 hex digits computed as defined below, which proves that the user knows a password
响应一个由32个十六进制数字组成的字符串，按以下定义计算，证明用户知道密码
username The user's name in the specified realm.
用户名指定域中的用户名。
digest-uri The URI from Request-URI of the Request-Line; duplicated here because proxies are allowed to change the Request-Line in transit.
digest uri来自请求行的请求uri的uri；此处重复，因为允许代理更改传输中的请求行。
qop Indicates what "quality of protection" the client has applied to the message. If present, its value MUST be one of the alternatives the server indicated it supports in the WWW-Authenticate header. These values affect the computation of the request-digest. Note that this is a single token, not a quoted list of alternatives as in WWW- Authenticate. This directive is optional in order to preserve backward compatibility with a minimal implementation of RFC 2069 [6], but SHOULD be used if the server indicated that qop is supported by providing a qop directive in the WWW-Authenticate header field.
qop表示客户端应用于消息的“保护质量”。如果存在，则其值必须是服务器在WWW Authenticate标头中指示其支持的备选方案之一。这些值会影响请求摘要的计算。请注意，这是一个单独的令牌，而不是WWW-Authenticate中引用的备选方案列表。为了保持与RFC 2069[6]的最小实现的向后兼容性，此指令是可选的，但如果服务器通过在WWW Authenticate header字段中提供qop指令指示支持qop，则应使用此指令。
cnonce This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. The cnonce-value is an opaque quoted 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 response-digest and request-digest values.
cnonce如果发送qop指令，则必须指定此项（请参见上文），如果服务器未在WWW Authenticate标头字段中发送qop指令，则不得指定此项。cnonce值是客户端提供的一个不透明的带引号的字符串值，客户端和服务器都使用它来避免选择明文攻击，提供相互身份验证，并提供一些消息完整性保护。有关响应摘要和请求摘要值的计算，请参见下面的说明。
nonce-count This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. 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 directive 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 request-digest value.
nonce count如果发送了qop指令（参见上文），则必须指定此值；如果服务器未在WWW Authenticate标头字段中发送qop指令，则不得指定此值。nc值是客户端使用此请求中的nonce值发送的请求数（包括当前请求）的十六进制计数。例如，在响应给定nonce值而发送的第一个请求中，客户端发送“nc=00000001”。此指令的目的是允许服务器通过维护自己的此计数副本来检测请求重播-如果相同的nc值出现两次，则该请求为重播。请参见下面对请求摘要值构造的描述。
auth-param This directive allows for future extensions. Any unrecognized directive MUST be ignored.
auth param此指令允许将来扩展。必须忽略任何无法识别的指令。
If a directive or its value is improper, or required directives are missing, the proper response is 400 Bad Request. If the request-digest is invalid, then a login failure should be logged, since repeated login failures from a single client may indicate an attacker attempting to guess passwords.
如果指令或其值不正确，或者缺少必需的指令，则正确的响应是400错误请求。如果请求摘要无效，则应记录登录失败，因为来自单个客户端的重复登录失败可能表明攻击者试图猜测密码。
The definition of request-digest 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”：
request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
If the "qop" directive is not present (this construction is for compatibility with RFC 2069):
如果“qop”指令不存在（此结构用于与RFC 2069兼容）：
request-digest =
<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
<">
request-digest =
<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
<">
See below for the definitions for A1 and A2.
A1和A2的定义见下文。
If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is:
如果“algorithm”指令的值为“MD5”或未指定，则A1为：
A1 = unq(username-value) ":" unq(realm-value) ":" passwd
A1 = unq(username-value) ":" unq(realm-value) ":" passwd
where
哪里
passwd = < user's password >
passwd = < user's password >
If the "algorithm" directive's value is "MD5-sess", then A1 is calculated only once - on the first request by the client following receipt of a WWW-Authenticate challenge from the server. It uses the server nonce from that challenge, and the first client nonce value to construct A1 as follows:
如果“algorithm”指令的值是“MD5 sess”，那么A1只计算一次——在客户端收到来自服务器的WWW身份验证质询后的第一个请求时。它使用来自该质询的服务器nonce和第一个客户端nonce值来构造A1，如下所示：
A1 = H( unq(username-value) ":" unq(realm-value)
":" passwd )
":" unq(nonce-value) ":" unq(cnonce-value)
A1 = H( unq(username-value) ":" unq(realm-value)
":" passwd )
":" unq(nonce-value) ":" unq(cnonce-value)
This creates a 'session key' for the authentication of subsequent requests and responses which 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.3.) Because the server need only use the hash of the user credentials in order to create the A1 value, this construction could 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.
第3.3节）由于服务器只需要使用用户凭据的哈希值来创建A1值，因此此构造可以与第三方身份验证服务结合使用，以便web服务器不需要实际的密码值。此类协议的规范超出了本规范的范围。
If the "qop" directive's value is "auth" or is unspecified, then A2 is:
如果“qop”指令的值为“auth”或未指定，则A2为：
A2 = Method ":" digest-uri-value
A2=方法“：”摘要uri值
If the "qop" value is "auth-int", then A2 is:
如果“qop”值为“auth int”，则A2为：
A2 = Method ":" digest-uri-value ":" H(entity-body)
A2 = Method ":" digest-uri-value ":" H(entity-body)
Note that the value of many of the directives, 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 includes the fields
请注意，许多指令的值（如“username value”）定义为“带引号的字符串”。然而，“unq”符号表示在形成字符串A1时去掉了周围的引号。因此，如果授权标头包含字段
username="Mufasa", realm=myhost@testrealm.com
username="Mufasa", realm=myhost@testrealm.com
and the user Mufasa has password "Circle Of Life" then H(A1) would be H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks in the digested string.
用户Mufasa拥有密码“生命周期”，那么H（A1）将是H（Mufasa:myhost@testrealm.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@testrealm.com:Circle Of Life
Mufasa:myhost@testrealm.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 which 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
还要注意，如果应用了完整性保护（qop=auth int），则H（实体体）是实体体的哈希，而不是消息体-它是在发送方应用任何传输编码之前计算的
and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded headers in each part of any multipart content-type.
在收件人将其移除后。请注意，这包括任何多部分内容类型的每个部分中的多部分边界和嵌入头。
The "Method" value is the HTTP request method as specified in section 5.1.1 of [2]. The "request-uri" value is the Request-URI from the request line as specified in section 5.1.2 of [2]. This may be "*", an "absoluteURL" or an "abs_path" as specified in section 5.1.2 of [2], but it MUST agree with the Request-URI. In particular, it MUST be an "absoluteURL" if the Request-URI is an "absoluteURL". The "cnonce-value" is an optional client-chosen value whose purpose is to foil chosen plaintext attacks.
“方法”值是[2]第5.1.1节中规定的HTTP请求方法。“请求uri”值是[2]第5.1.2节中指定的来自请求行的请求uri。这可能是“*”、“绝对URL”或[2]第5.1.2节中规定的“abs_路径”，但必须与请求URI一致。特别是，如果请求URI是“绝对URL”，则它必须是“绝对URL”。“cnonce值”是可选的客户端选择值，其目的是抵御选择的明文攻击。
The authenticating server must assure that the resource designated by the "uri" directive 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 interact with shared caches. The HTTP/1.1 protocol specifies that when a shared cache (see section 13.7 of [2]) has received a request containing an Authorization header and a response from relaying that request, it MUST NOT return that response as a reply to any other request, unless one of two Cache-Control (see section 14.9 of [2]) directives was present in the response. If the original response included the "must-revalidate" Cache-Control directive, the cache MAY use the entity of that response in replying to a subsequent request, but MUST first revalidate it with the origin server, using the request headers from the new request to allow the origin server to authenticate the new request. Alternatively, if the original response included the "public" Cache-Control directive, the response entity MAY be returned in reply to any subsequent request.
实现者应该知道经过身份验证的事务如何与共享缓存交互。HTTP/1.1协议规定，当共享缓存（见[2]第13.7节）收到包含授权标头的请求和中继该请求的响应时，它不得将该响应作为对任何其他请求的响应返回，除非响应中存在两个缓存控制（见[2]第14.9节）指令之一。如果原始响应包含“必须重新验证”缓存控制指令，则缓存可以在响应后续请求时使用该响应的实体，但必须首先使用新请求的请求头向源服务器重新验证该实体，以允许源服务器验证新请求。或者，如果原始响应包括“公共”缓存控制指令，则响应实体可以返回以响应任何后续请求。
The Authentication-Info header is used by the server to communicate some information regarding the successful authentication in the response.
服务器使用Authentication Info报头在响应中传递有关成功身份验证的一些信息。
AuthenticationInfo = "Authentication-Info" ":" auth-info
auth-info = 1#(nextnonce | [ message-qop ]
| [ response-auth ] | [ cnonce ]
| [nonce-count] )
nextnonce = "nextnonce" "=" nonce-value
response-auth = "rspauth" "=" response-digest
response-digest = <"> *LHEX <">
AuthenticationInfo = "Authentication-Info" ":" auth-info
auth-info = 1#(nextnonce | [ message-qop ]
| [ response-auth ] | [ cnonce ]
| [nonce-count] )
nextnonce = "nextnonce" "=" nonce-value
response-auth = "rspauth" "=" response-digest
response-digest = <"> *LHEX <">
The value of the nextnonce directive is the nonce the server wishes the client to use for a future authentication response. The server may send the Authentication-Info header with a nextnonce field as a means of implementing one-time or otherwise changing nonces. If the nextnonce field is present the client SHOULD use it when constructing the Authorization header 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的手段。如果存在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 directive 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 nonce-count can retain most of the security advantages of a new server nonce without the deleterious affects on pipelining.
服务器实现应该仔细考虑使用该机制的性能影响；如果每个响应都包含必须在服务器接收的下一个请求上使用的NEXTNOCE指令，则无法执行管道化请求。应考虑允许在有限的时间内使用旧的nonce值以允许请求管道化的性能与安全权衡。使用nonce计数可以保留新服务器nonce的大部分安全优势，而不会对管道产生有害影响。
message-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 message-qop directive in the response as was sent by the client in the corresponding request.
消息qop表示应用于服务器响应的“保护质量”选项。值“auth”表示身份验证；值“auth int”表示具有完整性保护的身份验证。服务器应在响应中使用与客户端在相应请求中发送的相同的消息qop指令值。
The optional response digest in the "response-auth" directive 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 "response-digest" value is calculated as for the "request-digest" in the Authorization header, except that if "qop=auth" or is not specified in the Authorization header for the request, A2 is
“response auth”指令中的可选响应摘要支持相互身份验证——服务器证明它知道用户的秘密，并且使用qop=auth int还提供有限的响应完整性保护。“响应摘要”值是针对授权标头中的“请求摘要”计算的，除非在授权标头中没有为请求指定“qop=auth”或A2
A2 = ":" digest-uri-value
A2=“：”摘要uri值
and if "qop=auth-int", then A2 is
如果“qop=auth int”，则A2为
A2 = ":" digest-uri-value ":" H(entity-body)
A2 = ":" digest-uri-value ":" H(entity-body)
where "digest-uri-value" is the value of the "uri" directive on the Authorization header in the request. The "cnonce-value" and "nc-value" MUST be the ones for the client request to which this message is the response. The "response-auth", "cnonce", and "nonce-count" directives MUST BE present if "qop=auth" or "qop=auth-int" is specified.
其中，“digest uri value”是请求中授权头上的“uri”指令的值。“cnonce值”和“nc值”必须是此消息响应的客户端请求的值。如果指定了“qop=auth”或“qop=auth int”，则必须存在“response auth”、“cnonce”和“nonce count”指令。
The Authentication-Info header is allowed in the trailer of an HTTP message transferred via chunked transfer-coding.
通过分块传输编码传输的HTTP消息的尾部允许使用身份验证信息头。
Upon receiving the Authorization header, 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) performed by the client, and compare the result to the given request-digest value.
收到授权标头后，服务器可以通过查找与提交的用户名对应的密码来检查其有效性。然后，服务器必须执行客户端执行的相同摘要操作（例如MD5），并将结果与给定的请求摘要值进行比较。
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 may 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 in future requests within that protection space. The Authorization header 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 information, even though the nonce value included might not be fresh. Alternatively, the server may return a 401 response with a new nonce value, 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值可能不是新的。或者，服务器可以返回带有新nonce值的401响应，导致客户端重试该请求；通过在此响应中指定stale=TRUE，服务器会告诉客户端使用新的nonce重试，但不会提示输入新的用户名和密码。
Because the client is required to return the value of the opaque directive given to it by the server for the duration of a session, the opaque data may 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 directive whose value includes a URI on the second server, and an opaque directive whose value
由于要求客户端在会话期间返回服务器给它的不透明指令的值，因此不透明数据可用于传输身份验证会话状态信息。（请注意，通过将状态包含在nonce中，也可以更容易、更安全地完成任何此类使用。）例如，服务器可以负责验证实际位于另一台服务器上的内容。它可以通过让第一个401响应包含一个域指令（其值包括第二台服务器上的URI）和一个不透明指令（其值为
contains the state information. The client will retry the request, at which time the server might respond with a 301/302 redirection, pointing to the URI on the second server. The client will follow the redirection, and pass an Authorization header , including the <opaque> data.
包含状态信息。客户端将重试该请求，此时服务器可能会响应301/302重定向，指向第二台服务器上的URI。客户端将遵循重定向，并传递授权标头，包括<opaque>数据。
As with the basic scheme, proxies must be completely transparent in the Digest access authentication scheme. That is, they must forward the WWW-Authenticate, Authentication-Info and Authorization headers 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 headers described in section 3.6 below.
与基本方案一样，摘要访问认证方案中的代理必须是完全透明的。也就是说，他们必须转发WWW身份验证、身份验证信息和授权头，不受影响。如果代理希望在将请求转发到服务器之前对客户端进行身份验证，则可以使用下面第3.6节中描述的代理身份验证和代理授权头进行身份验证。
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 may want 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.
服务器可能需要摘要作为其身份验证方法，即使服务器不知道客户端支持它。如果服务器仅指定它无法处理的身份验证方案，则鼓励客户端正常失败。
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.nowhere.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.nowhere.org/dir/index.html". 客户机和服务器都知道此文档的用户名是“Mufasa”，密码是“Circle Of Life”（三个单词之间各有一个空格）。
The first time the client requests the document, no Authorization header is sent, so the server responds with:
客户机第一次请求文档时，不会发送授权标头，因此服务器会响应：
HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"
HTTP/1.1 401未经授权的WWW身份验证：摘要域=”testrealm@host.com，qop=“auth，auth int”，nonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093”，不透明=“5CC069C403EBAF9F0171E9517F40E41”
The client may prompt the user for the username and password, after which it will respond with a new request, including the following Authorization header:
客户端可能会提示用户输入用户名和密码，然后会以新的请求进行响应，包括以下授权标头：
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
The digest authentication scheme may 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 headers. These headers are instances of the Proxy-Authenticate and Proxy-Authorization headers specified in sections 10.33 and 10.34 of the HTTP/1.1 specification [2] 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 which requires authentication, the proxy/server must issue the "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header. The digest-challenge used in the Proxy-Authenticate header is the same as that for the WWW-Authenticate header as defined above in section 3.2.1.
摘要认证方案还可用于通过使用代理认证和代理授权报头来认证用户到代理、代理到代理或代理到源服务器。这些头是HTTP/1.1规范[2]第10.33节和第10.34节中指定的代理身份验证和代理授权头的实例，其行为受其中描述的限制。代理身份验证的事务与前面描述的事务非常相似。收到需要身份验证的请求后，代理/服务器必须发出带有“代理身份验证”头的“407需要代理身份验证”响应。代理身份验证标头中使用的摘要质询与上文第3.2.1节中定义的WWW身份验证标头中使用的摘要质询相同。
The client/proxy must then re-issue the request with a Proxy-Authorization header, with directives as specified for the Authorization header in section 3.2.2 above.
然后，客户机/代理必须使用上面第3.2.2节中为授权标头指定的指令，使用代理授权标头重新发出请求。
On subsequent responses, the server sends Proxy-Authentication-Info with directives 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.
请注意，原则上可以要求客户机向代理服务器和终端服务器进行自身身份验证，但决不能在同一响应中进行。
4 Security Considerations
4安全考虑
The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier. HTTP does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security or the addition of enhancements (such as schemes to use one-time passwords) to Basic authentication.
基本身份验证方案不是一种安全的用户身份验证方法，也不会以任何方式保护实体，该实体通过用作载体的物理网络以明文形式传输。HTTP不会阻止使用其他身份验证方案和加密机制来提高安全性，也不会阻止向基本身份验证添加增强功能（例如使用一次性密码的方案）。
The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address.
基本身份验证中最严重的缺陷是，它导致用户密码在物理网络上以明文形式传输。摘要身份验证试图解决的就是这个问题。
Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used (without enhancements) to protect sensitive or valuable information.
由于基本身份验证涉及密码的明文传输，因此不应使用（未经增强）来保护敏感或有价值的信息。
A common use of Basic authentication is for identification purposes -- requiring the user to provide a user name and password as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major concern. This is only correct if the server issues both user name and password to the users and in particular does not allow the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid the task of maintaining multiple passwords.
基本身份验证的一个常见用途是用于身份验证——要求用户提供用户名和密码作为身份验证的手段，例如，用于收集服务器上的准确使用统计数据。当以这种方式使用时，人们很容易认为，如果非法获取受保护的文件不是一个主要问题，那么使用它就没有危险。只有当服务器同时向用户发出用户名和密码，特别是不允许用户选择自己的密码时，这才是正确的。这种危险是因为天真的用户经常重复使用一个密码来避免维护多个密码的任务。
If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the server but also unauthorized access to any other resources on other systems that the user protects with the same password. Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all those sites if this information is not maintained in a secure fashion.
如果服务器允许用户选择自己的密码，那么威胁不仅是未经授权访问服务器上的文档，而且是未经授权访问用户使用相同密码保护的其他系统上的任何其他资源。此外，在服务器的密码数据库中，许多密码也可能是其他站点的用户密码。因此，如果不以安全的方式维护此类信息，则此类系统的所有者或管理员可能会使系统的所有用户面临未经授权访问所有这些站点的风险。
Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with Digest Authentication. Server implementers SHOULD guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous for a server to simply turn over a connection to a gateway. That gateway can then use the persistent connection mechanism to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable by the client.
基本身份验证也容易受到假冒服务器的欺骗。如果用户在连接到恶意服务器或网关时，能够被引导相信他正在连接到包含受基本身份验证保护的信息的主机，那么攻击者可以请求密码，存储密码以供以后使用，并假装出错。这种类型的攻击在摘要身份验证中是不可能的。服务器实现者应该防止网关或CGI脚本进行此类伪造。特别是，服务器简单地将连接切换到网关是非常危险的。然后，该网关可以使用持久连接机制与客户端进行多个事务，同时以客户端无法检测到的方式模拟原始服务器。
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 LDAP [10], POP and IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and even more dangerous Basic mechanism.
然而，它明显强于（例如）CRAM-MD5，后者已被提议用于LDAP[10]、POP和IMAP（参见RFC 2195[9]）。它的目的是取代更弱、甚至更危险的基本机制。
Digest Authentication offers no confidentiality protection beyond protecting the actual 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 qop=auth-int mechanism is used, those parts of the message used in the calculation of the WWW-Authenticate and Authorization header field response directive 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 Authenticate and Authorization header field response指令值（参见上文第3.2节）时使用的消息部分将受到保护。大多数标题字段及其值都可以作为中间人攻击的一部分进行修改。
Many needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs TLS or SHTTP are more appropriate protocols. 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. Any service in present use that uses Basic should be switched to Digest as soon as practical.
摘要身份验证无法满足安全HTTP事务的许多需求。对于这些需求，TLS或SHTTP是更合适的协议。特别是摘要身份验证不能用于任何需要保密保护的交易。尽管如此，仍然存在许多功能，对于这些功能，摘要身份验证既有用又合适。目前使用的任何使用Basic的服务都应该尽快转换为摘要服务。
The Digest scheme uses a server-specified nonce to seed the generation of the request-digest value (as specified in section 3.2.2.1 above). As shown in the example nonce in section 3.2.1, 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 4.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 directive in the Authentication-Info header field of every response. This protects against even an immediate replay attack, but has a high cost checking nonce values, and perhaps more important 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.2.2.1节所述）。如第3.2.1节中的示例nonce所示，服务器可以自由构造nonce，以便仅可从特定客户端、针对特定资源、在有限的时间段或使用次数或任何其他限制条件下使用nonce。这样做可以增强针对重播攻击等提供的保护（参见4.5）。但是，应该注意的是，为生成和检查nonce而选择的方法也会影响性能和资源。例如，服务器可以通过维护每个最近发出的nonce是否已返回的记录，并在每个响应的认证信息报头字段中发送下一个nonce指令，选择允许每个nonce值仅使用一次。这甚至可以防止立即重播攻击，但检查nonce值的成本很高，而且可能更重要的是，这会导致任何流水线请求的身份验证失败（可能会返回过时的nonce指示）。类似地，合并特定于请求的元素（如资源的Etag值）会将nonce的使用限制在该版本的资源上，并且还会破坏管道。因此，对有副作用但对无副作用的方法具有不可接受的性能的方法来说，这样做可能是有用的。
Both Digest and Basic Authentication are very much on the weak end of the security strength spectrum. But a comparison between the two points out the utility, even necessity, of replacing Basic by Digest.
摘要认证和基本认证在安全强度谱中都非常薄弱。但是，通过对两者的比较，可以看出用摘要取代基本内容的效用，甚至是必要性。
The greatest threat to the type of transactions for which these protocols are used is network snooping. This kind of transaction might involve, for example, online access to a database whose use is restricted to paying subscribers. With Basic authentication an eavesdropper can obtain the password of the user. This not only permits him to access anything in the database, but, often worse, will permit access to anything else the user protects with the same password.
对使用这些协议的事务类型的最大威胁是网络窥探。例如，此类交易可能涉及对数据库的在线访问，该数据库的使用仅限于付费订户。通过基本身份验证，窃听者可以获得用户的密码。这不仅允许他访问数据库中的任何内容，而且更糟糕的是，还允许他访问用户使用相同密码保护的任何其他内容。
By contrast, with Digest Authentication the eavesdropper only gets access to the transaction in question and not to the user's password. The information gained by the eavesdropper would permit a replay attack, but only with a request for the same document, and even that may be limited by the server's choice of nonce.
相比之下，使用摘要身份验证，窃听者只能访问有问题的事务，而不能访问用户的密码。窃听者获得的信息将允许重播攻击，但只允许对同一文档进行请求，甚至可能会受到服务器选择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 time-stamp, 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 time-stamp expires. Digesting the client IP and time-stamp in the nonce permits an implementation which 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 which will not be honored for a second use. This requires the overhead of the server
对于无法容忍重播攻击的应用程序，服务器可以使用一次性的nonce值，而第二次使用时将不受尊重。这需要服务器的开销
remembering which nonce values have been used until the nonce time-stamp (and hence the digest built with it) has expired, but it effectively protects against replay attacks.
记住在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 form 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 4.8.
实现必须特别注意使用POST和PUT请求重播攻击的可能性。除非服务器使用一次性或其他限制使用的nonce和/或坚持使用qop=auth int的完整性保护，否则攻击者可能会使用伪造的表单数据或其他消息体重播成功请求中的有效凭据。即使使用完整性保护，头字段中的大多数元数据也不受保护。正确的nonce生成和检查可以防止重播以前使用的有效凭据，但请参见4.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（身份验证）响应的多个质询，每个质询可能使用不同的身份验证方案。用户代理必须选择使用其理解的最强身份验证方案，并根据该质询向用户请求凭据。
Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only include Basic if it is minimally acceptable.
请注意，许多浏览器将只识别Basic，并要求它是第一个提交的身份验证方案。只有在最低限度可接受的情况下，服务器才应包含Basic。
When the server offers choices of authentication schemes using the WWW-Authenticate header, the strength of the resulting authentication is only as good as that of the of the weakest of the authentication schemes. See section 4.8 below for discussion of particular attack scenarios that exploit multiple authentication schemes.
当服务器使用WWW Authenticate标头提供身份验证方案的选择时，生成的身份验证的强度仅与最弱的身份验证方案的强度相同。有关利用多个身份验证方案的特定攻击场景的讨论，请参见下文第4.8节。
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.
服务器可以通过不允许用户选择字典中的密码来减轻此攻击。
Both Basic and Digest authentication are 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 produce 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 [8].
通过摘要身份验证，MITM或恶意服务器可以任意选择客户端用于计算响应的nonce。这称为“选择明文”攻击。选择nonce的能力使密码分析变得更容易[8]。
However, no way to analyze the MD5 one-way function used by Digest using chosen plaintext is currently known.
但是，目前还不知道如何使用选定的明文分析摘要使用的MD5单向函数。
The countermeasure against this attack is for clients to be configured to require the use of the optional "cnonce" directive; 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 to for clients to be configured to require the use of the optional "cnonce" directive.
针对此攻击的对策是将客户端配置为需要使用可选的“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 to for clients to be configured to require the use of the optional "cnonce" directive.
针对此攻击的对策是将客户端配置为需要使用可选的“cnonce”指令。
Basic Authentication is vulnerable to spoofing by counterfeit servers. If a user can be led to believe that she is connecting to a host containing information protected by a password she knows, when in fact she is connecting to a hostile server, then the hostile server can request a password, store it away for later use, and feign an error. This type of attack is more difficult with Digest Authentication -- but the client must know to demand that Digest authentication be used, perhaps using some of the techniques described above to counter "man-in-the-middle" attacks. Again, the user can be helped in detecting this attack by a visual indication of the authentication mechanism in use with appropriate guidance in interpreting the implications of each scheme.
基本身份验证容易受到假冒服务器的欺骗。如果可以引导用户相信她正在连接到一个主机，该主机包含她知道的密码保护的信息，而实际上她正在连接到一个恶意服务器，那么恶意服务器可以请求一个密码，将其存储起来供以后使用，并假装出错。这种类型的攻击在摘要身份验证中更加困难——但是客户机必须知道如何要求使用摘要身份验证，也许可以使用上面描述的一些技术来对抗“中间人”攻击。同样，用户可以通过视觉指示正在使用的身份验证机制，并在解释每个方案的含义时提供适当的指导，来帮助用户检测这种攻击。
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 need 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 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).
这样做的安全含义是，如果此密码文件被破坏，则攻击者可以立即使用此域访问服务器上的文档。与标准UNIX密码文件不同，访问与此文件关联的服务器域中的文档时，不需要解密此信息。另一方面，需要解密，或者更可能是暴力攻击来获取用户的密码。这就是域是存储在密码文件中的摘要数据的一部分的原因。这意味着，如果一个摘要身份验证密码文件被破坏，它不会自动破坏具有相同用户名和密码的其他文件（尽管它会使它们遭受暴力攻击）。
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 which 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.
第二个结果是，领域字符串在任何单个用户可能使用的所有领域中都应该是唯一的。尤其是领域字符串应该包括进行身份验证的主机的名称。客户端无法对服务器进行身份验证是摘要身份验证的一个弱点。
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 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 satisfied with a nonce like the one recommended above restricted to a single IP address and a single ETag or with a limited lifetime.
根据现代密码标准，摘要认证很弱。但是，对于许多目的来说，它作为基本身份验证的替代品是很有价值的。它弥补了一些（但不是全部）基本身份验证的弱点。其强度可能因实施情况而异。特别是nonce的结构（取决于服务器实现）可能会影响重播攻击的易用性。一系列服务器选项是合适的，因为，例如，一些实现可能愿意接受一次性nonce或digest的服务器开销，以消除重播的可能性。其他人可能会对上面推荐的仅限于单个IP地址和单个ETag或具有有限生存期的nonce感到满意。
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.
底线是*任何*兼容的实现在加密标准下都相对较弱，但*任何*兼容的实现都远远优于基本身份验证。
5 Sample implementation
5示例实现
The following code implements the calculations of H(A1), H(A2), request-digest and response-digest, and a test program which computes the values used in the example of section 3.5. It uses the MD5 implementation from RFC 1321.
以下代码实现了H（A1）、H（A2）、请求摘要和响应摘要的计算，以及计算第3.5节示例中使用的值的测试程序。它使用RFC1321中的MD5实现。
File "digcalc.h":
文件“digcalc.h”：
#define HASHLEN 16
typedef char HASH[HASHLEN];
#define HASHHEXLEN 32
typedef char HASHHEX[HASHHEXLEN+1];
#define IN
#define OUT
#define HASHLEN 16
typedef char HASH[HASHLEN];
#define HASHHEXLEN 32
typedef char HASHHEX[HASHHEXLEN+1];
#define IN
#define OUT
/* calculate H(A1) as per HTTP Digest spec */
void DigestCalcHA1(
IN char * pszAlg,
IN char * pszUserName,
IN char * pszRealm,
IN char * pszPassword,
IN char * pszNonce,
IN char * pszCNonce,
OUT HASHHEX SessionKey
);
/* calculate H(A1) as per HTTP Digest spec */
void DigestCalcHA1(
IN char * pszAlg,
IN char * pszUserName,
IN char * pszRealm,
IN char * pszPassword,
IN char * pszNonce,
IN char * pszCNonce,
OUT HASHHEX SessionKey
);
/* calculate request-digest/response-digest as per HTTP Digest spec */
void DigestCalcResponse(
IN HASHHEX HA1, /* H(A1) */
IN char * pszNonce, /* nonce from server */
IN char * pszNonceCount, /* 8 hex digits */
IN char * pszCNonce, /* client nonce */
IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
IN char * pszMethod, /* method from the request */
IN char * pszDigestUri, /* requested URL */
IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
OUT HASHHEX Response /* request-digest or response-digest */
);
/* calculate request-digest/response-digest as per HTTP Digest spec */
void DigestCalcResponse(
IN HASHHEX HA1, /* H(A1) */
IN char * pszNonce, /* nonce from server */
IN char * pszNonceCount, /* 8 hex digits */
IN char * pszCNonce, /* client nonce */
IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
IN char * pszMethod, /* method from the request */
IN char * pszDigestUri, /* requested URL */
IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
OUT HASHHEX Response /* request-digest or response-digest */
);
File "digcalc.c":
文件“digcalc.c”：
#include <global.h>
#include <md5.h>
#include <global.h>
#include <md5.h>
#include <string.h>
#include "digcalc.h"
#include <string.h>
#include "digcalc.h"
void CvtHex(
IN HASH Bin,
OUT HASHHEX Hex
)
{
unsigned short i;
unsigned char j;
void CvtHex(
IN HASH Bin,
OUT HASHHEX Hex
)
{
unsigned short i;
unsigned char j;
for (i = 0; i < HASHLEN; i++) {
j = (Bin[i] >> 4) & 0xf;
if (j <= 9)
Hex[i*2] = (j + '0');
else
Hex[i*2] = (j + 'a' - 10);
j = Bin[i] & 0xf;
if (j <= 9)
Hex[i*2+1] = (j + '0');
else
Hex[i*2+1] = (j + 'a' - 10);
};
Hex[HASHHEXLEN] = '\0';
};
for (i = 0; i < HASHLEN; i++) {
j = (Bin[i] >> 4) & 0xf;
if (j <= 9)
Hex[i*2] = (j + '0');
else
Hex[i*2] = (j + 'a' - 10);
j = Bin[i] & 0xf;
if (j <= 9)
Hex[i*2+1] = (j + '0');
else
Hex[i*2+1] = (j + 'a' - 10);
};
Hex[HASHHEXLEN] = '\0';
};
/* calculate H(A1) as per spec */
void DigestCalcHA1(
IN char * pszAlg,
IN char * pszUserName,
IN char * pszRealm,
IN char * pszPassword,
IN char * pszNonce,
IN char * pszCNonce,
OUT HASHHEX SessionKey
)
{
MD5_CTX Md5Ctx;
HASH HA1;
/* calculate H(A1) as per spec */
void DigestCalcHA1(
IN char * pszAlg,
IN char * pszUserName,
IN char * pszRealm,
IN char * pszPassword,
IN char * pszNonce,
IN char * pszCNonce,
OUT HASHHEX SessionKey
)
{
MD5_CTX Md5Ctx;
HASH HA1;
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
MD5Final(HA1, &Md5Ctx);
if (stricmp(pszAlg, "md5-sess") == 0) {
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
MD5Final(HA1, &Md5Ctx);
if (stricmp(pszAlg, "md5-sess") == 0) {
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, HA1, HASHLEN);
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
MD5Final(HA1, &Md5Ctx);
};
CvtHex(HA1, SessionKey);
};
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, HA1, HASHLEN);
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
MD5Final(HA1, &Md5Ctx);
};
CvtHex(HA1, SessionKey);
};
/* calculate request-digest/response-digest as per HTTP Digest spec */
void DigestCalcResponse(
IN HASHHEX HA1, /* H(A1) */
IN char * pszNonce, /* nonce from server */
IN char * pszNonceCount, /* 8 hex digits */
IN char * pszCNonce, /* client nonce */
IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
IN char * pszMethod, /* method from the request */
IN char * pszDigestUri, /* requested URL */
IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
OUT HASHHEX Response /* request-digest or response-digest */
)
{
MD5_CTX Md5Ctx;
HASH HA2;
HASH RespHash;
HASHHEX HA2Hex;
/* calculate request-digest/response-digest as per HTTP Digest spec */
void DigestCalcResponse(
IN HASHHEX HA1, /* H(A1) */
IN char * pszNonce, /* nonce from server */
IN char * pszNonceCount, /* 8 hex digits */
IN char * pszCNonce, /* client nonce */
IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
IN char * pszMethod, /* method from the request */
IN char * pszDigestUri, /* requested URL */
IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
OUT HASHHEX Response /* request-digest or response-digest */
)
{
MD5_CTX Md5Ctx;
HASH HA2;
HASH RespHash;
HASHHEX HA2Hex;
// calculate H(A2)
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, pszMethod, strlen(pszMethod));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszDigestUri, strlen(pszDigestUri));
if (stricmp(pszQop, "auth-int") == 0) {
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, HEntity, HASHHEXLEN);
};
MD5Final(HA2, &Md5Ctx);
CvtHex(HA2, HA2Hex);
// calculate H(A2)
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, pszMethod, strlen(pszMethod));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszDigestUri, strlen(pszDigestUri));
if (stricmp(pszQop, "auth-int") == 0) {
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, HEntity, HASHHEXLEN);
};
MD5Final(HA2, &Md5Ctx);
CvtHex(HA2, HA2Hex);
// calculate response
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, HA1, HASHHEXLEN);
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
MD5Update(&Md5Ctx, ":", 1);
if (*pszQop) {
// calculate response
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, HA1, HASHHEXLEN);
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
MD5Update(&Md5Ctx, ":", 1);
if (*pszQop) {
MD5Update(&Md5Ctx, pszNonceCount, strlen(pszNonceCount));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszQop, strlen(pszQop));
MD5Update(&Md5Ctx, ":", 1);
};
MD5Update(&Md5Ctx, HA2Hex, HASHHEXLEN);
MD5Final(RespHash, &Md5Ctx);
CvtHex(RespHash, Response);
};
MD5Update(&Md5Ctx, pszNonceCount, strlen(pszNonceCount));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszQop, strlen(pszQop));
MD5Update(&Md5Ctx, ":", 1);
};
MD5Update(&Md5Ctx, HA2Hex, HASHHEXLEN);
MD5Final(RespHash, &Md5Ctx);
CvtHex(RespHash, Response);
};
File "digtest.c":
文件“digtest.c”：
#include <stdio.h>
#include "digcalc.h"
#include <stdio.h>
#include "digcalc.h"
void main(int argc, char ** argv) {
void main(int argc, char ** argv) {
char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093";
char * pszCNonce = "0a4f113b";
char * pszUser = "Mufasa";
char * pszRealm = "testrealm@host.com";
char * pszPass = "Circle Of Life";
char * pszAlg = "md5";
char szNonceCount[9] = "00000001";
char * pszMethod = "GET";
char * pszQop = "auth";
char * pszURI = "/dir/index.html";
HASHHEX HA1;
HASHHEX HA2 = "";
HASHHEX Response;
char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093";
char * pszCNonce = "0a4f113b";
char * pszUser = "Mufasa";
char * pszRealm = "testrealm@host.com";
char * pszPass = "Circle Of Life";
char * pszAlg = "md5";
char szNonceCount[9] = "00000001";
char * pszMethod = "GET";
char * pszQop = "auth";
char * pszURI = "/dir/index.html";
HASHHEX HA1;
HASHHEX HA2 = "";
HASHHEX Response;
DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,
pszCNonce, HA1);
DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop,
pszMethod, pszURI, HA2, Response);
printf("Response = %s\n", Response);
};
DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,
pszCNonce, HA1);
DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop,
pszMethod, pszURI, HA2, Response);
printf("Response = %s\n", Response);
};
6 Acknowledgments
6致谢
Eric W. Sink, of AbiSource, Inc., was one of the original authors before the specification underwent substantial revision.
AbiSource，Inc.的Eric W.Sink是规范进行实质性修订之前的原始作者之一。
In addition to the authors, valuable discussion instrumental in creating this document has come from Peter J. Churchyard, Ned Freed, and David M. Kristol.
除了作者之外，彼得·J·丘吉尔、内德·弗里德和大卫·M·克里斯托也对编写本文件进行了有价值的讨论。
Jim Gettys and Larry Masinter edited this document for update.
Jim Gettys和Larry Masinter编辑了此文档以进行更新。
7 References
7参考文献
[1] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[1] Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[2] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[2] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱西克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[3] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[4] Freed, N. and N. Borenstein. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[4] 弗里德，N.和N.博伦斯坦。“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[5] Dierks, T. and C. Allen "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[5] Dierks，T.和C.Allen，“TLS协议，版本1.0”，RFC 2246，1999年1月。
[6] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[6] Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P.，Lootonen，A.，Sink，E.和L.Stewart，“HTTP的扩展：摘要访问认证”，RFC 2069，1997年1月。
[7] Berners Lee, T, Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7] Berners Lee，T，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[8] Kaliski, B.,Robshaw, M., "Message Authentication with MD5",
CryptoBytes, Sping 1995, RSA Inc,
(http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
[8] Kaliski, B.,Robshaw, M., "Message Authentication with MD5",
CryptoBytes, Sping 1995, RSA Inc,
(http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
[9] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[9] Klensin，J.，Catoe，R.和P.Krumviede，“简单质询/响应的IMAP/POP授权扩展”，RFC 21951997年9月。
[10] Morgan, B., Alvestrand, H., Hodges, J., Wahl, M., "Authentication Methods for LDAP", Work in Progress.
[10] Morgan，B.，Alvestrand，H.，Hodges，J.，Wahl，M.，“LDAP的身份验证方法”，正在进行的工作。
8 Authors' Addresses
8作者地址
John Franks Professor of Mathematics Department of Mathematics Northwestern University Evanston, IL 60208-2730, USA
约翰·弗兰克斯美国伊利诺伊州埃文斯顿西北大学数学系数学教授，邮编60208-2730
EMail: john@math.nwu.edu
EMail: john@math.nwu.edu
Phillip M. Hallam-Baker Principal Consultant Verisign Inc. 301 Edgewater Place Suite 210 Wakefield MA 01880, USA
Phillip M.Hallam Baker首席顾问Verisign Inc.301 Edgewater Place套房210 Wakefield MA 01880，美国
EMail: pbaker@verisign.com
EMail: pbaker@verisign.com
Jeffery L. Hostetler Software Craftsman AbiSource, Inc. 6 Dunlap Court Savoy, IL 61874
Jeffery L.Hostettler软件工匠Abiseource，Inc.伊利诺伊州萨伏伊敦拉普法院6号，邮编61874
EMail: jeff@AbiSource.com
EMail: jeff@AbiSource.com
Scott D. Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
Scott D.Lawrence Agranat Systems，Inc.美国马萨诸塞州梅纳德市钟塔广场5号400室01754
EMail: lawrence@agranat.com
EMail: lawrence@agranat.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
Paul J.Leach微软公司美国华盛顿州微软路雷德蒙1号，邮编：98052
EMail: paulle@microsoft.com
EMail: paulle@microsoft.com
Ari Luotonen Member of Technical Staff Netscape Communications Corporation 501 East Middlefield Road Mountain View, CA 94043, USA
美国加利福尼亚州东米德菲尔德路山景城501号网景通信公司技术人员Ari Lootonen，邮编94043
Lawrence C. Stewart Open Market, Inc. 215 First Street Cambridge, MA 02142, USA
美国马萨诸塞州剑桥第一街215号劳伦斯·C·斯图尔特公开市场公司，邮编：02142
EMail: stewart@OpenMarket.com
EMail: stewart@OpenMarket.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。