Internet Engineering Task Force (IETF) Y. Oiwa
Request for Comments: 8120 H. Watanabe
Category: Experimental H. Takagi
ISSN: 2070-1721 ITRI, AIST
K. Maeda
Individual Contributor
T. Hayashi
Lepidum
Y. Ioku
Individual Contributor
April 2017
Internet Engineering Task Force (IETF) Y. Oiwa
Request for Comments: 8120 H. Watanabe
Category: Experimental H. Takagi
ISSN: 2070-1721 ITRI, AIST
K. Maeda
Individual Contributor
T. Hayashi
Lepidum
Y. Ioku
Individual Contributor
April 2017
Mutual Authentication Protocol for HTTP
HTTP的相互认证协议
Abstract
摘要
This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.
本文档指定了超文本传输协议（HTTP）的身份验证方案，称为相互身份验证方案或相互身份验证协议。此方案使用基于密码的身份验证在HTTP客户端和HTTP服务器之间提供真正的相互身份验证。与基本身份验证方案和摘要身份验证方案不同，本文档中指定的相互身份验证方案可向用户保证服务器确实知道用户的加密密码。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8120.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8120.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Document Structure and Related Documents ...................6
2. Protocol Overview ...............................................6
2.1. Messages ...................................................7
2.2. Typical Flows of the Protocol ..............................8
2.3. Alternative Flows .........................................10
3. Message Syntax .................................................12
3.1. Non-ASCII Extended Header Parameters ......................12
3.2. Values ....................................................13
3.2.1. Tokens .............................................13
3.2.2. Strings ............................................14
3.2.3. Numbers ............................................14
4. Messages .......................................................15
4.1. 401-INIT and 401-STALE ....................................16
4.2. req-KEX-C1 ................................................19
4.3. 401-KEX-S1 ................................................19
4.4. req-VFY-C .................................................20
4.5. 200-VFY-S .................................................21
5. Authentication Realms ..........................................21
5.1. Resolving Ambiguities .....................................23
6. Session Management .............................................24
7. Host Validation Methods ........................................26
7.1. Applicability Notes .......................................27
7.2. Notes on "tls-unique" .....................................28
8. Authentication Extensions ......................................28
9. String Preparation .............................................29
10. Decision Procedure for Clients ................................29
10.1. General Principles and Requirements ......................29
10.2. State Machine for the Client (Informative) ...............31
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.2. Document Structure and Related Documents ...................6
2. Protocol Overview ...............................................6
2.1. Messages ...................................................7
2.2. Typical Flows of the Protocol ..............................8
2.3. Alternative Flows .........................................10
3. Message Syntax .................................................12
3.1. Non-ASCII Extended Header Parameters ......................12
3.2. Values ....................................................13
3.2.1. Tokens .............................................13
3.2.2. Strings ............................................14
3.2.3. Numbers ............................................14
4. Messages .......................................................15
4.1. 401-INIT and 401-STALE ....................................16
4.2. req-KEX-C1 ................................................19
4.3. 401-KEX-S1 ................................................19
4.4. req-VFY-C .................................................20
4.5. 200-VFY-S .................................................21
5. Authentication Realms ..........................................21
5.1. Resolving Ambiguities .....................................23
6. Session Management .............................................24
7. Host Validation Methods ........................................26
7.1. Applicability Notes .......................................27
7.2. Notes on "tls-unique" .....................................28
8. Authentication Extensions ......................................28
9. String Preparation .............................................29
10. Decision Procedure for Clients ................................29
10.1. General Principles and Requirements ......................29
10.2. State Machine for the Client (Informative) ...............31
11. Decision Procedure for Servers ................................36
12. Authentication Algorithms .....................................39
12.1. Support Functions and Notations ..........................39
12.2. Default Functions for Algorithms .........................41
13. Application Channel Binding ...................................42
14. Application for Proxy Authentication ..........................42
15. Methods to Extend This Protocol ...............................43
16. IANA Considerations ...........................................44
16.1. Addition to HTTP Authentication Schemes Registry .........44
16.2. Registry for Authentication Algorithms ...................44
16.3. Registry for Validation Methods ..........................45
17. Security Considerations .......................................46
17.1. Security Properties ......................................46
17.2. Secrecy of Credentials ...................................46
17.3. Denial-of-Service Attacks on Servers .....................47
17.3.1. Online Active Password Attacks ....................47
17.4. Communicating the Status of Mutual Authentication
with Users ...............................................48
17.5. Implementation Considerations ............................48
17.6. Usage Considerations .....................................49
18. References ....................................................49
18.1. Normative References .....................................49
18.2. Informative References ...................................51
Authors' Addresses ................................................53
11. Decision Procedure for Servers ................................36
12. Authentication Algorithms .....................................39
12.1. Support Functions and Notations ..........................39
12.2. Default Functions for Algorithms .........................41
13. Application Channel Binding ...................................42
14. Application for Proxy Authentication ..........................42
15. Methods to Extend This Protocol ...............................43
16. IANA Considerations ...........................................44
16.1. Addition to HTTP Authentication Schemes Registry .........44
16.2. Registry for Authentication Algorithms ...................44
16.3. Registry for Validation Methods ..........................45
17. Security Considerations .......................................46
17.1. Security Properties ......................................46
17.2. Secrecy of Credentials ...................................46
17.3. Denial-of-Service Attacks on Servers .....................47
17.3.1. Online Active Password Attacks ....................47
17.4. Communicating the Status of Mutual Authentication
with Users ...............................................48
17.5. Implementation Considerations ............................48
17.6. Usage Considerations .....................................49
18. References ....................................................49
18.1. Normative References .....................................49
18.2. Informative References ...................................51
Authors' Addresses ................................................53
This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using just a simple password as a credential.
本文档指定了超文本传输协议（HTTP）的身份验证方案，称为相互身份验证方案或相互身份验证协议。此方案仅使用简单的密码作为凭据，在HTTP客户端和HTTP服务器之间提供真正的相互身份验证。
Password-stealing attacks are one of the most critical threats for Web systems. Plain-text password authentication techniques (Basic authentication and Web-form-based authentication) have been widely used for a long time. When these techniques are used with plain HTTP protocols, it is trivially easy for attackers to sniff the password credentials on the wire.
密码窃取攻击是Web系统最关键的威胁之一。纯文本密码认证技术（基本认证和基于Web表单的认证）已经被广泛使用了很长一段时间。当这些技术与普通HTTP协议一起使用时，攻击者很容易在线路上嗅探密码凭据。
The Digest authentication scheme [RFC7616] uses SHA-256 and SHA-512/256 (formerly SHA-1 and MD5) hash algorithms to hide the raw user password from network sniffers. However, if the number of possible candidate users' passwords is not enough, newer and more powerful computers can compute possible hash values for billions of password candidates and compare these with the sniffed values to find out the correct password. This kind of attack is called an offline password dictionary attack; the search capacity of these newer
摘要身份验证方案[RFC7616]使用SHA-256和SHA-512/256（以前的SHA-1和MD5）散列算法对网络嗅探器隐藏原始用户密码。然而，如果可能的候选用户密码的数量不够，更新和更强大的计算机可以为数十亿个候选密码计算可能的哈希值，并将其与嗅探值进行比较，以找出正确的密码。这种攻击称为离线密码字典攻击；这些较新版本的搜索能力
computers reduces the effectiveness of users' memorable passwords, thereby threatening the effectiveness of such hash-based password protections.
计算机降低了用户可记忆密码的有效性，从而威胁到这种基于散列的密码保护的有效性。
Transport Layer Security (TLS) [RFC5246] provides strong cryptographic protection against the network-based sniffing of passwords and other communication contents. If TLS is correctly used by both server operators and client users, passwords and other credentials will not be available to any outside attackers. However, there is a pitfall related to TLS deployment on Web systems: if the users are fraudulently routed to a "wrong Website" via some kind of social engineering attack (e.g., phishing) and tricked into performing authentication on that site, the credentials will be sent to the attacker's server and trivially leaked. Attacks such as phishing have become a serious threat. In current Web system deployments, TLS certificates will be issued to almost any users of the Internet (including malicious attackers). Although those certificates include several levels of the "validation results" (such as corporate names) of the issued entities, the task of "checking" those validation results is left to the users of Web browsers, still leaving open the possibility of such social engineering attacks.
传输层安全（TLS）[RFC5246]针对基于网络的密码嗅探和其他通信内容提供强大的密码保护。如果服务器操作员和客户端用户都正确使用TLS，则任何外部攻击者都无法使用密码和其他凭据。然而，在Web系统上部署TLS存在一个陷阱：如果用户通过某种社会工程攻击（如网络钓鱼）被欺诈地路由到“错误的网站”，并被欺骗在该网站上执行身份验证，则凭据将被发送到攻击者的服务器，并被轻微泄漏。网络钓鱼等攻击已成为严重威胁。在当前的Web系统部署中，TLS证书将颁发给几乎所有Internet用户（包括恶意攻击者）。尽管这些证书包含已颁发实体的几个级别的“验证结果”（如公司名称），但“检查”这些验证结果的任务留给Web浏览器的用户，仍然存在此类社会工程攻击的可能性。
Another way to avoid such threats is to avoid password-based authentication and use some kinds of pre-deployed strong secret keys (on either the client side or the server side) for authentications. Several federated authentication frameworks, as well as HTTP Origin-Bound Authentication (HOBA) [RFC7486], are proposed and deployed on real Web systems to satisfy those needs. However, a type of authentication based on "human-memorable secrets" (i.e., passwords) is still required in several scenarios, such as initialization, key deployment to new clients, or recovery of secret accounts with lost cryptographic keys.
避免此类威胁的另一种方法是避免基于密码的身份验证，并使用某种预先部署的强密钥（在客户端或服务器端）进行身份验证。为了满足这些需求，提出了几种联邦身份验证框架，以及HTTP源绑定身份验证（HOBA）[RFC7486]，并部署在实际的Web系统上。然而，在一些情况下，仍然需要基于“人类可记忆秘密”（即密码）的身份验证，例如初始化、密钥部署到新客户端或恢复丢失密码密钥的秘密帐户。
The Mutual authentication protocol, as proposed in this document, is a strong cryptographic solution for password authentications. It mainly provides the following two key features:
本文件中提出的相互认证协议是用于密码认证的强大密码解决方案。它主要提供以下两个关键功能：
o No password information at all is exchanged in the communications. When the server and the user fail to authenticate with each other, the protocol will not reveal even the tiniest bit of information about the user's password. This prevents any kind of offline password dictionary attacks, even with the existence of phishing attacks.
o 通信中根本不交换密码信息。当服务器和用户无法相互验证时，协议甚至不会透露有关用户密码的最微小信息。这可以防止任何类型的脱机密码字典攻击，即使存在网络钓鱼攻击。
o To successfully authenticate, the server, as well as client users, must own the valid registered credentials (authentication secret). This means that a phishing attacker cannot trick users into thinking that it is an "authentic" server. (It should be
o 要成功进行身份验证，服务器和客户端用户必须拥有有效的注册凭据（身份验证密钥）。这意味着网络钓鱼攻击者无法诱使用户认为它是“真实”服务器。（应该是
pointed out that this is not true for Basic and Digest authentication; for example, servers using Basic authentication can answer "YES" to any clients without actually checking authentication at all.) Client users can ascertain whether or not the communicating peer is truly "the server" that registered their account beforehand. In other words, it provides "true" mutual authentication between servers and clients.
指出基本认证和摘要认证并非如此；例如，使用基本身份验证的服务器可以对任何客户端回答“是”，而无需实际检查身份验证。）客户端用户可以确定通信的对等方是否确实是事先注册其帐户的“服务器”。换句话说，它在服务器和客户端之间提供“真正的”相互身份验证。
Given the information above, the proposed protocol can serve as a strong alternative to the Basic, Digest, and Web-form-based authentication schemes and also as a strong companion to the non-password-based authentication frameworks.
鉴于上述信息，建议的协议可以作为基本、摘要和基于Web表单的身份验证方案的有力替代方案，也可以作为非基于密码的身份验证框架的有力伙伴。
The proposed protocol will serve in the same way as does existing Basic or Digest authentication: it meets the requirements for new authentication schemes for HTTP, as described in Section 5.1.2 of [RFC7235]. Additionally, to communicate authentication results more reliably between the server and the client user, it suggests that Web browsers have some "secure" way of displaying the authentication results. Having such a user interface in future browsers will greatly reduce the risk of impersonation by various kinds of social engineering attacks, in a manner similar to that of the "green padlock" for Extended Validation TLS certificates.
提议的协议将以与现有基本或摘要认证相同的方式发挥作用：它满足[RFC7235]第5.1.2节所述的HTTP新认证方案的要求。此外，为了在服务器和客户端用户之间更可靠地传递身份验证结果，建议Web浏览器使用某种“安全”的方式显示身份验证结果。在未来的浏览器中使用这样的用户界面将大大降低各种社会工程攻击的模拟风险，其方式类似于扩展验证TLS证书的“绿色挂锁”。
Technically, the authentication scheme proposed in this document is a general framework for using password-based authenticated key exchange (PAKE) and similar stronger cryptographic primitives with HTTP. The two key features shown above correspond to the nature of PAKE.
从技术上讲，本文提出的身份验证方案是一个通用框架，用于使用基于密码的身份验证密钥交换（PAKE）和类似的更强的HTTP加密原语。上面显示的两个关键特性与PAKE的性质相对应。
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]中的说明进行解释。
This document distinguishes the terms "client" and "user" in the following way: a "client" is an entity that understands and implements HTTP and the specified authentication protocol -- usually computer software; a "user" is typically a human being who wants to access data resources using a "client".
本文档通过以下方式区分术语“客户机”和“用户”：“客户机”是理解并实现HTTP和指定的身份验证协议（通常是计算机软件）的实体；“用户”通常是希望使用“客户机”访问数据资源的人。
The term "natural numbers" refers to the non-negative integers (including zero) throughout this document.
术语“自然数”指本文件中的非负整数（包括零）。
This document treats both the input (domain) and the output (codomain) of hash functions as octet strings. When a natural number output for a hash function is required, it will be written as INT(H(s)).
本文档将哈希函数的输入（域）和输出（codomain）都视为八位字节字符串。当需要哈希函数的自然数输出时，它将被写入INT（H（s））。
The entire document is organized as follows:
整个文件的组织如下：
o Section 2 presents an overview of the protocol design.
o 第2节概述了协议设计。
o Sections 3 through 11 define a general framework of the Mutual authentication protocol. This framework is independent of specific cryptographic primitives.
o 第3节至第11节定义了相互认证协议的一般框架。该框架独立于特定的加密原语。
o Section 12 describes properties needed for cryptographic algorithms used with this protocol framework and defines a few functions that will be shared among such cryptographic algorithms.
o 第12节描述了与本协议框架一起使用的加密算法所需的属性，并定义了一些将在这些加密算法之间共享的功能。
o Sections 13 through 15 contain general normative and informative information about the protocol.
o 第13至15节载有关于议定书的一般性规范性和信息性信息。
o Sections 16 and 17 describe IANA considerations and security considerations, respectively.
o 第16节和第17节分别描述了IANA注意事项和安全注意事项。
In addition, we will refer to the following two companion documents, as they are related to this specification:
此外，我们将参考以下两份随附文件，因为它们与本规范相关：
o [RFC8121] defines cryptographic primitives that can be used with this protocol framework.
o [RFC8121]定义可用于此协议框架的加密原语。
o [RFC8053] defines small but useful extensions to the current HTTP authentication framework so that it can support application-level semantics of existing Web systems.
o [RFC8053]定义了对当前HTTP身份验证框架的小型但有用的扩展，以便支持现有Web系统的应用程序级语义。
The protocol, as a whole, is designed as a natural extension to HTTP [RFC7230] and uses the framework defined in [RFC7235]. Internally, the server and the client will first perform a cryptographic key exchange, using the secret password as a "tweak" to the exchange. The key exchange will only succeed when the secrets used by both peers are correctly related (i.e., generated from the same password). Then, both peers will verify the authentication results by confirming the sharing of the exchanged key. This section provides a brief outline of the protocol and the exchanged messages.
作为一个整体，该协议被设计为HTTP[RFC7230]的自然扩展，并使用[RFC7235]中定义的框架。在内部，服务器和客户端将首先执行加密密钥交换，使用秘密密码作为交换的“调整”。只有当两个对等方使用的秘密正确相关（即，由相同密码生成）时，密钥交换才会成功。然后，两个对等方将通过确认交换密钥的共享来验证认证结果。本节简要介绍协议和交换的消息。
The authentication protocol uses six kinds of messages to perform mutual authentication. These messages have specific names within this specification.
身份验证协议使用六种消息执行相互身份验证。这些消息在此规范中具有特定的名称。
o Authentication request messages: used by the servers to request that clients start mutual authentication.
o 身份验证请求消息：服务器用于请求客户端启动相互身份验证。
* 401-INIT message: a general message to start the authentication protocol. It is also used as a message indicating an authentication failure.
* 401-INIT消息：启动身份验证协议的一般消息。它还用作指示身份验证失败的消息。
* 401-STALE message: a message indicating that the client has to start a new key exchange.
* 401-STALE message：指示客户端必须启动新密钥交换的消息。
o Authenticated key exchange messages: used by both peers to perform authentication and the sharing of a cryptographic secret.
o 经过身份验证的密钥交换消息：由两个对等方用于执行身份验证和共享加密密钥。
* req-KEX-C1 message: a message sent from the client.
* req-KEX-C1消息：从客户端发送的消息。
* 401-KEX-S1 message: an intermediate response to a req-KEX-C1 message from the server.
* 401-KEX-S1消息：对来自服务器的req-KEX-C1消息的中间响应。
o Authentication verification messages: used by both peers to verify the authentication results.
o 身份验证消息：由两个对等方用于验证身份验证结果。
* req-VFY-C message: a message used by the client to request that the server authenticate and authorize the client.
* req-VFY-C消息：客户端用于请求服务器对客户端进行身份验证和授权的消息。
* 200-VFY-S message: a response used by the server to indicate that client authentication succeeded. It also contains information necessary for the client to check the authenticity of the server.
* 200-VFY-S消息：服务器用于指示客户端身份验证成功的响应。它还包含客户端检查服务器真实性所需的信息。
In addition to the above six kinds of messages, a request or response without any HTTP headers related to this specification will be hereafter called a "normal request" or "normal response", respectively.
除了上述六种消息之外，没有与本规范相关的任何HTTP头的请求或响应在下文中将分别称为“正常请求”或“正常响应”。
In typical cases, client access to a resource protected by the Mutual authentication scheme will use the following protocol sequence:
在典型情况下，客户端对受相互身份验证方案保护的资源的访问将使用以下协议序列：
Client Server
| |
| ---- (1) normal request ---------> |
GET / HTTP/1.1 |
| |
| <---------------- (2) 401-INIT --- |
| 401 Unauthorized |
| WWW-Authenticate: Mutual realm="a realm"
| |
[user, | |
pass]-->| |
| ---- (3) req-KEX-C1 -------------> |
GET / HTTP/1.1 |
Authorization: Mutual user="john", |--> [user DB]
kc1="...", ... |<-- [user info]
| |
| <-------------- (4) 401-KEX-S1 --- |
| 401 Unauthorized |
| WWW-Authenticate: Mutual sid=..., ks1="...", ...
| |
[compute] (5) compute session secret [compute]
| |
| |
| ---- (6) req-VFY-C --------------> |
GET / HTTP/1.1 |--> [verify (6)]
Authorization: Mutual sid=..., |<-- OK
vkc="...", ... |
| |
| <--------------- (7) 200-VFY-S --- |
[verify | 200 OK |
(7)]<--| Authentication-Info: Mutual vks="..."
| |
v v
Client Server
| |
| ---- (1) normal request ---------> |
GET / HTTP/1.1 |
| |
| <---------------- (2) 401-INIT --- |
| 401 Unauthorized |
| WWW-Authenticate: Mutual realm="a realm"
| |
[user, | |
pass]-->| |
| ---- (3) req-KEX-C1 -------------> |
GET / HTTP/1.1 |
Authorization: Mutual user="john", |--> [user DB]
kc1="...", ... |<-- [user info]
| |
| <-------------- (4) 401-KEX-S1 --- |
| 401 Unauthorized |
| WWW-Authenticate: Mutual sid=..., ks1="...", ...
| |
[compute] (5) compute session secret [compute]
| |
| |
| ---- (6) req-VFY-C --------------> |
GET / HTTP/1.1 |--> [verify (6)]
Authorization: Mutual sid=..., |<-- OK
vkc="...", ... |
| |
| <--------------- (7) 200-VFY-S --- |
[verify | 200 OK |
(7)]<--| Authentication-Info: Mutual vks="..."
| |
v v
Figure 1: Typical Communication Flow for First Access to Resource
图1：首次访问资源的典型通信流
o As is typical in general HTTP protocol designs, a client will at first request a resource without any authentication attempt (1). If the requested resource is protected by the Mutual authentication protocol, the server will respond with a message requesting authentication (401-INIT) (2).
o 与一般HTTP协议设计中的典型情况一样，客户端将首先请求资源，而不进行任何身份验证尝试（1）。如果请求的资源受相互身份验证协议保护，服务器将用请求身份验证的消息（401-INIT）（2）进行响应。
o The client processes the body of the message and waits for the user to input the username and password. If the username and password are available, the client will send a message with the authenticated key exchange (req-KEX-C1) to start the authentication (3).
o 客户端处理消息体并等待用户输入用户名和密码。如果用户名和密码可用，客户机将发送一条带有经过身份验证的密钥交换（req-KEX-C1）的消息，以启动身份验证（3）。
o If the server has received a req-KEX-C1 message, the server looks up the user's authentication information within its user database. Then, the server creates a new session identifier (sid) that will be used to identify sets of the messages that follow it and responds with a message containing a server-side authenticated key exchange value (401-KEX-S1) (4).
o 如果服务器已收到req-KEX-C1消息，则服务器将在其用户数据库中查找用户的身份验证信息。然后，服务器创建一个新的会话标识符（sid），该标识符将用于标识跟随它的消息集，并用包含服务器端经过身份验证的密钥交换值（401-KEX-S1）（4）的消息进行响应。
o At this point (5), both peers calculate a shared "session secret" using the exchanged values in the key exchange messages. Only when both the server and the client have used secret credentials generated from the same password will the session secret values match. This session secret will be used for access authentication of every individual request/response pair after this point.
o 此时（5），两个对等方使用密钥交换消息中的交换值计算共享的“会话秘密”。只有当服务器和客户端都使用了由相同密码生成的机密凭据时，会话机密值才会匹配。在此之后，此会话机密将用于每个单独请求/响应对的访问身份验证。
o The client will send a request with a client-side authentication verification value (req-VFY-C) (6), calculated from the client-generated session secret. The server will check the validity of the verification value using its own version of the session secret.
o 客户端将发送一个带有客户端身份验证值（req-VFY-C）（6）的请求，该值根据客户端生成的会话密钥计算得出。服务器将使用自己版本的会话密钥检查验证值的有效性。
o If the authentication verification value from the client was correct, then the client definitely owns the credential based on the expected password (i.e., the client authentication succeeded). The server will respond with a successful message (200-VFY-S) (7). Unlike the usual one-way authentication (e.g., HTTP Basic authentication or POP APOP authentication [RFC1939]), this message also contains a server-side authentication verification value.
o 如果来自客户机的身份验证值正确，则客户机肯定拥有基于预期密码的凭据（即，客户机身份验证成功）。服务器将响应一条成功消息（200-VFY-S）（7）。与通常的单向身份验证（例如HTTP基本身份验证或POP APOP身份验证[RFC1939]）不同，此消息还包含服务器端身份验证值。
When the client's verification value is incorrect (e.g., because the user-supplied password was incorrect), the server will respond with a 401-INIT message (the same message as the message used in (2)) instead.
当客户端的验证值不正确时（例如，由于用户提供的密码不正确），服务器将以401-INIT消息（与（2）中使用的消息相同）作为响应。
o The client MUST first check the validity of the server-side authentication verification value contained in the message (7). If the value was equal to the expected value, server authentication succeeded.
o 客户端必须首先检查消息（7）中包含的服务器端身份验证值的有效性。如果该值等于预期值，则服务器身份验证成功。
If it is not the expected value or the message does not contain the authentication verification value, then the mutual authentication has been broken for some unexpected reason. The client MUST NOT process any body or header values contained in the HTTP response in this case. (Note: This case should not happen between a correctly implemented server and client without any active attacks; such a scenario could be caused by either a man-in-the-middle attack or incorrect implementation.)
如果不是预期值或消息不包含身份验证值，则由于某些意外原因，相互身份验证已中断。在这种情况下，客户端不得处理HTTP响应中包含的任何正文或标头值。（注意：在没有任何主动攻击的情况下，这种情况不应发生在正确实现的服务器和客户端之间；这种情况可能是由中间人攻击或不正确的实现造成的。）
As shown above, the typical flow for a first authentication request requires three request-response pairs. To reduce protocol overhead, the protocol enables several shortcut flows that require fewer messages.
如上所示，第一个身份验证请求的典型流需要三个请求-响应对。为了减少协议开销，该协议启用了多个需要较少消息的快捷方式流。
o Case A: If the client knows that the resource is likely to require authentication, the client MAY omit the first unauthenticated request (1) and immediately send a key exchange (req-KEX-C1) message. This will reduce the number of round trips by one.
o 案例A：如果客户机知道资源可能需要身份验证，则客户机可能会忽略第一个未经身份验证的请求（1），并立即发送密钥交换（req-KEX-C1）消息。这将使往返次数减少一次。
o Case B: If both the client and the server previously shared a session secret associated with a valid sid, the client MAY directly send a req-VFY-C message using the existing sid and corresponding session secret. This will further reduce the number of round trips by one.
o 案例B：如果客户端和服务器之前共享了与有效sid关联的会话机密，则客户端可以使用现有sid和相应的会话机密直接发送req-VFY-C消息。这将使往返次数进一步减少一次。
The server MAY have thrown out the corresponding session from the session table. If so, the server will respond with a 401-STALE message, indicating that a new key exchange is required. The client SHOULD try again to construct a req-KEX-C1 message in this case.
服务器可能已从会话表中抛出了相应的会话。如果是这样，服务器将响应401-STALE消息，指示需要新的密钥交换。在这种情况下，客户端应再次尝试构造req-KEX-C1消息。
Figure 2 depicts the shortcut flows described above. When using appropriate settings and implementations, most of the requests to resources are expected to meet both criteria; thus, only one round trip of request/response will be required.
图2描述了上述快捷方式流。当使用适当的设置和实现时，对资源的大多数请求都应满足这两个标准；因此，只需要一次请求/响应往返。
Case A: Omit first request (2 round trips)
案例A：省略第一个请求（两次往返）
Client Server
| |
| --- req-KEX-C1 ----> |
| |
| <---- 401-KEX-S1 --- |
| |
| ---- req-VFY-C ----> |
| |
| <----- 200-VFY-S --- |
| |
Client Server
| |
| --- req-KEX-C1 ----> |
| |
| <---- 401-KEX-S1 --- |
| |
| ---- req-VFY-C ----> |
| |
| <----- 200-VFY-S --- |
| |
Case B: Reuse session secret (re-authentication)
案例B：重用会话机密（重新身份验证）
(B-1) key available (B-2) key expired (1 round trip) (3 round trips)
（B-1）钥匙可用（B-2）钥匙过期（1次往返）（3次往返）
Client Server Client Server
| | | |
| ---- req-VFY-C ----> | | --- req-VFY-C -------> |
| | | |
| <----- 200-VFY-S --- | | <------- 401-STALE --- |
| | | |
| --- req-KEX-C1 ------> |
| |
| <------ 401-KEX-S1 --- |
| |
| --- req-VFY-C -------> |
| |
| <------- 200-VFY-S --- |
| |
Client Server Client Server
| | | |
| ---- req-VFY-C ----> | | --- req-VFY-C -------> |
| | | |
| <----- 200-VFY-S --- | | <------- 401-STALE --- |
| | | |
| --- req-KEX-C1 ------> |
| |
| <------ 401-KEX-S1 --- |
| |
| --- req-VFY-C -------> |
| |
| <------- 200-VFY-S --- |
| |
Figure 2: Several Alternative Protocol Flows
图2：几种替代协议流
For more details, see Sections 10 and 11.
有关更多详细信息，请参见第10节和第11节。
Throughout this specification, the syntax is denoted in the extended augmented BNF syntax as defined in [RFC7230] and [RFC5234]. The following elements are used in this document per [RFC5234], [RFC7230], and [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, header-field, token, challenge, and credentials.
在本规范中，该语法以[RFC7230]和[RFC5234]中定义的扩展扩充BNF语法表示。根据[RFC5234]、[RFC7230]和[RFC7235]，本文档中使用了以下元素：数字、字母、SP、身份验证方案、带引号的字符串、身份验证参数、标题字段、令牌、质询和凭据。
The Mutual authentication protocol uses three headers: WWW-Authenticate (usually in responses with a 401 status code), Authorization (in requests), and Authentication-Info (in responses other than a 401 status code). These headers follow the frameworks described in [RFC7235] and [RFC7615]. See Section 4 for more details regarding these headers.
相互身份验证协议使用三个头：WWW-Authenticate（通常在401状态码的响应中）、authentication（在请求中）和authentication Info（在401状态码以外的响应中）。这些头文件遵循[RFC7235]和[RFC7615]中描述的框架。有关这些标题的更多详细信息，请参见第4节。
The framework in [RFC7235] defines the syntax for the headers WWW-Authenticate and Authorization as the syntax elements "challenge" and "credentials", respectively. The auth-scheme element contained in those headers MUST be set to "Mutual" when using the protocol specified in this document. The syntax for "challenge" and "credentials" to be used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth-param), not the "token68" parameter defined in [RFC7235].
[RFC7235]中的框架将头WWW Authenticate和Authorization的语法分别定义为语法元素“challenge”和“credentials”。当使用本文档中指定的协议时，这些标头中包含的auth scheme元素必须设置为“Mutual”。与“相互”身份验证方案一起使用的“质询”和“凭证”的语法应为名称-值对（#auth-param），而不是[RFC7235]中定义的“token68”参数。
The Authentication-Info header used in this protocol SHALL follow the syntax defined in [RFC7615].
本协议中使用的身份验证信息头应遵循[RFC7615]中定义的语法。
In HTTP, the WWW-Authenticate header may contain two or more challenges. Client implementations SHOULD be aware of, and be capable of correctly handling, those cases.
在HTTP中，WWW身份验证标头可能包含两个或多个质询。客户机实现应该了解并能够正确处理这些情况。
All of the parameters contained in the above three headers, except for the "realm" field, MAY be extended to ISO 10646-1 values using the framework described in [RFC5987]. All servers and clients MUST be capable of receiving and sending values encoded per the syntax specified in [RFC5987].
除“领域”字段外，上述三个标题中包含的所有参数都可以使用[RFC5987]中描述的框架扩展为ISO 10646-1值。所有服务器和客户端必须能够接收和发送按照[RFC5987]中指定语法编码的值。
If a value to be sent contains only ASCII characters, the field MUST be sent using plain syntax as defined in RFC 7235. The syntax as extended by RFC 5987 MUST NOT be used in this case.
如果要发送的值仅包含ASCII字符，则必须使用RFC 7235中定义的普通语法发送字段。在这种情况下，不得使用RFC 5987扩展的语法。
If a value (except for the "realm" header) contains one or more non-ASCII characters, the parameter SHOULD be sent using the syntax defined in Section 3.2 of [RFC5987] as "ext-parameter". Such a parameter MUST have a charset value of "UTF-8", and the language
如果值（除“realm”标题外）包含一个或多个非ASCII字符，则应使用[RFC5987]第3.2节中定义为“ext parameter”的语法发送参数。此类参数必须具有字符集值“UTF-8”，且语言
value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the syntax used.
值必须始终忽略（具有空值）。无论使用何种语法，同一参数不能发送多次。
For example, a parameter "user" with the value "Renee of France" SHOULD be sent as < user="Renee of France" >. If the value is "Ren<e acute>e of France", it SHOULD be sent as < user*=UTF-8''Ren%C3%89e%20of%20France > instead.
例如，值为“法国蕾妮”的参数“user”应作为<user=“法国蕾妮”>发送。如果值为“Ren<e acute>e of France”，则应改为以<user*=UTF-8“Ren%C3%89e%20of%20France>的形式发送。
[RFC7235] requires that the "realm" parameter be in its plain form (not as an extended "realm*" parameter), so the syntax specified in RFC 5987 MUST NOT be used for this parameter.
[RFC7235]要求“realm”参数采用普通形式（不是扩展的“realm*”参数），因此RFC 5987中指定的语法不能用于此参数。
The parameter values contained in challenges or credentials MUST be parsed in strict conformance with HTTP semantics (especially the unquoting of string parameter values). In this protocol, those values are further categorized into the following value types: tokens (bare-token and extensive-token), string, integer, hex-fixed-number, and base64-fixed-number.
质询或凭据中包含的参数值必须严格按照HTTP语义进行解析（尤其是字符串参数值的取消引用）。在该协议中，这些值进一步分类为以下值类型：令牌（裸令牌和扩展令牌）、字符串、整数、十六进制固定数和base64固定数。
For clarity, it is RECOMMENDED that implementations use the canonical representations specified in the following subsections for sending values. However, recipients MUST accept both quoted and unquoted representations interchangeably, as specified in HTTP.
为清楚起见，建议实现使用以下小节中指定的规范表示来发送值。但是，收件人必须按照HTTP中的规定，交替接受带引号和不带引号的表示。
For sustaining both security and extensibility at the same time, this protocol defines a stricter sub-syntax for the "token" to be used. Extensive-token values SHOULD use the following syntax (after the parsing of HTTP values):
为了同时保持安全性和可扩展性，该协议为要使用的“令牌”定义了更严格的子语法。扩展令牌值应使用以下语法（在解析HTTP值之后）：
bare-token = bare-token-lead-char *bare-token-char
bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token
bare-token = bare-token-lead-char *bare-token-char
bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token
Figure 3: BNF Syntax for Token Values
图3：令牌值的BNF语法
The tokens (bare-token and extension-token) are case insensitive. Senders SHOULD send these in lower case, and receivers MUST accept both upper and lower cases. When tokens are used as (partial) inputs to any hash functions or other mathematical functions, they MUST always be used in lower case.
令牌（裸令牌和扩展令牌）不区分大小写。发送方应以小写形式发送，接收方必须同时接受大写和小写。当令牌用作任何哈希函数或其他数学函数的（部分）输入时，它们必须始终以小写形式使用。
Extensive-tokens are used in this protocol where the set of acceptable tokens may include non-standard extensions. Any extension of this protocol MAY use either the bare-tokens allocated by IANA (see the procedure described in Section 16) or extension-tokens with the format "-<bare-token>.<domain-name>", where <domain-name> is a valid (sub)domain name on the Internet owned by the party who defines the extension.
此协议中使用扩展令牌，其中可接受的令牌集可能包括非标准扩展。本协议的任何扩展都可以使用IANA分配的裸令牌（参见第16节中描述的过程）或格式为“<裸令牌><domain name>”的扩展令牌，其中<domain name>是定义扩展的一方在互联网上拥有的有效（子）域名。
Bare-tokens and extensive-tokens are also used for parameter names, in the unquoted form. Requirements for using the extension-token for the parameter names are the same as those described in the previous paragraph.
裸令牌和扩展令牌也用于参数名称，形式为无引号。对参数名称使用扩展标记的要求与上一段中描述的要求相同。
The canonical format for bare-tokens and extensive-tokens is the unquoted representation.
裸令牌和扩展令牌的标准格式是无引号表示。
All character strings MUST be encoded to octet strings using UTF-8 encoding [RFC3629] for the Unicode character set [Unicode]. Such strings MUST NOT contain any leading Byte Order Marks (BOMs) (also known as ZERO WIDTH NO-BREAK SPACE, U+FEFF, or EF BB BF). It is RECOMMENDED that both peers reject any invalid UTF-8 sequences that might cause decoding ambiguities (e.g., containing <"> in the second or subsequent bytes of the UTF-8 encoded characters).
必须使用Unicode字符集[Unicode]的UTF-8编码[RFC3629]将所有字符串编码为八位字符串。此类字符串不得包含任何前导字节顺序标记（BOM）（也称为零宽度无中断空间、U+FEFF或EF BB BF）。建议两个对等方拒绝任何可能导致解码歧义的无效UTF-8序列（例如，在UTF-8编码字符的第二个或后续字节中包含<>）。
If strings represent a domain name or URI that contains non-ASCII characters, the host parts SHOULD be encoded as they (the parts) are used in the HTTP protocol layer (e.g., in a Host: header); per current standards, the A-label as defined in [RFC5890] will be used. Lowercase ASCII characters SHOULD be used.
如果字符串表示包含非ASCII字符的域名或URI，则应在HTTP协议层（例如，在主机：头中）使用主机部分时对其进行编码；根据现行标准，将使用[RFC5890]中定义的A标签。应使用小写ASCII字符。
The canonical format for strings is quoted-string (as it may contain equals signs ("="), plus signs ("+"), and slashes ("/")), unless the parameter containing the string value will use extended syntax as defined in [RFC5987]. (Per [RFC5987], an extended parameter will have an unquoted encoded value.)
字符串的标准格式为带引号的字符串（因为它可能包含等号（=”），加号（+”）和斜杠（/”），除非包含字符串值的参数将使用[RFC5987]中定义的扩展语法。（根据[RFC5987]，扩展参数将有一个无引号的编码值。）
The following syntax definitions provide a syntax for numeric values:
以下语法定义提供了数值的语法：
integer = "0" / (%x31-39 *DIGIT) ; no leading zeros
hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66))
base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"="
integer = "0" / (%x31-39 *DIGIT) ; no leading zeros
hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66))
base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"="
Figure 4: BNF Syntax for Numbers
图4：数字的BNF语法
The syntax definition of the integers only allows representations that do not contain leading zeros.
整数的语法定义只允许不包含前导零的表示。
A number represented as a hex-fixed-number MUST include an even number of hexadecimal digits (i.e., multiples of eight bits). Those values are case insensitive and SHOULD be sent in lower case. When these values are generated from any cryptographic values, they MUST have their "natural length"; if they are generated from a hash function, their lengths correspond to the hash size; if they represent elements of a mathematical set (or group), their lengths SHALL be the shortest lengths that represent all the elements in the set. For example, the results of the SHA-256 hash function will be represented by 64 digits, and any elements in a 2048-bit prime field (modulo a 2048-bit integer) will be represented by 512 digits, regardless of how many zeros appear in front of such representations. Session identifiers and other non-cryptographically generated values are represented in any (even) length determined by the side that generates it first, and the same length MUST be used in all communications by both peers.
表示为十六进制固定数的数字必须包含偶数个十六进制数字（即八位的倍数）。这些值不区分大小写，应以小写形式发送。当这些值由任何加密值生成时，它们必须具有其“自然长度”；如果它们是从散列函数生成的，则它们的长度对应于散列大小；如果它们代表数学集合（或组）的元素，则其长度应为代表集合中所有元素的最短长度。例如，SHA-256哈希函数的结果将由64位数字表示，2048位素数字段（模2048位整数）中的任何元素将由512位数字表示，而不管这些表示前面出现多少个零。会话标识符和其他非加密生成的值以首先生成它的一方确定的任何（偶数）长度表示，并且两个对等方在所有通信中必须使用相同的长度。
The numbers represented as base64-fixed-number SHALL be generated as follows: first, the number is converted to a big-endian radix-256 binary representation as an octet string. The length of the representation is determined in the same way as the technique mentioned above. Then, the string is encoded using base64 encoding (described in Section 4 of [RFC4648]) without any spaces and newlines. Implementations decoding base64-fixed-number SHOULD reject any input data with invalid characters, excess or insufficient padding, or non-canonical pad bits (see Sections 3.1 through 3.5 of [RFC4648]).
以base64 fixed number表示的数字应按如下方式生成：首先，数字转换为作为八位字节字符串的大端基数-256二进制表示。表示的长度以与上述技术相同的方式确定。然后，使用base64编码（如[RFC4648]第4节所述）对字符串进行编码，不带任何空格和换行符。解码base64固定数字的实现应拒绝包含无效字符、多余或不足填充或非规范填充位的任何输入数据（请参阅[RFC4648]第3.1节至第3.5节）。
The canonical format for integer and hex-fixed-number is unquoted tokens, and the canonical format for base64-fixed-number is quoted-string.
整数和十六进制固定数字的标准格式是不带引号的标记，base64固定数字的标准格式是带引号的字符串。
In this section, we define the six kinds of messages in the authentication protocol, along with the formats and requirements of the headers for each type of message.
在本节中，我们定义了身份验证协议中的六种消息，以及每种消息的头的格式和要求。
To determine under what circumstances each message is expected to be sent, see Sections 10 and 11.
要确定在何种情况下发送每条信息，请参见第10节和第11节。
In the descriptions below, the types of allowable values for each header parameter are shown in parentheses after each parameter name. The "algorithm-determined" type means that the acceptable value for the parameter is one of the types defined in Section 3 and is
在下面的描述中，每个标题参数的允许值类型显示在每个参数名称后的括号中。“算法确定”类型意味着参数的可接受值是第3节中定义的类型之一，并且是
determined by the value of the "algorithm" parameter. The parameters marked "mandatory" SHALL be contained in the message. The parameters marked "non-mandatory" MAY be either contained in the message or omitted from it. Each parameter SHALL appear in each header exactly once at most.
由“算法”参数的值确定。标记为“强制性”的参数应包含在信息中。标记为“非强制性”的参数可以包含在消息中，也可以从消息中省略。每个参数最多只能在每个标题中出现一次。
All credentials and challenges MAY contain any parameters not explicitly specified in the following sections. Recipients that do not understand such parameters MUST silently ignore them. However, all credentials and challenges MUST meet the following criteria:
所有凭证和质询可能包含以下各节中未明确指定的任何参数。不理解这些参数的收件人必须默默地忽略它们。但是，所有证书和挑战必须符合以下标准：
o For responses, the parameters "reason", any "ks#" (where "#" stands for any decimal integer), and "vks" are mutually exclusive; any challenges MUST NOT contain two or more parameters among them. They MUST NOT contain any "kc#" or "vkc" parameters.
o 对于响应，参数“reason”、任意“ks#”（其中“#”表示任意十进制整数）和“vks”是互斥的；任何挑战都不得包含其中的两个或多个参数。它们不得包含任何“kc#”或“vkc”参数。
o For requests, the parameters "kc#" (where "#" stands for any decimal integer) and "vkc" are mutually exclusive; any challenges MUST NOT contain two or more parameters among them. They MUST NOT contain any "ks#" or "vks" parameters.
o 对于请求，参数“kc#”（其中“#”表示任何十进制整数）和“vkc”是互斥的；任何挑战都不得包含其中的两个或多个参数。它们不得包含任何“ks#”或“vks”参数。
Every message defined in this section contains a "version" field to detect any future revisions of the protocol that are incompatible. Implementations of the protocol described in this specification MUST always send a token "1" to represent the version number. Recipients MUST reject messages that contain any other value for the version, unless another specification defines specific behavior for that version.
本节中定义的每条消息都包含一个“版本”字段，用于检测协议将来的任何不兼容版本。本规范中描述的协议的实现必须始终发送令牌“1”以表示版本号。收件人必须拒绝包含该版本的任何其他值的邮件，除非其他规范定义了该版本的特定行为。
Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401 (Unauthorized) status message (or some other 4xx status message, if appropriate) containing one and only one (hereafter not explicitly noted) WWW-Authenticate header containing a "reason" parameter in the challenge. The challenge SHALL contain all of the parameters marked "mandatory" below and MAY contain those marked "non-mandatory".
每个401-INIT或401-STALE消息应为有效的HTTP 401（未经授权）状态消息（或其他4xx状态消息，如适用），其中包含且仅包含一个（下文未明确说明）WWW Authenticate标头，其中包含质询中的“原因”参数。质询应包含以下标记为“强制性”的所有参数，也可包含标记为“非强制性”的参数。
version: (mandatory extensive-token) should be the token "1".
版本：（强制扩展令牌）应为令牌“1”。
algorithm: (mandatory extensive-token) specifies the authentication algorithm to be used. The value MUST be one of the tokens specified in [RFC8121] or another supplemental specification.
算法：（强制扩展令牌）指定要使用的身份验证算法。该值必须是[RFC8121]或其他补充规范中指定的令牌之一。
validation: (mandatory extensive-token) specifies the method of host validation. The value MUST be one of the tokens described in Section 7 or the tokens specified in another supplemental specification.
验证：（强制扩展令牌）指定主机验证的方法。该值必须是第7节中描述的令牌之一，或者是另一补充规范中指定的令牌。
auth-scope: (non-mandatory string) specifies the authentication scope, i.e., the set of hosts for which the authentication credentials are valid. It MUST be one of the strings described in Section 5. If the value is omitted, it is assumed to be the "single-server type" domain as described in Section 5.
auth scope：（非强制字符串）指定身份验证范围，即身份验证凭据有效的主机集。它必须是第5节中描述的字符串之一。如果省略该值，则假定为第5节所述的“单服务器类型”域。
realm: (mandatory string) is a string representing the name of the authentication realm inside the authentication scope. As specified in [RFC7235], this value MUST always be sent in the quoted-string form, and an encoding as specified in [RFC5987] MUST NOT be used.
realm：（必填字符串）是表示身份验证范围内身份验证领域名称的字符串。按照[RFC7235]中的规定，必须始终以带引号的字符串形式发送此值，并且不得使用[RFC5987]中规定的编码。
The realm value sent from the server SHOULD be an ASCII string. Clients MAY treat any non-ASCII value received in this field as a binary blob, an NFC-normalized UTF-8 string ("NFC" stands for "Normalization Form C"), or an error.
从服务器发送的领域值应为ASCII字符串。客户端可以将此字段中接收的任何非ASCII值视为二进制blob、NFC标准化UTF-8字符串（“NFC”表示“标准化形式C”）或错误。
reason: (mandatory extensive-token) SHALL be an extensive-token that describes the possible reason for the failed authentication or authorization. Both servers and clients SHALL understand and support the following three tokens:
原因：（强制扩展令牌）应为描述认证或授权失败的可能原因的扩展令牌。服务器和客户端都应理解并支持以下三种令牌：
* initial: Authentication was not attempted because there was no Authorization header in the corresponding request.
* 初始：未尝试身份验证，因为相应请求中没有授权标头。
* stale-session: The provided sid in the request was either unknown to the server or expired in the server.
* 陈旧会话：请求中提供的sid对服务器未知或已在服务器中过期。
* auth-failed: The authentication trial failed for some reason, possibly because of a bad authentication credential.
* 身份验证失败：身份验证试验因某种原因失败，可能是因为身份验证凭据错误。
Implementations MAY support the following tokens or any extensive-tokens defined outside of this specification. If clients receive any unknown tokens, they SHOULD treat them as if they were "auth-failed" or "initial".
实现可能支持以下令牌或本规范之外定义的任何扩展令牌。如果客户机收到任何未知令牌，他们应该将其视为“身份验证失败”或“初始”。
* reauth-needed: The server-side application requires a new authentication trial, regardless of the current status.
* 需要重新验证：无论当前状态如何，服务器端应用程序都需要新的身份验证试用。
* invalid-parameters: The server did not attempt authentication because some parameters were not acceptable.
* 无效参数：服务器未尝试身份验证，因为某些参数不可接受。
* internal-error: The server did not attempt authentication because there are some problems on the server side.
* 内部错误：服务器未尝试身份验证，因为服务器端存在一些问题。
* user-unknown: This is a special case of auth-failed; it suggests that the provided username is invalid. Due to security implications, the use of this parameter is NOT RECOMMENDED, except for special-purpose applications where it would make sense to do so.
* 用户未知：这是身份验证失败的特殊情况；这表明提供的用户名无效。由于安全问题，不建议使用此参数，除非在特殊用途的应用中这样做是有意义的。
* invalid-credential: This is another special case of auth-failed; it suggests that the provided username was valid but authentication still failed. For security reasons, the use of this parameter is NOT RECOMMENDED.
* 无效凭证：这是身份验证失败的另一种特殊情况；这表明提供的用户名有效，但身份验证仍然失败。出于安全原因，不建议使用此参数。
* authz-failed: Authentication was successful, but access to the specified resource is not authorized to the specific authenticated user. (It might be used along with either a 401 (Unauthorized) or 403 (Forbidden) status code to indicate that the authentication result is one of the existing reasons for the failed authorization.)
* authz失败：身份验证成功，但未授权特定身份验证用户访问指定资源。（它可能与401（未授权）或403（禁止）状态代码一起使用，以指示身份验证结果是授权失败的现有原因之一。）
It is RECOMMENDED that the reason for failure be recorded to some type of diagnostic log, shown to the client user immediately, or both. It will be helpful to find out later whether the reason for the failure is technical or caused by user error.
建议将故障原因记录到某种类型的诊断日志中，立即显示给客户端用户，或同时显示两者。这将有助于以后查明故障原因是技术原因还是用户错误。
The algorithm specified in this header will determine the types (among those defined in Section 3) and the values for K_c1, K_s1, VK_c, and VK_s.
此标题中指定的算法将确定类型（第3节中定义的类型）以及K_c1、K_s1、VK_c和VK_s的值。
Among these messages, any messages with the "reason" parameter value "stale-session" will be called "401-STALE" messages hereafter, because these messages have a special meaning in the protocol flow. Messages with any other "reason" parameters will be called "401-INIT" messages.
在这些消息中，具有“reason”参数值“stale session”的任何消息在下文中将被称为“401-stale”消息，因为这些消息在协议流中具有特殊含义。带有任何其他“原因”参数的消息将称为“401-INIT”消息。
Every req-KEX-C1 message SHALL be a valid HTTP request message containing an Authorization header with a credential containing a "kc1" parameter.
每个req-KEX-C1消息应为有效的HTTP请求消息，其中包含授权标头，凭证包含“kc1”参数。
The credential SHALL contain the parameters with the following names:
凭证应包含具有以下名称的参数：
version: (mandatory, extensive-token) should be the token "1".
版本：（强制，扩展令牌）应为令牌“1”。
algorithm, validation, auth-scope, realm: MUST be the same values as those received from the server.
算法、验证、身份验证范围、领域：必须与从服务器接收的值相同。
user: (mandatory, string) is the UTF-8 encoded name of the user. The string SHOULD be prepared according to the method presented in Section 9.
user：（必填，字符串）是用户的UTF-8编码名称。应按照第9节中介绍的方法制备管柱。
kc1: (mandatory, algorithm-determined) is the client-side key exchange value K_c1, which is specified by the algorithm that is used.
kc1：（强制，算法确定）是客户端密钥交换值K_c1，由所使用的算法指定。
Every 401-KEX-S1 message SHALL be a valid HTTP 401 (Unauthorized) status response message containing a WWW-Authenticate header with a challenge containing a "ks1" parameter.
每个401-KEX-S1消息都应是有效的HTTP 401（未经授权）状态响应消息，其中包含WWW认证头，质询包含“ks1”参数。
The challenge SHALL contain the parameters with the following names:
质询应包含具有以下名称的参数：
version: (mandatory, extensive-token) should be the token "1".
版本：（强制，扩展令牌）应为令牌“1”。
algorithm, validation, auth-scope, realm: MUST be the same values as those received from the client.
算法、验证、身份验证范围、领域：必须与从客户端接收的值相同。
sid: (mandatory, hex-fixed-number) MUST be a session identifier, which is a random integer. The sid SHOULD have uniqueness of at least 80 bits or the square of the maximum estimated transactions concurrently available in the session table, whichever is larger. See Section 6 for more details.
sid：（必需，十六进制固定数）必须是会话标识符，它是一个随机整数。sid的唯一性应至少为80位或会话表中并发可用的最大估计事务数的平方，以较大者为准。详见第6节。
ks1: (mandatory, algorithm-determined) is the server-side key exchange value K_s1, which is specified by the algorithm.
ks1：（强制，算法确定）是服务器端密钥交换值K_s1，由算法指定。
nc-max: (mandatory, integer) is the maximum value of nonce numbers that the server accepts.
nc max：（必需，整数）是服务器接受的nonce编号的最大值。
nc-window: (mandatory, integer) is the number of available nonce number slots that the server will accept. It is RECOMMENDED that the value of the "nc-window" parameter be 128 or more.
nc window：（必需，整数）是服务器将接受的可用nonce number插槽数。建议“nc窗口”参数的值为128或更大。
time: (mandatory, integer) represents the suggested time (in seconds) that the client can reuse the session represented by the sid. It is RECOMMENDED that the time be set to at least 60 (seconds). However, the server is not required to guarantee that the session represented by the sid will be available (e.g., alive, usable) for the time specified in this parameter.
time：（必填，整数）表示客户端可以重用sid表示的会话的建议时间（秒）。建议将时间设置为至少60（秒）。但是，服务器不需要保证sid表示的会话在此参数中指定的时间内可用（例如，活动、可用）。
path: (non-mandatory, string) specifies to which path in the URI space the same authentication is expected to be applied. The value is a space-separated list of URIs, in the same format as that specified in the "domain" parameter [RFC7616] for Digest authentications. All path elements contained in the "path" parameter MUST be inside the specified auth-scope; if not, clients SHOULD ignore such elements. For better performance, it is important that clients recognize and use this parameter.
path：（非强制性，字符串）指定URI空间中预期应用相同身份验证的路径。该值是以空格分隔的URI列表，格式与摘要身份验证的“域”参数[RFC7616]中指定的格式相同。“path”参数中包含的所有path元素必须在指定的auth范围内；如果不是，客户端应该忽略这些元素。为了获得更好的性能，客户机必须识别并使用此参数。
Every req-VFY-C message SHALL be a valid HTTP request message containing an Authorization header with a credential containing a "vkc" parameter.
每个req-VFY-C消息应为有效的HTTP请求消息，其中包含授权标头，凭证包含“vkc”参数。
The parameters contained in the header are as follows:
标题中包含的参数如下所示：
version: (mandatory, extensive-token) should be the token "1".
版本：（强制，扩展令牌）应为令牌“1”。
algorithm, validation, auth-scope, realm: MUST be the same values as those received from the server for the session.
算法、验证、身份验证范围、领域：必须与从服务器接收的会话值相同。
sid: (mandatory, hex-fixed-number) MUST be one of the sid values that was received from the server for the same authentication realm.
sid：（必需，十六进制固定数字）必须是从同一身份验证领域的服务器接收的sid值之一。
nc: (mandatory, integer) is a nonce request number that is unique among the requests sharing the same sid. The values of the nonce numbers SHOULD satisfy the properties outlined in Section 6.
nc：（必需，整数）是一个nonce请求号，在共享相同sid的请求中是唯一的。nonce数的值应满足第6节中概述的属性。
vkc: (mandatory, algorithm-determined) is the client-side authentication verification value VK_c, which is specified by the algorithm.
vkc：（强制，算法确定）是客户端身份验证值VK_c，由算法指定。
Every 200-VFY-S message SHALL be a valid HTTP message that does not have a 401 (Unauthorized) status code and SHALL contain an Authentication-Info header with a "vks" parameter.
每个200-VFY-S消息应为有效的HTTP消息，没有401（未经授权）状态代码，并应包含带有“vks”参数的身份验证信息头。
The parameters contained in the header are as follows:
标题中包含的参数如下所示：
version: (mandatory, extensive-token) should be the token "1".
版本：（强制，扩展令牌）应为令牌“1”。
sid: (mandatory, hex-fixed-number) MUST be the value received from the client.
sid：（必需，十六进制固定数字）必须是从客户端接收的值。
vks: (mandatory, algorithm-determined) is the server-side authentication verification value VK_s, which is specified by the algorithm.
vks：（强制，算法确定）是服务器端身份验证值VK_s，由算法指定。
The header MUST be sent before the content body; it MUST NOT be sent in the trailer of a chunked-encoded response. If a "100 (Continue)" [RFC7231] response is sent from the server, the Authentication-Info header SHOULD be included in that response instead of the final response.
标题必须在内容正文之前发送；它不能在分块编码响应的尾部发送。如果服务器发送了“100（继续）”[RFC7231]响应，则该响应中应包含身份验证信息头，而不是最终响应。
In this protocol, an authentication realm is defined as a set of resources (URIs) for which the same set of usernames and passwords is valid. If the server requests authentication for an authentication realm for which the client is already authenticated, the client will automatically perform the authentication using the already-known credentials. However, for different authentication realms, clients MUST NOT automatically reuse usernames and passwords for another realm.
在该协议中，身份验证领域定义为一组资源（URI），同一组用户名和密码对其有效。如果服务器请求对客户端已进行身份验证的身份验证域进行身份验证，则客户端将使用已知凭据自动执行身份验证。但是，对于不同的身份验证领域，客户端不能自动重用另一个领域的用户名和密码。
As is the case for the Basic and Digest access authentication protocols, the Mutual authentication protocol supports multiple, separate protection spaces to be set up inside each host. Furthermore, the protocol allows a single authentication realm to span several hosts within the same Internet domain.
与基本和摘要访问身份验证协议一样，相互身份验证协议支持在每个主机内设置多个单独的保护空间。此外，该协议允许单个身份验证域跨同一Internet域中的多个主机。
Each authentication realm is defined and distinguished by the triple of an authentication algorithm, an authentication scope, and a "realm" parameter. However, it is NOT RECOMMENDED that server operators use the same pair of an authentication scope and a realm with different authentication algorithms.
每个身份验证领域都通过身份验证算法、身份验证范围和“领域”参数的三元组来定义和区分。但是，不建议服务器运营商使用具有不同身份验证算法的同一对身份验证作用域和域。
The "realm" parameter is a string as defined in Section 4. Authentication scopes are described in the remainder of this section.
“realm”参数是第4节中定义的字符串。本节其余部分将介绍身份验证范围。
An authentication scope specifies the range of hosts spanned by the authentication realm. In this protocol, it MUST be one of the following kinds of strings:
身份验证范围指定身份验证领域跨越的主机范围。在此协议中，它必须是以下类型的字符串之一：
o Single-server type: A string in the format "<scheme>://<host>" or "<scheme>://<host>:<port>", where <scheme>, <host>, and <port> are the corresponding URI parts of the request URI. If the default port (i.e., 80 for HTTP and 443 for HTTPS) is used for the underlying HTTP communications, the port part MUST be omitted, regardless of whether it was present in the request URI. In all other cases, the port part MUST be present, and it MUST NOT contain leading zeros. Use this format when authentication is only valid for a specific protocol (such as HTTPS). This format is equivalent to the ASCII serialization of a Web origin, as presented in Section 6.2 of [RFC6454].
o 单一服务器类型：格式为“<scheme>：//<host>”或“<scheme>：//<host>：<port>”的字符串，其中<scheme>、<host>和<port>是请求URI的相应URI部分。如果底层HTTP通信使用默认端口（即HTTP为80，HTTPS为443），则无论请求URI中是否存在端口部分，都必须省略端口部分。在所有其他情况下，端口部分必须存在，并且不得包含前导零。当身份验证仅对特定协议（如HTTPS）有效时，请使用此格式。此格式相当于[RFC6454]第6.2节中所述的Web源的ASCII序列化。
o Single-host type: The "host" part of the requested URI. This is the default value. Authentication realms within this kind of authentication scope will span several protocols (e.g., HTTP and HTTPS) and ports but will not span different hosts.
o 单主机类型：请求URI的“主机”部分。这是默认值。这种身份验证范围内的身份验证领域将跨越多个协议（例如HTTP和HTTPS）和端口，但不会跨越不同的主机。
o Wildcard-domain type: A string in the format "*.<domain-postfix>", where <domain-postfix> is either the host part of the requested URI or any domain in which the requested host is included (this means that the specification "*.example.com" is valid for all of hosts "www.example.com", "web.example.com", "www.sales.example.com", and "example.com"). The domain-postfix sent by the servers MUST be equal to or included in a valid Internet domain assigned to a specific organization; if clients know, via some means such as a blacklist for HTTP cookies [RFC6265], that the specified domain is not to be assigned to any specific organization (e.g., "*.com" or "*.jp"), it is RECOMMENDED that clients reject the authentication request.
o 通配符域类型：格式为“*。<domain postfix>”的字符串，其中<domain postfix>是请求URI的主机部分或包含请求主机的任何域（这意味着规范“*.example.com”对所有主机“www.example.com”、“web.example.com”、“www.sales.example.com”和“example.com”都有效）。服务器发送的域后缀必须等于或包含在分配给特定组织的有效Internet域中；如果客户通过HTTP Cookie黑名单[RFC6265]等方式知道指定的域不会分配给任何特定组织（例如“*.com”或“*.jp”），建议客户拒绝认证请求。
In the above specifications, every "scheme", "host", and "domain" MUST be in lower case, and any internationalized domain names beyond the ASCII character set SHALL be represented in the way they are sent in the underlying HTTP protocol, represented in lowercase characters, i.e., these domain names SHALL be in the form of LDH ("letters, digits, hyphen") labels as defined in the Internationalized Domain Names for Applications (IDNA) specification [RFC5890]. A "port" MUST be given in shortest unsigned decimal number notation. Not obeying these requirements will cause valid authentication attempts to fail.
在上述规范中，每个“方案”、“主机”和“域”必须使用小写，ASCII字符集之外的任何国际化域名都应以底层HTTP协议中发送的方式表示，以小写字符表示，即这些域名应采用LDH的形式(“字母、数字、连字符”）标签，如国际应用程序域名（IDNA）规范[RFC5890]中所定义。“端口”必须以最短的无符号十进制数字表示法给出。不遵守这些要求将导致有效身份验证尝试失败。
In the above definitions of authentication scopes, several scopes may overlap each other. If a client has already been authenticated to several realms applicable to the same server, the client may have multiple lists of the "path" parameters received with the "401-KEX-S1" message (see Section 4). If these path lists have any overlap, a single URI may belong to multiple possible candidate realms to which the client can be authenticated. In such cases, clients face an ambiguous choice regarding which credentials to send for a new request (see Steps 3 and 4 of the decision procedure presented in Section 10).
在上述认证范围的定义中，多个范围可能相互重叠。如果客户机已通过适用于同一服务器的多个领域的身份验证，则该客户机可能具有随“401-KEX-S1”消息接收的多个“路径”参数列表（参见第4节）。如果这些路径列表有任何重叠，那么单个URI可能属于多个可能的候选领域，客户机可以通过这些候选领域的身份验证。在这种情况下，客户机面临一个模棱两可的选择，即为新请求发送哪些凭据（请参阅第10节中介绍的决策过程的步骤3和步骤4）。
In such cases, a client MAY freely send requests that belong to any of these candidate realms, or it MAY simply send an unauthenticated request and see for which realm the server requests an authentication. It is RECOMMENDED that server operators provide properly configured "path" parameters (more precisely, disjoint path sets for each realm) for clients so that such ambiguities will not occur.
在这种情况下，客户机可以自由地发送属于这些候选领域中任何一个领域的请求，或者只发送未经验证的请求，然后查看服务器为哪个领域请求身份验证。建议服务器操作员为客户端提供正确配置的“路径”参数（更准确地说，每个领域的不相交路径集），以避免出现这种歧义。
The following procedure is one possible tactic for resolving ambiguities in such cases:
以下程序是在此类情况下解决歧义的一种可能策略：
o If the client has previously sent a request to the same URI and it remembers the authentication realm requested by the 401-INIT message at that time, use that realm.
o 如果客户端以前向同一URI发送过请求，并且它记住了401-INIT消息当时请求的身份验证域，则使用该域。
o In other cases, use one of the authentication realms representing the most-specific authentication scopes. The list of possible domain specifications shown above is given from most specific to least specific.
o 在其他情况下，使用其中一个身份验证领域来表示最特定的身份验证范围。上面显示的可能域规范列表从最具体到最不具体。
If there are several choices with different wildcard-domain specifications, the one that has the longest domain-postfix has priority over those with shorter domain-postfixes.
如果有多个具有不同通配符域规范的选项，则具有最长域后缀的选项优先于具有较短域后缀的选项。
o If there are realms with the same authentication scope, there is no defined priority; the client MAY choose any one of the possible choices.
o 如果存在具有相同认证范围的领域，则没有定义优先级；客户可以选择任何一种可能的选择。
In the Mutual authentication protocol, a session represented by an sid is set up using four messages (first request, 401-INIT, req-KEX-C1, and 401-KEX-S1), after which a session secret (z) associated with the session is established. After mutually establishing a session secret, this session, along with the secret, can be used for one or more requests for resources protected by the same realm on the same server. Note that session management is only an inside detail of the protocol and usually not visible to normal users. If a session expires, the client and server SHOULD automatically re-establish another session without informing the user.
在相互认证协议中，使用四条消息（第一个请求、401-INIT、req-KEX-C1和401-KEX-S1）建立由sid表示的会话，然后建立与会话相关联的会话秘密（z）。在相互建立会话机密后，此会话以及该机密可用于对同一服务器上受同一领域保护的资源的一个或多个请求。请注意，会话管理只是协议的内部细节，通常对普通用户不可见。如果会话过期，客户端和服务器应自动重新建立另一个会话，而无需通知用户。
Sessions and session identifiers are local to each server (defined by scheme, host, and port), even if an authentication scope covers multiple servers; clients MUST establish separate sessions for each port of a host to be accessed. Furthermore, sessions and identifiers are also local to each authentication realm, even if they are provided by the same server. The same session identifiers provided either from different servers or for different realms MUST be treated as being independent of each other.
会话和会话标识符对于每个服务器都是本地的（由方案、主机和端口定义），即使身份验证范围覆盖多个服务器；客户端必须为要访问的主机的每个端口建立单独的会话。此外，会话和标识符对于每个身份验证领域也是本地的，即使它们是由相同的服务器提供的。从不同服务器或为不同领域提供的相同会话标识符必须视为彼此独立。
The server SHOULD accept at least one req-VFY-C request for each session if the request reaches the server in a time window specified by the "timeout" parameter in the 401-KEX-S1 message and if there are no emergent reasons (such as flooding attacks) to forget the session. After that, the server MAY discard any session at any time and MAY send 401-STALE messages for any further req-VFY-C requests received for that session.
如果请求在401-KEX-S1消息中“超时”参数指定的时间窗口内到达服务器，并且没有紧急原因（如洪水攻击）忘记会话，则服务器应为每个会话接受至少一个req-VFY-C请求。在此之后，服务器可随时丢弃任何会话，并可发送401-STALE消息以用于针对该会话接收的任何进一步req-VFY-C请求。
The client MAY send two or more requests using a single session specified by the sid. However, for all such requests, each value of the nonce number (in the "nc" parameter) MUST satisfy the following conditions:
客户端可以使用sid指定的单个会话发送两个或多个请求。但是，对于所有此类请求，nonce number（在“nc”参数中）的每个值必须满足以下条件：
o It is a natural number.
o 这是一个自然数。
o The same nonce number was not sent within the same session.
o 同一会话中未发送相同的nonce编号。
o It is not larger than the nc-max value that was sent from the server in the session represented by the sid.
o 它不大于sid表示的会话中从服务器发送的nc最大值。
o It is larger than (largest-nc - nc-window), where largest-nc is the largest value of nc that was previously sent in the session and nc-window is the value of the "nc-window" parameter that was received from the server for the session.
o 它大于（最大nc-nc窗口），其中最大nc是先前在会话中发送的nc的最大值，nc窗口是从会话服务器接收的“nc窗口”参数的值。
The last condition allows servers to reject any nonce numbers that are "significantly" smaller than the "current" value (defined by the value of nc-window) of the nonce number used in the session involved. In other words, servers MAY treat such nonce numbers as "already received". This restriction enables servers to implement duplicate-nonce detection in a constant amount of memory for each session.
最后一个条件允许服务器拒绝任何“明显”小于所涉及会话中使用的nonce编号的“当前”值（由nc窗口的值定义）的nonce编号。换句话说，服务器可能会将这些临时号码视为“已收到”。此限制使服务器能够在每个会话的固定内存量中实现重复的nonce检测。
Servers MUST check for duplication of the received nonce numbers, and if any duplication is detected, the server MUST discard the session and respond with a 401-STALE message, as outlined in Section 11. The server MAY also reject other invalid nonce numbers (such as those above the nc-max limit) by sending a 401-STALE message.
服务器必须检查接收到的nonce号码是否存在重复，如果检测到任何重复，服务器必须丢弃会话并使用401-STALE消息进行响应，如第11节所述。服务器还可以通过发送401-STALE消息来拒绝其他无效的nonce编号（例如高于nc max limit的编号）。
For example, assume that the nc-window value of the current session is 128 and nc-max is 400, and that the client has already used the following nonce numbers: {1-120, 122, 124, 130-238, 255-360, 363-372}. The nonce number that can then be used for the next request is a number from the following set: {245-254, 361, 362, 373-400}. The values {0, 121, 123, 125-129, 239-244} MAY be rejected by the server because they are not above the current "window limit" (244 = 372 - 128).
例如，假设当前会话的nc窗口值为128，nc max为400，并且客户端已经使用了以下nonce编号：{1-120、122、124、130-238、255-360、363-372}。然后可用于下一个请求的nonce编号是以下集合中的一个编号：{245-254、361、362、373-400}。服务器可能会拒绝值{0、121、123、125-129、239-244}，因为它们不高于当前的“窗口限制”（244=372-128）。
Typically, clients can ensure the above property by using a monotonically increasing integer counter that counts from zero up to the value of nc-max.
通常，客户端可以通过使用从零到nc-max值的单调递增整数计数器来确保上述属性。
The values of the nonce numbers and any nonce-related values MUST always be treated as natural numbers within an infinite range. Implementations that use fixed-width integer representations, fixed-precision floating-point numbers, or similar representations SHOULD NOT reject any larger values that overflow such representative limits and MUST NOT silently truncate them using any modulus-like rounding operation (e.g., by mod 2^32). Instead, the whole protocol is carefully designed so that recipients MAY replace any such overflowing values (e.g., 2^80) with some reasonably large maximum representative integer (e.g., 2^31 - 1 or others).
nonce数的值和任何与nonce相关的值必须始终被视为无限范围内的自然数。使用固定宽度整数表示法、固定精度浮点数或类似表示法的实现不应拒绝超出此类代表性限制的任何较大值，并且不得使用任何类似模的舍入操作（例如，通过mod 2^32）对其进行静默截断。相反，整个协议经过仔细设计，以便接收方可以用一些合理大的最大代表整数（例如，2^31-1或其他）替换任何此类溢出值（例如，2^80）。
The "validation method" specifies a method to "relate" (or "bind") the mutual authentication processed by this protocol with other authentications already performed in the underlying layers and to prevent man-in-the-middle attacks. It determines the value vh that is an input to the authentication protocols.
“验证方法”指定了一种方法，用于将此协议处理的相互身份验证与底层中已执行的其他身份验证“关联”（或“绑定”），并防止中间人攻击。它确定作为认证协议输入的值vh。
When HTTPS or another possible secure transport is used, this corresponds to the idea of "channel binding" as described in [RFC5929]. Even when HTTP is used, similar, but somewhat limited, "binding" is performed to prevent a malicious server from trying to authenticate itself to another server as a valid user by forwarding the received credentials.
当使用HTTPS或其他可能的安全传输时，这与[RFC5929]中所述的“通道绑定”思想相对应。即使使用HTTP，也会执行类似但有一定限制的“绑定”，以防止恶意服务器通过转发接收到的凭据，尝试将自己作为有效用户身份验证给另一台服务器。
The valid tokens for the "validation" parameter and corresponding values of vh are as follows:
“验证”参数的有效标记和vh的相应值如下所示：
host: hostname validation. The value vh will be the ASCII string in the following format: "<scheme>://<host>:<port>", where <scheme>, <host>, and <port> are the URI components corresponding to the server-side resource currently being accessed. The scheme and host are in lower case, and the port is listed in shortest decimal notation. Even if the request URI does not have a port part, vh will include the default port number.
主机名验证。值vh将是以下格式的ASCII字符串：“<scheme>：/<host>：<port>”，其中<scheme>、<host>和<port>是与当前正在访问的服务器端资源相对应的URI组件。方案和主机采用小写，端口以最短十进制表示法列出。即使请求URI没有端口部分，vh也将包括默认端口号。
tls-server-end-point: TLS endpoint (certificate) validation. The value vh will be the octet string of the hash value of the server's public key certificate used in the underlying TLS [RFC5246] connection, processed as specified in Section 4.1 of [RFC5929].
tls服务器终结点：tls终结点（证书）验证。值vh将是基础TLS[RFC5246]连接中使用的服务器公钥证书哈希值的八位字符串，按照[RFC5929]第4.1节的规定进行处理。
tls-unique: TLS shared-key validation. The value vh will be the channel-binding material derived from the Finished messages, as defined in Section 3.1 of [RFC5929]. (Note: See Section 7.2 for some security-related notes regarding this validation method.)
tls唯一：tls共享密钥验证。vh值将是根据[RFC5929]第3.1节中的定义，从完成的消息中导出的信道绑定材料。（注：有关此验证方法的一些安全相关说明，请参见第7.2节。）
If HTTP is used on a non-encrypted channel (TCP and the Stream Control Transmission Protocol (SCTP), for example), the validation type MUST be "host". If HTTP/TLS [RFC2818] (HTTPS) is used with a server certificate, the validation type MUST be "tls-server-end-point". If HTTP/TLS is used with an anonymous Diffie-Hellman key exchange, the validation type MUST be "tls-unique" (see the note below).
如果HTTP用于非加密通道（例如TCP和流控制传输协议（SCTP）），则验证类型必须为“主机”。如果HTTP/TLS[RFC2818]（HTTPS）与服务器证书一起使用，则验证类型必须为“TLS服务器端点”。如果HTTP/TLS与匿名Diffie-Hellman密钥交换一起使用，则验证类型必须为“TLS唯一”（请参见下面的注释）。
If the validation type "tls-server-end-point" is used, the server certificate provided in the TLS connection MUST be verified at least to make sure that the server actually owns the corresponding private key. (Note: This verification is automatic in some RSA-based key exchanges but is NOT automatic in Diffie-Hellman-based key exchanges with separate exchanges for server verification.)
如果使用验证类型“tls server end point”，则必须至少验证tls连接中提供的服务器证书，以确保服务器实际拥有相应的私钥。（注意：在一些基于RSA的密钥交换中，此验证是自动的，但在基于Diffie-Hellman的密钥交换中，此验证不是自动的，使用单独的交换进行服务器验证。）
Clients MUST validate this parameter upon receipt of 401-INIT messages.
客户端必须在收到401-INIT消息时验证此参数。
Note: The protocol defines two variants of validation on the TLS connections. The "tls-unique" method is technically more secure. However, there are some situations where "tls-server-end-point" is preferable:
注：协议定义了TLS连接验证的两种变体。“tls独特”方法在技术上更安全。但是，在某些情况下，“tls服务器端点”更可取：
o When TLS accelerating proxies are used. In this case, it is difficult for the authenticating server to acquire the TLS key information that is used between the client and the proxy. This is not the case for client-side "tunneling" proxies using the HTTP CONNECT method.
o 使用TLS加速代理时。在这种情况下，认证服务器很难获取客户端和代理之间使用的TLS密钥信息。对于使用HTTP连接方法的客户端“隧道”代理，情况并非如此。
o When a black-box implementation of the TLS protocol is used on either peer.
o 在任一对等机上使用TLS协议的黑盒实现时。
When the client is a Web browser with any scripting capabilities (support of dynamic contents), the underlying TLS channel used with HTTP/TLS MUST provide server identity verification. This means that (1) anonymous Diffie-Hellman key exchange cipher suites MUST NOT be used and (2) verification of the server certificate provided by the server MUST be performed. This is to prevent loading identity-unauthenticated scripts or dynamic contents, which are referenced from the authenticated page.
当客户端是具有任何脚本功能（支持动态内容）的Web浏览器时，与HTTP/TLS一起使用的底层TLS通道必须提供服务器身份验证。这意味着（1）不得使用匿名Diffie-Hellman密钥交换密码套件，（2）必须验证服务器提供的服务器证书。这是为了防止加载未经身份验证的脚本或动态内容，这些脚本或内容是从经过身份验证的页面引用的。
For other systems, when the underlying TLS channel used with HTTP/TLS does not perform server identity verification, the client SHOULD ensure that all responses are validated using the Mutual authentication protocol, regardless of the existence of 401-INIT responses.
对于其他系统，当与HTTP/TLS一起使用的底层TLS通道不执行服务器身份验证时，客户端应确保使用相互身份验证协议验证所有响应，而不管是否存在401-INIT响应。
As described in the interoperability note in Section 3.1 of [RFC5929], the "tls-unique" verification value will be changed by possible TLS renegotiation, causing an interoperability problem. TLS renegotiations are used in several HTTPS server implementations for enforcing some security properties (such as cryptographic strength) for some specific responses.
如[RFC5929]第3.1节中的互操作性说明所述，“tls唯一”验证值将因可能的tls重新协商而改变，从而导致互操作性问题。TLS重新协商在几个HTTPS服务器实现中用于强制某些特定响应的某些安全属性（如加密强度）。
If an implementation supports the "tls-unique" verification method, the following precautions SHOULD be taken:
如果实施支持“tls唯一”验证方法，则应采取以下预防措施：
o Both peers must be aware that the vh values used for vkc (in req-VFY-C messages) and vks (in 200-VFY-S messages) may be different. These values MUST be retrieved from underlying TLS libraries each time they are used.
o 两个对等方必须意识到，vkc（在req-VFY-C消息中）和vks（在200-VFY-S消息中）使用的vh值可能不同。每次使用这些值时，必须从底层TLS库中检索它们。
o After calculating the values vh and vkc to send a req-VFY-C request, clients SHOULD NOT initiate TLS renegotiation until the end of the corresponding response header is received. An exception is that clients can and SHOULD perform TLS renegotiation as a response to the server's request for TLS renegotiation, before receipt of the beginning of the response header.
o 在计算值vh和vkc以发送req-VFY-C请求后，客户端不应启动TLS重新协商，直到收到相应响应标头的末尾。例外情况是，在收到响应头的开头之前，客户端可以并且应该执行TLS重新协商，作为对服务器TLS重新协商请求的响应。
Also, implementers MUST take care of session resumption attacks regarding "tls-unique" channel-binding mechanisms and master secrets. As a mitigation, the TLS extension defined in [RFC7627] SHOULD be used when "tls-unique" host verification is to be used.
此外，实现者必须注意有关“tls唯一”通道绑定机制和主机密的会话恢复攻击。作为缓解措施，在使用“TLS唯一”主机验证时，应使用[RFC7627]中定义的TLS扩展。
It is RECOMMENDED that interactive clients (e.g., Web browsers) supporting this protocol support non-mandatory authentication and the Authentication-Control header defined in [RFC8053], except for the "auth-style" parameter. This specification also proposes (but does not mandate) that the default "auth-style" be "non-modal". Web applications SHOULD, however, consider the security impacts of the behavior of clients that do not support these headers.
建议支持此协议的交互式客户端（例如Web浏览器）支持非强制性身份验证和[RFC8053]中定义的身份验证控制头，但“auth style”参数除外。本规范还建议（但不强制要求）默认的“auth样式”为“非模态”。然而，Web应用程序应该考虑不支持这些标头的客户端行为的安全影响。
Authentication-initializing messages with the Optional-WWW-Authenticate header are used only where the 401-INIT response is valid. It will not replace other 401-type messages such as 401-STALE and 401-KEX-S1. That is, the "reason" field of such a message MUST be "initial" (or any extensive-tokens NOT defined in Section 4.1).
仅当401-INIT响应有效时，才使用带有可选WWW Authenticate标头的身份验证初始化消息。它不会替换其他401类型的消息，例如401-STALE和401-KEX-S1。也就是说，此类消息的“原因”字段必须为“初始”（或第4.1节中未定义的任何扩展标记）。
For interoperability reasons, it is important that usernames and passwords used in this protocol be binary-comparable, regardless of the user's input methods and/or environments. To ensure this, the following preparation SHOULD be performed:
出于互操作性的原因，无论用户的输入方法和/或环境如何，本协议中使用的用户名和密码必须具有二进制可比性。为确保这一点，应进行以下准备：
o Usernames received from users SHOULD be prepared using the "UsernameCasePreserved" profile defined in Section 3.3 of [RFC7613].
o 应使用[RFC7613]第3.3节中定义的“UsernameCasePreserved”配置文件准备从用户处收到的用户名。
o Passwords received from users SHOULD be prepared using the "OpaqueString" profile defined in Section 4.2 of [RFC7613].
o 应使用[RFC7613]第4.2节中定义的“OpaqueString”配置文件准备从用户处收到的密码。
In both cases, it is the sender's duty to correctly prepare the character strings. If any non-prepared character string is received from the other peer of the communication, the behavior of its recipient is not defined; the recipient MAY either accept or reject such input.
In both cases, it is the sender's duty to correctly prepare the character strings. If any non-prepared character string is received from the other peer of the communication, the behavior of its recipient is not defined; the recipient MAY either accept or reject such input.translate error, please retry
Server applications SHOULD also prepare usernames and passwords accordingly upon registration of user credentials.
服务器应用程序还应在注册用户凭据时相应地准备用户名和密码。
In addition, binary-based "interfaces" of implementations MAY require and assume that the string is already prepared accordingly; when a string is already stored as a binary Unicode string form, implementations MAY omit preparation and Unicode normalization (performing UTF-8 encoding only) before using it. When a string is already stored as an octet blob, implementations MAY send it as is.
此外，基于二进制的实现“接口”可能需要并假设字符串已经相应地准备好；当字符串已存储为二进制Unicode字符串形式时，实现可能会在使用它之前省略准备和Unicode规范化（仅执行UTF-8编码）。当字符串已经存储为八位字节blob时，实现可以按原样发送它。
To securely implement the protocol, the client must be careful about accepting the authenticated responses from the server. This also holds true for the reception of a "normal response" (a response that does not contain mutual-authentication-related headers) from HTTP servers.
为了安全地实现协议，客户机必须小心接受来自服务器的经过身份验证的响应。对于从HTTP服务器接收“正常响应”（不包含相互身份验证相关头的响应）也是如此。
Per typical HTTP authentication, a single user-level request may result in the exchange of two or more HTTP requests and responses in sequence. The following normative rules MUST be followed by the clients implementing this protocol:
根据典型的HTTP身份验证，单个用户级请求可能会导致按顺序交换两个或多个HTTP请求和响应。实施本协议的客户必须遵守以下规范性规则：
o Any kind of "normal response" MUST only be accepted for the very first request in the sequence. Any "normal response" returned for the second or subsequent requests in the sequence SHALL be considered invalid.
o 任何类型的“正常响应”都必须只接受序列中第一个请求。对于序列中的第二个或后续请求返回的任何“正常响应”均应视为无效。
o By the same principle, if any response is related to an authentication realm that is different from that of the client's request (for example, a 401-INIT message requesting authentication on another realm), it MUST only be accepted for the very first request in the sequence. Such a response returned for a second or subsequent request in the sequence SHALL be considered invalid.
o 根据相同的原则，如果任何响应与不同于客户端请求的身份验证域（例如，在另一个域上请求身份验证的401-INIT消息）的身份验证域相关，则必须仅对序列中的第一个请求接受该响应。对于序列中的第二个或后续请求返回的此类响应应视为无效。
o A req-KEX-C1 message MAY be sent as either an initial request or a response to a 401-INIT or 401-STALE message. However, to avoid infinite loops of messages, the req-KEX-C1 message SHOULD NOT be sent more than once in the sequence for a single authentication realm. A 401-KEX-S1 response MUST be accepted only when the corresponding request is req-KEX-C1.
o req-KEX-C1消息可以作为初始请求或对401-INIT或401-STALE消息的响应发送。但是，为了避免无限的消息循环，对于单个身份验证领域，不应按顺序多次发送req-KEX-C1消息。只有当相应的请求为req-KEX-C1时，才能接受401-KEX-S1响应。
o A req-VFY-C message MAY be sent if there is a valid session secret shared between the client and the server, as established by req-KEX-C1 and 401-KEX-S1 messages. If any response with a 401 status code is returned for such a message, the corresponding session secret SHOULD be discarded as unusable.
o 如req-KEX-C1和401-KEX-S1消息所确定，如果客户机和服务器之间共享有效会话秘密，则可发送req-VFY-C消息。如果针对此类消息返回任何带有401状态码的响应，则应将相应的会话机密视为不可用而丢弃。
In particular, upon the reception of a 401-STALE response, the client SHOULD try to establish a new session by sending a req-KEX-C1 message, but only once within the request/response sequence.
特别是，在接收到401-STALE响应时，客户端应通过发送req-KEX-C1消息尝试建立新会话，但在请求/响应序列中仅发送一次。
o A 200-VFY-S message MUST be accepted only as a response to a req-VFY-C message and nothing else. The VK_s values of such response messages MUST always be checked against the correct value, and if it is incorrect, the whole response SHOULD be considered invalid.
o 200-VFY-S消息必须仅作为对req-VFY-C消息的响应而被接受，不得接受其他任何消息。必须始终对照正确的值检查此类响应消息的VK_s值，如果该值不正确，则应认为整个响应无效。
The final status of the client request following the message exchange sequence shall be determined as follows:
按照消息交换顺序，客户端请求的最终状态应确定如下：
o AUTH-SUCCEED: A 200-VFY-S message with the correct VK_s value was returned in response to the req-VFY-C request in the sequence.
o AUTH-SUCCESS：返回一条具有正确VK_S值的200-VFY-S消息，以响应序列中的req-VFY-C请求。
o AUTH-REQUIRED: Two cases exist:
o 需要验证：存在两种情况：
* A 401-INIT message was returned from the server, and the client does not know how to authenticate to the given authentication realm.
* 服务器返回了401-INIT消息，客户端不知道如何对给定的身份验证域进行身份验证。
* A 401-INIT response was returned for a req-VFY-C (or req-KEX-C1) message, which means that the user-supplied authentication credentials were not accepted.
* 针对req-VFY-C（或req-KEX-C1）消息返回401-INIT响应，这意味着不接受用户提供的身份验证凭据。
o UNAUTHENTICATED: A "normal response" is returned for an initial request of any kind in the sequence.
o 未经验证：对于序列中任何类型的初始请求，都会返回“正常响应”。
Any kind of response (including a "normal response") other than those explicitly allowed in the above rules SHOULD be interpreted as a fatal communication error. In such cases, the clients MUST NOT process any data (the response body and other content-related headers) sent from the server. However, to handle exceptional error cases, clients MAY accept a message without an Authentication-Info header if it has a Server Error (5xx) status code. In such cases, they SHOULD be careful about processing the body of the content (ignoring it is still RECOMMENDED, as it may possibly be forged by intermediate attackers), and the client will then have a status of "UNAUTHENTICATED".
除上述规则中明确允许的响应外，任何类型的响应（包括“正常响应”）都应解释为致命通信错误。在这种情况下，客户端不得处理从服务器发送的任何数据（响应正文和其他与内容相关的标题）。但是，为了处理异常错误情况，如果消息具有服务器错误（5xx）状态代码，则客户端可能会接受没有身份验证信息头的消息。在这种情况下，他们应该小心处理内容主体（仍然建议忽略它，因为它可能被中间攻击者伪造），然后客户端的状态将为“未经验证”。
If a request is a sub-request for a resource included in another resource (e.g., embedded images, style sheets, frames), clients MAY treat an AUTH-REQUESTED status the same way they would treat an UNAUTHENTICATED status. In other words, the client MAY ignore the server's request to start authentication with new credentials via sub-requests.
如果一个请求是对另一个资源（例如，嵌入的图像、样式表、帧）中包含的资源的子请求，则客户端可以像对待未经身份验证的状态一样对待身份验证请求的状态。换句话说，客户端可能会忽略服务器通过子请求开始使用新凭据进行身份验证的请求。
The following state machine describes the possible request-response sequences derived from the above normative rules. If implementers are not quite sure of the security consequences of the above rules, we strongly advise that the decision procedure below be followed. In particular, clients SHOULD NOT accept "normal responses" unless explicitly allowed in the rules. The labels in the steps below are
以下状态机描述了从上述规范性规则派生的可能的请求-响应序列。如果实施者不太确定上述规则的安全后果，我们强烈建议遵循以下决策过程。特别是，除非规则中明确允许，否则客户端不应接受“正常响应”。以下步骤中的标签如下所示
for informational purposes only. Action entries within each step are checked in top-to-bottom order, and the first clause satisfied is to be followed.
仅供参考。每个步骤中的操作条目按自上而下的顺序进行检查，并遵循满足的第一个子句。
Step 1 (step_new_request): If the client software needs to access a new Web resource, check to see whether the resource is expected to be inside some authentication realm for which the user has already been authenticated via the Mutual authentication scheme. If yes, go to Step 2. Otherwise, go to Step 5.
步骤1（Step_new_request）：如果客户端软件需要访问一个新的Web资源，请检查该资源是否预期位于某个身份验证领域内，用户已经通过相互身份验证方案进行了身份验证。如果是，请转至步骤2。否则，转至步骤5。
Step 2: Check to see whether there is an available sid for the expected authentication realm. If there is one, go to Step 3. Otherwise, go to Step 4.
步骤2：检查预期的身份验证领域是否有可用的sid。如果有，请转至步骤3。否则，转至步骤4。
Step 3 (step_send_vfy_1): Send a req-VFY-C request.
步骤3（步骤1）：发送req-vfy-C请求。
* If a 401-INIT message is received with a different authentication realm than expected, go to Step 6.
* 如果收到的401-INIT消息的身份验证域与预期的不同，请转至步骤6。
* If a 401-STALE message is received, go to Step 9.
* 如果收到401-STALE消息，请转至步骤9。
* If a 401-INIT message is received, go to Step 13.
* 如果收到401-INIT消息，则转至步骤13。
* If a 200-VFY-S message is received, go to Step 14.
* 如果收到200-VFY-S消息，则转至步骤14。
* If a "normal response" is received, go to Step 11.
* 如果收到“正常响应”，则转至步骤11。
Step 4 (step_send_kex1_1): Send a req-KEX-C1 request.
步骤4（步骤发送kex1-1）：发送req-KEX-C1请求。
* If a 401-INIT message is received with a different authentication realm than expected, go to Step 6.
* 如果收到的401-INIT消息的身份验证域与预期的不同，请转至步骤6。
* If a 401-KEX-S1 message is received, go to Step 10.
* 如果收到401-KEX-S1消息，请转至步骤10。
* If a 401-INIT message is received with the same authentication realm, go to Step 13 (see Note 1).
* 如果使用相同的身份验证域接收401-INIT消息，请转至步骤13（请参见注释1）。
* If a "normal response" is received, go to Step 11.
* 如果收到“正常响应”，则转至步骤11。
Step 5 (step_send_normal_1): Send a request without any mutual-authentication headers.
步骤5（步骤1）：在不使用任何相互身份验证头的情况下发送请求。
* If a 401-INIT message is received, go to Step 6.
* 如果收到401-INIT消息，请转至步骤6。
* If a "normal response" is received, go to Step 11.
* 如果收到“正常响应”，则转至步骤11。
Step 6 (step_rcvd_init): Check to see whether the user's password for the requested authentication realm is known. If yes, go to Step 7. Otherwise, go to Step 12.
步骤6（Step_rcvd_init）：检查所请求的身份验证领域的用户密码是否已知。如果是，请转至步骤7。否则，转至步骤12。
Step 7: Check to see whether there is an available sid for the expected authentication realm. If there is one, go to Step 8. Otherwise, go to Step 9.
步骤7：检查预期的身份验证领域是否有可用的sid。如果有，请转至步骤8。否则，转至步骤9。
Step 8 (step_send_vfy): Send a req-VFY-C request.
步骤8（步骤发送）：发送req-vfy-C请求。
* If a 401-STALE message is received, go to Step 9.
* 如果收到401-STALE消息，请转至步骤9。
* If a 401-INIT message is received, go to Step 13.
* 如果收到401-INIT消息，则转至步骤13。
* If a 200-VFY-S message is received, go to Step 14.
* 如果收到200-VFY-S消息，则转至步骤14。
Step 9 (step_send_kex1): Send a req-KEX-C1 request.
步骤9（步骤发送）：发送req-KEX-C1请求。
* If a 401-KEX-S1 message is received, go to Step 10.
* 如果收到401-KEX-S1消息，请转至步骤10。
* If a 401-INIT message is received, go to Step 13 (see Note 1).
* 如果收到401-INIT消息，则转至步骤13（参见注释1）。
Step 10 (step_rcvd_kex1): Send a req-VFY-C request.
步骤10（步骤rcvd）：发送req-VFY-C请求。
* If a 401-INIT message is received, go to Step 13.
* 如果收到401-INIT消息，则转至步骤13。
* If a 200-VFY-S message is received, go to Step 14.
* 如果收到200-VFY-S消息，则转至步骤14。
Step 11 (step_rcvd_normal): The requested resource is out of the authenticated area. The client will be in the "UNAUTHENTICATED" status. If the response contains a request for authentication other than Mutual authentication, it MAY be handled normally.
步骤11（步骤_rcvd _normal）：请求的资源不在已验证区域内。客户端将处于“未经验证”状态。如果响应包含相互认证以外的认证请求，则可以正常处理。
Step 12 (step_rcvd_init_unknown): The requested resource requires Mutual authentication, and the user is not yet authenticated. The client will be in the "AUTH-REQUESTED" status; it is RECOMMENDED that the client process the content sent from the server and ask the user for a username and password. When those are supplied by the user, go to Step 9.
Step 12 (step_rcvd_init_unknown): The requested resource requires Mutual authentication, and the user is not yet authenticated. The client will be in the "AUTH-REQUESTED" status; it is RECOMMENDED that the client process the content sent from the server and ask the user for a username and password. When those are supplied by the user, go to Step 9.translate error, please retry
Step 13 (step_rcvd_init_failed): The authentication failed for some reason, possibly because the password or username is invalid for the authenticated resource. Forget the user-provided credentials for the authentication realm, and go to Step 12.
步骤13（Step_rcvd_init_失败）：身份验证由于某种原因失败，可能是因为密码或用户名对于已验证的资源无效。忘记用户为身份验证领域提供的凭据，然后转至步骤12。
Step 14 (step_rcvd_vfy): The received message is the 200-VFY-S message, which always contains a "vks" field. Check the validity of the received VK_s value. If it is equal to the expected value, then the mutual authentication succeeded. The client will be in the "AUTH-SUCCEED" status.
步骤14（步骤_rcvd_vfy）：收到的消息是200-vfy-S消息，它始终包含一个“vks”字段。检查收到的VK_s值的有效性。如果它等于预期值，则相互身份验证成功。客户端将处于“AUTH-success”状态。
An unexpected value is interpreted as a fatal communication error.
意外值被解释为致命的通信错误。
If a user explicitly asks to log out (via the user interface), the client MUST forget the user's password, go to Step 5, and reload the current resource without an authentication header.
如果用户明确要求注销（通过用户界面），客户端必须忘记用户的密码，转到步骤5，重新加载当前资源，而不使用身份验证标头。
Note 1: These transitions MAY be accepted by clients, but it is NOT RECOMMENDED that servers initiate them.
注1：客户机可能会接受这些转换，但不建议服务器启动它们。
Figure 5 shows an informative diagram of the client state.
图5显示了客户机状态的信息图表。
=========== -(11)------------
NEW REQUEST ( UNAUTHENTICATED )
=========== -----------------
| ^ normal
v | response
+(1)-------------------+ NO +(5)----------+
| The requested URI |--------------------------->| send normal |
| known to be auth'ed? | | request |
+----------------------+ +-------------+
YES | 401-INIT 401-INIT|
| with a different realm |
| -----------------------------------. |
| / v v
| | -(12)------------ NO +(6)--------+
| | ( AUTH-REQUESTED )<------| user/pass |
| | ----------------- | known? |
| | +-----------+
| | |YES
v | v
+(2)--------+ | +(7)--------+
| session | | | session | NO
NO /| available?| | | available?|\
/ +-----------+ | +-----------+ |
/ |YES | |YES |
| | /| | |
| v / | 401- 401- v |
| +(3)--------+ | INIT --(13)---------- INIT +(8)--------+ |
| | send |--+----->/ AUTH-REQUESTED \<-------| send | |
| /| req-VFY-C | | \forget password / | req-VFY-C | |
\/ +-----------+ / ---------------- /+-----------+ |
/\ \ \/ ^ 401-INIT | |401- |
| ------ \/\ 401-STALE | | | STALE /
| \ /\ -----------------+--------------+---. | /
| | / \ | | | | /
| v / | 401- | 401- | v v v
| +(4)--------+ | KEX-S1 +(10)-------+ KEX-S1 | +(9)--------+
| | send |-|--------->| send |<-------+-| send |
| --| req-KEX-C1| | | req-VFY-C | | | req-KEX-C1|
|/ +-----------+ | +-----------+ | +-----------+
| |200-VFY-S | 200-VFY-S| ^
|normal | |200-VFY-S / |
|response | v / ==================
v \ -(14)--------- / USER/PASS INPUTTED
-(11)------------ ------->( AUTH-SUCCEED )<-- ==================
( UNAUTHENTICATED ) --------------
-----------------
=========== -(11)------------
NEW REQUEST ( UNAUTHENTICATED )
=========== -----------------
| ^ normal
v | response
+(1)-------------------+ NO +(5)----------+
| The requested URI |--------------------------->| send normal |
| known to be auth'ed? | | request |
+----------------------+ +-------------+
YES | 401-INIT 401-INIT|
| with a different realm |
| -----------------------------------. |
| / v v
| | -(12)------------ NO +(6)--------+
| | ( AUTH-REQUESTED )<------| user/pass |
| | ----------------- | known? |
| | +-----------+
| | |YES
v | v
+(2)--------+ | +(7)--------+
| session | | | session | NO
NO /| available?| | | available?|\
/ +-----------+ | +-----------+ |
/ |YES | |YES |
| | /| | |
| v / | 401- 401- v |
| +(3)--------+ | INIT --(13)---------- INIT +(8)--------+ |
| | send |--+----->/ AUTH-REQUESTED \<-------| send | |
| /| req-VFY-C | | \forget password / | req-VFY-C | |
\/ +-----------+ / ---------------- /+-----------+ |
/\ \ \/ ^ 401-INIT | |401- |
| ------ \/\ 401-STALE | | | STALE /
| \ /\ -----------------+--------------+---. | /
| | / \ | | | | /
| v / | 401- | 401- | v v v
| +(4)--------+ | KEX-S1 +(10)-------+ KEX-S1 | +(9)--------+
| | send |-|--------->| send |<-------+-| send |
| --| req-KEX-C1| | | req-VFY-C | | | req-KEX-C1|
|/ +-----------+ | +-----------+ | +-----------+
| |200-VFY-S | 200-VFY-S| ^
|normal | |200-VFY-S / |
|response | v / ==================
v \ -(14)--------- / USER/PASS INPUTTED
-(11)------------ ------->( AUTH-SUCCEED )<-- ==================
( UNAUTHENTICATED ) --------------
-----------------
Figure 5: State Diagram for Clients
图5：客户端的状态图
Each server SHOULD have a table of session states. This table need not be persistent over the long term; it MAY be cleared upon server restart, reboot, or for other reasons. Each entry in the table SHOULD contain at least the following information:
每个服务器都应该有一个会话状态表。该表不需要长期保持不变；它可能会在服务器重新启动、重新启动或出于其他原因时被清除。表中的每个条目应至少包含以下信息：
o The session identifier, which is the value of the "sid" parameter.
o 会话标识符，它是“sid”参数的值。
o The algorithm used.
o 使用的算法。
o The authentication realm.
o 身份验证领域。
o The state of the protocol: one of "key exchanging", "authenticated", "rejected", or "inactive".
o 协议状态：“密钥交换”、“已验证”、“已拒绝”或“不活动”。
o The username received from the client.
o 从客户端接收的用户名。
o A boolean flag indicating whether or not the session is fake.
o 一个布尔标志，指示会话是否为假。
o When the state is "key exchanging", the values of K_c1 and S_s1.
o 当状态为“密钥交换”时，K_c1和S_s1的值。
o When the state is "authenticated", the following information:
o 当状态为“已验证”时，将显示以下信息：
* The value of the session secret (z).
* 会话机密的值（z）。
* The largest nc received from the client (largest-nc).
* 从客户端接收的最大nc（最大nc）。
* For each possible nc value between (largest-nc - nc-window + 1) and max_nc, a boolean flag indicating whether or not a request with the corresponding nc has been received.
* 对于（最大nc-nc窗口+1）和最大nc之间的每个可能的nc值，一个布尔标志指示是否已收到具有相应nc的请求。
The table MAY contain other information.
该表可能包含其他信息。
Servers SHOULD respond to the client requests according to the following procedure (see Note 1 below regarding 401-INIT messages with a plus sign):
服务器应根据以下程序响应客户端请求（关于带加号的401-INIT消息，请参见下面的注释1）：
o When the server receives a "normal request":
o 当服务器收到“正常请求”时：
* If the requested resource is not protected by the Mutual authentication, send a "normal response".
* 如果请求的资源不受相互身份验证的保护，请发送“正常响应”。
* If the resource is protected by the Mutual authentication, send a 401-INIT response.
* 如果资源受相互身份验证保护，则发送401-INIT响应。
o When the server receives a req-KEX-C1 request:
o 当服务器收到req-KEX-C1请求时：
* If the requested resource is not protected by the Mutual authentication, send a "normal response".
* 如果请求的资源不受相互身份验证的保护，请发送“正常响应”。
* If the authentication realm specified in the req-KEX-C1 request is not the expected realm, send a 401-INIT response.
* 如果req-KEX-C1请求中指定的身份验证域不是预期的域，则发送401-INIT响应。
* If the server cannot validate the parameter "kc1", send a 401-INIT (+) response.
* 如果服务器无法验证参数“kc1”，请发送401-INIT（+）响应。
* If the received username is either invalid, unknown, or unacceptable, create a new session, mark it as a "fake" session, compute a random value as K_s1, and send a fake 401-KEX-S1 response (see Note 2).
* 如果收到的用户名无效、未知或不可接受，则创建一个新会话，将其标记为“伪”会话，计算一个随机值为K_s1，并发送一个伪401-KEX-s1响应（参见注释2）。
* Otherwise, create a new session, compute K_s1, and send a 401-KEX-S1 response. The created session is marked as not fake, and its largest-nc value is initialized to zero.
* 否则，创建一个新会话，计算K_s1，并发送401-KEX-s1响应。创建的会话被标记为not fake，其最大nc值初始化为零。
The created session is in the "key exchanging" state.
创建的会话处于“密钥交换”状态。
o When the server receives a req-VFY-C request:
o 当服务器收到req-VFY-C请求时：
* If the requested resource is not protected by the Mutual authentication, send a "normal response".
* 如果请求的资源不受相互身份验证的保护，请发送“正常响应”。
* If the authentication realm specified in the req-VFY-C request is not the expected realm, send a 401-INIT response.
* 如果req-VFY-C请求中指定的身份验证域不是预期的域，则发送401-INIT响应。
If none of the above holds true, the server will look up the session corresponding to the received sid and the authentication realm.
如果上述条件均不成立，服务器将查找与接收到的sid和身份验证域对应的会话。
* If the session corresponding to the received sid could not be found or it is in the "inactive" state, send a 401-STALE response.
* 如果找不到与接收到的sid对应的会话，或者该会话处于“非活动”状态，请发送401-STALE响应。
* If the session is in the "rejected" state, send either a 401-INIT (+) response or a 401-STALE message.
* 如果会话处于“拒绝”状态，请发送401-INIT（+）响应或401-STALE消息。
* If the nc value in the request is larger than the "nc-max" parameter sent from the server or it is not larger than (largest-nc - nc-window) (when in the "authenticated" state), the server MAY (but is not REQUIRED to; see Note 3) send a 401-STALE message. The session is changed to the "inactive" state if the 401-STALE message was sent.
* 如果请求中的nc值大于从服务器发送的“nc max”参数，或者不大于（最大nc-nc窗口）（当处于“已验证”状态时），服务器可以（但无需；请参见注释3）发送401-STALE消息。如果发送401-STALE消息，会话将更改为“非活动”状态。
* If the session is in the "authenticated" state and the request has an nc value that was previously received from the client, send a 401-STALE message. The session is changed to the "inactive" state.
* 如果会话处于“已验证”状态，并且请求具有以前从客户端接收到的nc值，则发送401-STALE消息。会话将更改为“非活动”状态。
* If the session is a "fake" session or the received vkc is incorrect, then send a 401-INIT (+) response. If the session is in the "key exchanging" state, it MUST be changed to the "rejected" state; otherwise, it MAY be either changed to the "rejected" state or kept in the previous state.
* 如果会话是“假”会话或收到的vkc不正确，则发送401-INIT（+）响应。如果会话处于“密钥交换”状态，则必须将会话更改为“拒绝”状态；否则，可能会将其更改为“拒绝”状态或保持在以前的状态。
* Otherwise, send a 200-VFY-S response. If the session was in the "key exchanging" state, the session SHOULD be changed to the "authenticated" state. The maximum nc and nc flags of the state MUST be updated appropriately.
* 否则，发送200-VFY-S响应。如果会话处于“密钥交换”状态，则会话应更改为“已验证”状态。必须适当更新状态的最大nc和nc标志。
At any time, the server MAY change any state entries with both the "rejected" and "authenticated" states to the "inactive" state and MAY discard any "inactive" states from the table. Entries with the "key exchanging" state SHOULD be kept unless there is an emergency situation such as a server reboot or a table capacity overflow.
在任何时候，服务器都可以将具有“拒绝”和“已验证”状态的任何状态条目更改为“非活动”状态，并可以从表中丢弃任何“非活动”状态。除非出现紧急情况，如服务器重新启动或表容量溢出，否则应保留具有“密钥交换”状态的条目。
Note 1: In relation to, and following the specification of, the optional authentication defined in [RFC8053], the 401-INIT messages marked with plus signs cannot be replaced with a successful response with an Optional-WWW-Authenticate header. Every other 401-INIT can be a response with an Optional-WWW-Authenticate header.
注1：根据[RFC8053]中定义的可选身份验证规范，带有加号的401-INIT消息不能替换为带有可选WWW Authenticate标头的成功响应。每隔401-INIT可以是一个带有可选WWW认证头的响应。
Note 2: The server SHOULD NOT send a 401-INIT response in this case, because it will leak the information to the client that the specified username will not be accepted. Instead, postpone it until the response to the next req-VFY-C request.
注2：在这种情况下，服务器不应发送401-INIT响应，因为它会将指定用户名不被接受的信息泄漏给客户端。相反，将其推迟到下一个req-VFY-C请求的响应。
Note 3: If the request is not rejected in this clause, the server will be required, in the next step, to determine whether the same nc value was previously received from the client. If that is impossible, the server MUST send a 401-STALE response in this step. If the server does not remember the whole history of the nc values received from the client, the server MUST send a 401-STALE message in this clause.
注3：如果本条款中的请求未被拒绝，则下一步将要求服务器确定之前是否从客户端接收到相同的nc值。如果不可能，服务器必须在此步骤中发送401-STALE响应。如果服务器不记得从客户端接收的nc值的整个历史记录，则服务器必须在此子句中发送401-STALE消息。
Cryptographic authentication algorithms that are used with this protocol will be defined separately. The algorithm definition MUST at least provide definitions for the following functions:
与此协议一起使用的加密身份验证算法将单独定义。算法定义必须至少提供以下函数的定义：
o The server-side authentication credential J, derived from the client-side authentication credential pi.
o 服务器端身份验证凭据J，来自客户端身份验证凭据pi。
o Key exchange values K_c1, K_s1 (exchanged on the wire) and S_c1, S_s1 (kept secret in each peer).
o 密钥交换值K_c1、K_s1（在线路上交换）和S_c1、S_s1（在每个对等方中保密）。
o Shared session secret (z), to be computed by both server and client.
o 共享会话机密（z），由服务器和客户端计算。
o A hash function H to be used with the protocol, along with its output size hSize.
o 与协议一起使用的哈希函数H及其输出大小hSize。
o The value nIterPi, the number of iterations for the key derivation operation.
o 值nIterPi，键派生操作的迭代次数。
Specifications for cryptographic algorithms used with this framework MUST specify whether those algorithms will (1) use the default functions defined below for values pi, VK_c, and VK_s or (2) define their own comparable functions.
与此框架一起使用的加密算法规范必须指定这些算法是（1）使用下面定义的值pi、VK_c和VK_s的默认函数，还是（2）定义它们自己的可比较函数。
All algorithms used with this protocol SHOULD provide secure mutual authentication between clients and servers and generate a cryptographically strong shared secret value (z) that is equally strong or stronger than the hash function H. If any passwords (or passphrases or any equivalents, i.e., weak secrets) are involved, these SHOULD NOT be guessable from any data transmitted in the protocol, even if an attacker (either an eavesdropper or an active server) knows the possible thoroughly searchable candidate list of passwords. Furthermore, it is RECOMMENDED that the function J for deriving the server-side authentication credential J(pi) be one-way, if possible, so that pi cannot be easily computed from J(pi).
与本协议一起使用的所有算法应在客户端和服务器之间提供安全的相互身份验证，并生成一个加密强共享秘密值（z），该值与散列函数H的强度相同或更强。如果涉及任何密码（或密码短语或任何等价物，即弱秘密），即使攻击者（窃听者或活动服务器）知道可能的可彻底搜索的候选密码列表，也不应通过协议中传输的任何数据猜测这些密码。此外，如果可能的话，建议用于导出服务器端认证凭证J（pi）的函数J是单向的，以便pi不能容易地从J（pi）计算出来。
In this section, we define several support functions and notations to be shared by several algorithm definitions.
在本节中，我们定义了几个支持函数和符号，以供几个算法定义共享。
The integers in the specification are in decimal, or in hexadecimal when prefixed with "0x".
规范中的整数是十进制的，如果前缀为“0x”，则是十六进制的。
The function octet(i) generates an octet string containing a single octet of value i. The operator "|", when applied to octet strings, denotes the concatenation of two operands.
函数octet（i）生成一个八位字节字符串，其中包含一个值为i的八位字节。运算符“|”应用于八位字节字符串时，表示两个操作数的串联。
The function VI encodes natural numbers into octet strings in the following manner: numbers are represented as big-endian radix-128 strings, where each digit is represented by an octet within the range 0x80-0xff, except for the last digit, which is represented by an octet within the range 0x00-0x7f. The first octet MUST NOT be 0x80. For example, VI(i) = octet(i) for i < 128, and VI(i) = octet(0x80 + (i >> 7)) | octet(i & 127) for 128 <= i < 16384. This encoding is the same as the encoding used for the subcomponents of object identifiers in ASN.1 encoding [ITU.X690.2015] and is available as a "w" conversion in the "pack" function of several scripting languages.
函数VI以以下方式将自然数编码为八位字节字符串：数字表示为大端基数-128字符串，其中每个数字由0x80-0xff范围内的八位字节表示，但最后一个数字除外，该数字由0x00-0x7f范围内的八位字节表示。第一个八位字节不能是0x80。例如，对于i<128，VI（i）=八位组（i），对于128<=i<16384，VI（i）=八位组（0x80+（i>>7））|八位组（i&127）。该编码与ASN.1编码[ITU.X690.2015]中用于对象标识符子组件的编码相同，并且在几种脚本语言的“pack”函数中以“w”转换形式提供。
The function VS encodes a variable-length octet string into a uniquely decoded, self-delimited octet string in the following manner:
函数VS以以下方式将可变长度八位字节字符串编码为唯一解码的自分隔八位字节字符串：
VS(s) = VI(length(s)) | s
VS(s) = VI(length(s)) | s
where length(s) is a number of octets (not characters) in s.
其中，长度（s）是以s为单位的八位字节数（不是字符）。
Some examples:
一些例子：
VI(0) = "\000" (in C string notation)
VI（0）=“\000”（用C字符串表示法）
VI(100) = "d"
VI（100）=“d”
VI(10000) = "\316\020"
VI（10000）=“\316\020”
VI(1000000) = "\275\204@"
VI(1000000) = "\275\204@"
VS("") = "\000"
VS（“”=“\000”
VS("Tea") = "\003Tea"
VS（“Tea”）=“\003Tea”
VS("Caf<e acute>" [in UTF-8]) = "\005Caf\303\251"
VS("Caf<e acute>" [in UTF-8]) = "\005Caf\303\251"
VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets)
VS（[10000“a”s]）=“\316\020AAAA…”（10002个八位字节）
(Note: Unlike the colon-separated format used in the Basic and Digest HTTP authentication schemes, the string generated by a concatenation of the VS-encoded strings will be unique, regardless of the characters included in the strings to be encoded.)
（注意：与基本和摘要HTTP身份验证方案中使用的冒号分隔格式不同，由VS编码字符串串联生成的字符串将是唯一的，而与要编码的字符串中包含的字符无关。）
The function OCTETS converts an integer into the corresponding radix-256 big-endian octet string having its natural length. See Section 3.2.3 for the definition of "natural length".
函数OCTETS将整数转换为相应的具有自然长度的基数256大端八进制字符串。“自然长度”的定义见第3.2.3节。
The function INT converts an octet string into a natural number, where the input string is treated as being in radix-256 big-endian notation. The identity INT(OCTETS(n)) = n always holds for any natural number n.
函数INT将八位字节字符串转换为自然数，其中输入字符串被视为基数为256的大端符号。对于任何自然数n，标识INT（八位组（n））=n始终保持不变。
The functions defined in this section are common default functions among authentication algorithms.
本节中定义的函数是身份验证算法中常见的默认函数。
The client-side password-based (credential) pi used by this authentication is a natural number derived in the following manner:
此身份验证使用的基于客户端密码（凭据）pi是一个自然数，其派生方式如下：
pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) |
VS(realm) | VS(username), nIterPi, hSize / 8))
pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) |
VS(realm) | VS(username), nIterPi, hSize / 8))
where
哪里
o PBKDF2 is the password-based key derivation function defined in [RFC8018],
o PBKDF2是[RFC8018]中定义的基于密码的密钥派生函数，
o HMAC_H is the Hashed Message Authentication Code (HMAC) function, defined in [RFC2104], composed from the hash function H, and
o HMAC_H是[RFC2104]中定义的哈希消息身份验证码（HMAC）函数，由哈希函数H组成，以及
o hSize is the output size of hash H in bits.
o hSize是哈希H的输出大小，以位为单位。
The values of algorithm, realm, and auth-scope are taken from the values contained in the 401-INIT message. If the password comes from user input, it SHOULD first be prepared according to the method presented in Section 9. Then, the password SHALL be encoded as a UTF-8 string.
algorithm、realm和auth scope的值取自401-INIT消息中包含的值。如果密码来自用户输入，则应首先按照第9节中介绍的方法准备密码。然后，密码应编码为UTF-8字符串。
The values VK_c and VK_s are derived via the following equations:
VK_c和VK_s的值通过以下方程式得出：
VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh)))
VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh)))
VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh)))
VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh)))
Applications and upper-layer communication protocols may need authentication binding to the HTTP-layer authenticated user. Such applications MAY use the following values as a standard shared secret.
应用程序和上层通信协议可能需要将身份验证绑定到HTTP层身份验证用户。此类应用程序可以使用以下值作为标准共享机密。
These values are parameterized with an optional octet string (t), which may be arbitrarily chosen by each application or protocol. If there is no appropriate value to be specified, use an empty string for t.
这些值由可选的八位字节字符串（t）参数化，每个应用程序或协议可以任意选择该字符串。如果没有要指定的适当值，请为t使用空字符串。
For applications requiring binding to either an authenticated user or a shared-key session (to ensure that the requesting client is authenticated), the following value b_1 MAY be used:
对于需要绑定到经过身份验证的用户或共享密钥会话（以确保请求的客户端经过身份验证）的应用程序，可以使用以下值b_1：
b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(0) | VS(vh)) | VS(t))
b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(0) | VS(vh)) | VS(t))
For applications requiring binding to a specific request (to ensure that the payload data is generated for the exact HTTP request), the following value b_2 MAY be used:
对于需要绑定到特定请求的应用程序（以确保为确切的HTTP请求生成有效负载数据），可以使用以下值b_2：
b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh)) | VS(t))
b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh)) | VS(t))
Note: Channel bindings to lower-layer transports (TCP and TLS) are defined in Section 7.
注：低层传输（TCP和TLS）的通道绑定在第7节中定义。
The authentication scheme defined in the previous sections can be applied (with modifications) to proxy authentication. In such cases, the following alterations MUST be applied:
前面几节中定义的身份验证方案可以（经过修改）应用于代理身份验证。在这种情况下，必须进行以下修改：
o The 407 (Proxy Authentication Required) status code is to be sent and recognized in places where the 401 status code is used,
o 将在使用401状态代码的地方发送和识别407（需要代理身份验证）状态代码，
o The Proxy-Authenticate header is to be used in places where the WWW-Authenticate header is used,
o 代理身份验证标头将用于使用WWW身份验证标头的位置，
o The Proxy-Authorization header is to be used in places where the Authorization header is used,
o 代理授权标头将在使用授权标头的地方使用，
o The Proxy-Authentication-Info header is to be used in places where the Authentication-Info header is used,
o 代理身份验证信息头将用于使用身份验证信息头的位置，
o The "auth-scope" parameter is fixed to the hostname of the proxy, which means that it covers all requests processed by the specific proxy,
o “auth scope”参数固定为代理的主机名，这意味着它涵盖了特定代理处理的所有请求，
o The limitation for the paths contained in the "path" parameter of 401-KEX-S1 messages is disregarded,
o 401-KEX-S1消息的“path”参数中包含的路径限制被忽略，
o The omission of the "path" parameter of 401-KEX-S1 messages means that the authentication realm will potentially cover all requests processed by the proxy,
o 401-KEX-S1消息中“path”参数的省略意味着身份验证领域可能涵盖代理处理的所有请求，
o The scheme, hostname, and port of the proxy are used for host validation tokens, and
o 代理的方案、主机名和端口用于主机验证令牌，以及
o Authentication extensions defined in [RFC8053] are not applicable.
o [RFC8053]中定义的身份验证扩展不适用。
If a private extension to this protocol is implemented, it MUST use the extension-tokens defined in Section 3 to avoid conflicts with this protocol and other extensions. (Standardized extensions, as well as extensions that are in the process of being standardized, MAY use either bare-tokens or extension-tokens.)
如果实现了此协议的专用扩展，则必须使用第3节中定义的扩展令牌，以避免与此协议和其他扩展冲突。（标准化扩展以及正在标准化的扩展可以使用裸令牌或扩展令牌。）
Specifications defining authentication algorithms MAY use other representations for the parameters "kc1", "ks1", "vkc", and "vks"; replace those parameter names; and/or add parameters to the messages containing those parameters in supplemental specifications, provided that syntactic and semantic requirements in Section 3 of this document, [RFC7230], and [RFC7235] are satisfied. Any parameters starting with "kc", "ks", "vkc", or "vks" and followed by decimal natural numbers (e.g., kc2, ks0, vkc1, vks3) are reserved for this purpose. If those specifications use names other than those mentioned above, it is RECOMMENDED that extension-tokens be used to avoid any parameter-name conflicts with future extensions to this protocol.
定义认证算法的规范可以使用参数“kc1”、“ks1”、“vkc”和“vks”的其他表示；替换这些参数名称；和/或在补充规范中包含这些参数的消息中添加参数，前提是满足本文件第3节[RFC7230]和[RFC7235]中的语法和语义要求。任何以“kc”、“ks”、“vkc”或“vks”开头并后跟十进制自然数（例如kc2、ks0、vkc1、vks3）的参数都保留用于此目的。如果这些规范使用上述以外的名称，建议使用扩展令牌，以避免任何参数名称与该协议的未来扩展冲突。
Extension-tokens MAY be freely used for any non-standard, private, and/or experimental uses for those parameters provided that the domain part in the token is used in the manner defined in Section 3.
扩展令牌可自由用于这些参数的任何非标准、私有和/或实验用途，前提是令牌中的域部分以第3节中定义的方式使用。
IANA has added the following entry to the "HTTP Authentication Schemes" registry:
IANA已将以下条目添加到“HTTP身份验证方案”注册表中：
o Authentication Scheme Name: Mutual
o 身份验证方案名称：Mutual
o Reference: RFC 8120
o 参考：RFC 8120
This document establishes the "HTTP Mutual Authentication Algorithms" registry. The registry manages case-insensitive ASCII strings. The strings MUST follow the extensive-token syntax defined in Section 3.
本文档建立了“HTTP相互认证算法”注册表。注册表管理不区分大小写的ASCII字符串。字符串必须遵循第3节中定义的扩展标记语法。
When bare-tokens are used for the authentication-algorithm parameter, they MUST be allocated by IANA. To acquire registered tokens, the usage of such tokens MUST be reviewed by a Designated Expert, as outlined in [RFC5226].
当身份验证算法参数使用裸令牌时，它们必须由IANA分配。如[RFC5226]所述，要获得注册代币，必须由指定专家审查此类代币的使用情况。
Registrations for an authentication algorithm are required to include descriptions of the authentication algorithms. Reviewers assigned by the IESG are advised to examine minimum security requirements and consistency of the key exchange algorithm descriptions.
认证算法的注册需要包括认证算法的描述。建议IESG指派的审查人员检查最低安全要求和密钥交换算法描述的一致性。
It is advised that new registrations provide the following information:
建议新注册提供以下信息：
o Token: A token used in HTTP headers for identifying the algorithm.
o 令牌：HTTP头中用于标识算法的令牌。
o Description: A brief description of the algorithm.
o 描述：算法的简要描述。
o Specification: A reference for a specification defining the algorithm.
o 规范：定义算法的规范的参考。
[RFC8121] defines the initial contents of this registry.
[RFC8121]定义此注册表的初始内容。
This document establishes the "HTTP Mutual Authentication Host Validation Methods" registry. The registry manages case-insensitive ASCII strings. The strings MUST follow the extensive-token syntax defined in Section 3.
本文档建立了“HTTP相互认证主机验证方法”注册表。注册表管理不区分大小写的ASCII字符串。字符串必须遵循第3节中定义的扩展标记语法。
When bare-tokens are used for the validation parameter, they MUST be allocated by IANA. To acquire registered tokens, the usage of such tokens MUST be reviewed by a Designated Expert, as outlined in [RFC5226].
当裸令牌用于验证参数时，它们必须由IANA分配。如[RFC5226]所述，要获得注册代币，必须由指定专家审查此类代币的使用情况。
Registrations for a validation method are required to include a description of the validation method. Reviewers assigned by the IESG are advised to examine its use-case requirements and any security consequences related to its introduction.
验证方法的注册必须包括验证方法的说明。建议IESG指派的评审员检查其用例需求以及与引入相关的任何安全后果。
It is advised that new registrations provide the following information:
建议新注册提供以下信息：
o Token: A token used in HTTP headers for identifying the method.
o 令牌：HTTP头中用于标识方法的令牌。
o Description: A brief description of the method.
o 描述：方法的简要描述。
o Specification: A reference for a specification defining the method.
o 规范：定义方法的规范的参考。
The initial contents of this registry are as follows:
本登记册的初始内容如下：
+----------------------+------------------------+----------------+
| Token | Description | Reference |
+----------------------+------------------------+----------------+
| host | Hostname verification | RFC 8120, |
| | only | Section 7 |
| | | |
| tls-server-end-point | TLS certificate-based | RFC 8120, |
| | | Section 7 |
| | | |
| tls-unique | TLS unique key-based | RFC 8120, |
| | | Section 7 |
+----------------------+------------------------+----------------+
+----------------------+------------------------+----------------+
| Token | Description | Reference |
+----------------------+------------------------+----------------+
| host | Hostname verification | RFC 8120, |
| | only | Section 7 |
| | | |
| tls-server-end-point | TLS certificate-based | RFC 8120, |
| | | Section 7 |
| | | |
| tls-unique | TLS unique key-based | RFC 8120, |
| | | Section 7 |
+----------------------+------------------------+----------------+
o The protocol is secure against passive eavesdropping and replay attacks. However, the protocol relies on transport security (including DNS integrity) for data secrecy and integrity. HTTP/TLS SHOULD be used where transport security is not assured and/or data confidentiality is important.
o 该协议对被动窃听和重放攻击是安全的。然而，该协议依赖于传输安全性（包括DNS完整性）来实现数据保密性和完整性。HTTP/TLS应在传输安全性未得到保证和/或数据保密性很重要的情况下使用。
o When used with HTTP/TLS, if TLS server certificates are reliably verified, the protocol provides true protection against active man-in-the-middle attacks.
o 当与HTTP/TLS一起使用时，如果TLS服务器证书得到可靠验证，则该协议可针对主动中间人攻击提供真正的保护。
o Even if the server certificate is not used or is unreliable, the protocol provides protection against active man-in-the-middle attacks for each HTTP request/response pair. However, in such cases, JavaScript or similar scripts that are not authenticated by this authentication mechanism can affect mutually authenticated contents to circumvent the protection. This is why this protocol stipulates that valid TLS server certificates MUST be shown from the server to the client (Section 7).
o 即使服务器证书未被使用或不可靠，该协议也为每个HTTP请求/响应对提供了针对主动中间人攻击的保护。但是，在这种情况下，未通过此身份验证机制进行身份验证的JavaScript或类似脚本可能会影响相互身份验证的内容以规避保护。这就是为什么该协议规定必须从服务器向客户端显示有效的TLS服务器证书（第7节）。
The client-side password credential MUST always be kept secret and SHOULD NOT be used for any other (possibly insecure) authentication purposes. Loss of control of the credential will directly affect the control of the corresponding server-side account.
客户端密码凭据必须始终保密，不应用于任何其他（可能不安全的）身份验证目的。失去对凭据的控制将直接影响对相应服务器端帐户的控制。
The use of a client-side credential with THIS authentication scheme is always safe, even if the connected server peer is not trustworthy (e.g., a phishing scenario). However, if it is used with other authentication schemes (such as Web forms) and the recipient is rogue, the result will be obvious.
使用此身份验证方案的客户端凭据始终是安全的，即使连接的服务器对等方不可信（例如，网络钓鱼场景）。但是，如果它与其他身份验证方案（如Web表单）一起使用，并且收件人是恶意的，那么结果将是显而易见的。
It is also important that the server-side password credential (J) be kept secret. If it is stolen and the client's choice of password is not strong, anyone who is aware of the server-side password credential can employ an offline dictionary attack to search for the client's password. However, if the client has chosen a strong password so that an attacker cannot guess the client's password from dictionary candidates, the client is still well protected from any attacks.
服务器端密码凭证（J）必须保密，这一点也很重要。如果密码被盗且客户端对密码的选择不强，任何知道服务器端密码凭据的人都可以使用脱机字典攻击来搜索客户端密码。但是，如果客户端选择了强密码，使得攻击者无法从候选字典中猜出客户端的密码，则客户端仍然可以很好地抵御任何攻击。
The shared session secret (z) MUST be kept secret inside the server/client software; if it is lost and the session is still active, session hijacking will result. After the session expires, the key is of no value to attackers.
共享会话机密（z）必须在服务器/客户端软件内保密；如果它丢失并且会话仍然处于活动状态，则会导致会话劫持。会话过期后，该密钥对攻击者没有任何价值。
The protocol requires a server-side table of active sessions, which may become a critical point for server resource consumption. For proper operation, the protocol requires that at least one key verification request be processed for each session identifier. After that, servers MAY discard sessions internally at any time without causing any operational problems for clients. Clients will then silently re-establish a new session.
该协议需要活动会话的服务器端表，这可能成为服务器资源消耗的关键点。为了正确操作，协议要求为每个会话标识符至少处理一个密钥验证请求。之后，服务器可以随时在内部丢弃会话，而不会给客户端造成任何操作问题。然后，客户端将以静默方式重新建立一个新会话。
However, if a malicious client sends too many requests for key exchanges (req-KEX-C1 messages) only, resource starvation might occur. In such critical situations, servers MAY discard any kind of existing sessions, regardless of their statuses. One way to mitigate such attacks is that servers MAY set number and time limits for unverified, pending key exchange requests (in the "key exchanging" state).
但是，如果恶意客户端仅发送过多的密钥交换请求（req-KEX-C1消息），则可能会发生资源不足。在这种危急情况下，服务器可能会丢弃任何类型的现有会话，而不管其状态如何。减轻此类攻击的一种方法是，服务器可以为未经验证的挂起密钥交换请求（处于“密钥交换”状态）设置数量和时间限制。
This is a common weakness of authentication protocols with almost any kind of negotiations or states, including the Digest authentication scheme and most cookie-based authentication implementations. However, regarding resource consumption, the situation for the Mutual authentication scheme is slightly better than that for Digest, because HTTP requests without any kind of authentication requests will not generate any kind of sessions. Session identifiers are only generated after a client starts a key negotiation, so that simple clients such as Web crawlers will not accidentally consume server-side resources for session management.
这是具有几乎任何类型的协商或状态的身份验证协议的一个常见弱点，包括摘要身份验证方案和大多数基于cookie的身份验证实现。然而，关于资源消耗，相互认证方案的情况略好于摘要方案，因为没有任何类型的认证请求的HTTP请求将不会生成任何类型的会话。会话标识符仅在客户端启动密钥协商后生成，这样简单的客户端（如Web爬虫）就不会意外地使用服务器端资源进行会话管理。
Although the protocol provides very strong protection against offline dictionary attacks from eavesdropped traffic, the protocol, by its nature, cannot prevent active password attacks in which an attacker sends so many authentication trial requests for every possible password.
尽管该协议提供了非常强大的保护，以抵御来自被窃听流量的脱机字典攻击，但该协议本身无法防止主动密码攻击，在主动密码攻击中，攻击者为每个可能的密码发送如此多的身份验证试验请求。
Possible countermeasures for preventing such attacks may be the rate-limiting of password authentication trials, statistics-based intrusion-detection measures, or similar protection schemes. If the server operators assume that the passwords of users are not strong enough, it may be desirable to introduce such ad hoc countermeasures.
防止此类攻击的可能对策可能是限制密码验证试验的速率、基于统计的入侵检测措施或类似的保护方案。如果服务器操作员认为用户的密码不够强，则可能需要引入此类临时对策。
This protocol is designed with two goals in mind. The first goal is simply to provide a secure alternative to existing Basic and Digest authentication schemes. The second goal is to provide users with a way to detect forged rogue servers imitating (e.g., via a phishing attack) a user's registered account on a server.
本协议的设计有两个目标。第一个目标只是提供现有基本和摘要身份验证方案的安全替代方案。第二个目标是为用户提供一种检测伪造流氓服务器的方法，该服务器模仿（例如，通过网络钓鱼攻击）用户在服务器上注册的帐户。
For this protocol to effectively work as a countermeasure against such attacks, it is very important that end users of clients be notified of the result of mutual authentication performed by this protocol, especially the three states "AUTH-SUCCEED", "AUTH-REQUIRED", and "UNAUTHENTICATED" as defined in Section 10. The design of secure user interfaces for HTTP interactive clients is out of scope for this document, but if possible, having some kind of UI indication for the three states above will be desirable from the standpoint of providing user security.
为了使本协议有效地作为对抗此类攻击的对策，将本协议执行的相互认证结果通知客户端的最终用户非常重要，特别是第10节中定义的三种状态“AUTH-success”、“AUTH-REQUIRED”和“UNAUTHENTICATED”。HTTP交互客户端的安全用户界面设计超出了本文档的范围，但如果可能，从提供用户安全的角度来看，需要对上述三种状态进行某种UI指示。
Of course, in such cases, the user interfaces for requesting passwords for this authentication shall be protected against imitation (for example, by other insecure password input fields, such as forms). If the passwords are known to malicious attackers outside of the protocol, the protocol cannot work as an effective security measure.
当然，在这种情况下，用于请求此身份验证密码的用户界面应受到保护，以防仿制（例如，通过其他不安全的密码输入字段，如表单）。如果协议之外的恶意攻击者知道密码，则协议无法作为有效的安全措施。
o To securely implement the protocol, the Authentication-Info headers in the 200-VFY-S messages MUST always be validated by the client. If the validation fails, the client MUST NOT process any content sent with the message, including other headers and the body part. Non-compliance with this requirement will allow phishing attacks.
o 为了安全地实现协议，200-VFY-S消息中的身份验证信息头必须始终由客户端验证。如果验证失败，客户端不得处理随消息发送的任何内容，包括其他标题和正文部分。不遵守此要求将允许网络钓鱼攻击。
o For HTTP/TLS communications, when a Web form is submitted from mutually authenticated pages via the "tls-server-end-point" validation method to a URI that is protected by the same realm (so indicated by the "path" parameter), if the server certificate has been changed since the pages were received, it is RECOMMENDED that the peer be revalidated using a req-KEX-C1 message with an "Expect: 100-continue" header. The same applies when the page is received via the "tls-unique" validation method and when the TLS session has expired.
o 对于HTTP/TLS通信，当通过“TLS服务器端点”验证方法从相互认证的页面向受同一领域保护的URI提交Web表单时（如“path”参数所示），如果自收到页面后服务器证书已更改，建议使用带有“Expect:100 continue”标头的req-KEX-C1消息重新验证对等机。当通过“tls唯一”验证方法接收页面时，以及当tls会话已过期时，同样适用。
o For better protection against possible password database stealing, server-side storage of user passwords should contain the values encrypted by the one-way function J(pi) instead of the real passwords or those hashed by pi.
o 为了更好地防止可能的密码数据库窃取，用户密码的服务器端存储应该包含由单向函数J（pi）加密的值，而不是真实密码或由pi散列的值。
o If TLS 1.2 [RFC5246] is used for underlying HTTP/TLS communications, follow the best practices specified in [RFC7525].
o 如果TLS 1.2[RFC5246]用于底层HTTP/TLS通信，请遵循[RFC7525]中指定的最佳实践。
o The usernames inputted by a user may be sent automatically to any servers sharing the same auth-scope. This means that when a host-type auth-scope is used for authentication on an HTTPS site and an HTTP server on the same host requests the Mutual authentication scheme within the same realm, the client will send the username in clear text. If usernames have to be kept secret (protected from eavesdroppers), the server must use the full-scheme-type "auth-scope" parameter and HTTPS. Passwords, on the other hand, are not exposed to eavesdroppers, even in HTTP requests.
o 用户输入的用户名可以自动发送到共享相同身份验证范围的任何服务器。这意味着，当主机类型的身份验证作用域用于HTTPS站点上的身份验证，并且同一主机上的HTTP服务器请求同一领域内的相互身份验证方案时，客户端将以明文形式发送用户名。如果用户名必须保密（防止被窃听），服务器必须使用完整的方案类型“auth scope”参数和HTTPS。另一方面，即使在HTTP请求中，密码也不会暴露给窃听者。
o If the server provides several ways to store server-side password secrets in the password database, it is desirable, for purposes of better security, to store the values encrypted by using the one-way function J(pi) instead of the real passwords or those hashed by pi.
o 如果服务器提供了几种在密码数据库中存储服务器端密码机密的方法，则为了更好的安全性，希望存储通过使用单向函数J（pi）而不是真实密码或pi散列的密码加密的值。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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>.
[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>.
[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>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, <http://www.rfc-editor.org/info/rfc8018>.
[RFC8018]Moriarty，K.，Ed.，Kaliski，B.，和A.Rusch，“PKCS#5：基于密码的加密规范版本2.1”，RFC 8018，DOI 10.17487/RFC8018，2017年1月<http://www.rfc-editor.org/info/rfc8018>.
[RFC8053] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "HTTP Authentication Extensions for Interactive Clients", RFC 8053, DOI 10.17487/RFC8053, January 2017, <http://www.rfc-editor.org/info/rfc8053>.
[RFC8053]Oiwa，Y.，Watanabe，H.，Takagi，H.，Maeda，K.，Hayashi，T.，和Y.Ioku，“交互式客户端的HTTP身份验证扩展”，RFC 8053，DOI 10.17487/RFC8053，2017年1月<http://www.rfc-editor.org/info/rfc8053>.
[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode]Unicode联盟，“Unicode标准”<http://www.unicode.org/versions/latest/>.
[ITU.X690.2015] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/>.
[ITU.X690.2015]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-12015年8月<https://www.itu.int/rec/T-REC-X.690/>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <http://www.rfc-editor.org/info/rfc1939>.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，DOI 10.17487/RFC1939，1996年5月<http://www.rfc-editor.org/info/rfc1939>.
[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>.
[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>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, <http://www.rfc-editor.org/info/rfc5929>.
[RFC5929]Altman，J.，Williams，N.和L.Zhu，“TLS的通道绑定”，RFC 5929，DOI 10.17487/RFC5929，2010年7月<http://www.rfc-editor.org/info/rfc5929>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[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>.
[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>.
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, <http://www.rfc-editor.org/info/rfc7486>.
[RFC7486]Farrell，S.，Hoffman，P.和M.Thomas，“HTTP源绑定身份验证（HOBA）”，RFC 7486，DOI 10.17487/RFC7486，2015年3月<http://www.rfc-editor.org/info/rfc7486>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<http://www.rfc-editor.org/info/rfc7616>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <http://www.rfc-editor.org/info/rfc7627>.
[RFC7627]Bhargavan，K.，Ed.，Delignat Lavaud，A.，Pironti，A.，Langley，A.，和M.Ray，“传输层安全（TLS）会话哈希和扩展主秘密扩展”，RFC 7627，DOI 10.17487/RFC7627，2015年9月<http://www.rfc-editor.org/info/rfc7627>.
[RFC8121] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)", RFC 8121, DOI 10.17487/RFC8121, April 2017, <http://www.rfc-editor.org/info/rfc8121>.
[RFC8121]Oiwa，Y.，Watanabe，H.，Takagi，H.，Maeda，K.，Hayashi，T.，和Y.Ioku，“HTTP的相互认证协议：基于密钥协商机制3（KAM3）的加密算法”，RFC 8121，DOI 10.17487/RFC8121，2017年4月<http://www.rfc-editor.org/info/rfc8121>.
Authors' Addresses
作者地址
Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: y.oiwa@aist.go.jp
Yutaka Oiwa国家高级工业科学和技术研究所信息技术研究所筑波中心1 1-1-1日本茨城梅佐诺筑波市电子邮件：y。oiwa@aist.go.jp
Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: h-watanabe@aist.go.jp
渡边哈吉国家高级工业科学技术研究所信息技术研究所筑波中心1 1-1-1日本茨城市梅佐诺筑波市电子邮件：h-watanabe@aist.go.jp
Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: takagi.hiromitsu@aist.go.jp
Hiromitsu Takagi国家先进工业科学技术研究所信息技术研究所Tsukuba Central 1-1-1 Umezono Tsukuba shi，茨城日本电子邮件：Takagi。hiromitsu@aist.go.jp
Kaoru Maeda Individual Contributor Email: kaorumaeda.ml@gmail.com
Kaoru Maeda个人撰稿人电子邮件：kaorumaeda。ml@gmail.com
Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo Japan Email: hayashi@lepidum.co.jp
Tatsuya Hayashi Lepidum有限公司位于日本东京涩谷佐佐助村3号602室1-30-3电子邮件：hayashi@lepidum.co.jp
Yuichi Ioku Individual Contributor Email: mutual-work@ioku.org
Ioku Yuichi个人投稿人电子邮件：相互-work@ioku.org