[要約] RFC 8120は、HTTPの相互認証プロトコルに関する要約であり、セキュアな通信を確保するためにクライアントとサーバー間で相互認証を行う方法を提案しています。目的は、通信の安全性を向上させ、不正アクセスやデータの改ざんを防ぐことです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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システムにとって最も重要な脅威の1つです。プレーンテキストのパスワード認証技術（基本認証と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 computers reduces the effectiveness of users' memorable passwords, thereby threatening the effectiveness of such hash-based password protections.
ダイジェスト認証スキーム[RFC7616]は、SHA-256およびSHA-512 / 256（以前のSHA-1およびMD5）ハッシュアルゴリズムを使用して、生のユーザーパスワードをネットワークスニファから隠します。ただし、考えられる候補ユーザーのパスワードの数が十分でない場合、より強力な新しいコンピューターが数十億のパスワード候補の考えられるハッシュ値を計算し、これらをスニッフィングされた値と比較して正しいパスワードを見つけることができます。この種の攻撃は、オフラインパスワード辞書攻撃と呼ばれます。これらの新しいコンピューターの検索容量は、ユーザーの覚えやすいパスワードの有効性を低下させるため、ハッシュベースのパスワード保護の有効性が脅かされます。
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サイト」にルーティングされ、そのサイトで認証を実行するようにだまされた場合、資格情報は攻撃者のサーバーに送信され、簡単にリークされます。フィッシングなどの攻撃は深刻な脅威になっています。現在のWebシステムの展開では、TLS証明書はインターネットのほとんどすべてのユーザー（悪意のある攻撃者を含む）に発行されます。これらの証明書には、発行されたエンティティの「検証結果」（会社名など）のいくつかのレベルが含まれていますが、これらの検証結果を「確認」するタスクは、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.
このような脅威を回避するもう1つの方法は、パスワードベースの認証を回避し、認証に（クライアント側またはサーバー側のいずれかで）事前にデプロイされたある種の強力な秘密鍵を使用することです。いくつかのフェデレーション認証フレームワーク、およびHTTP Origin-Bound Authentication（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:
このドキュメントで提案されている相互認証プロトコルは、パスワード認証のための強力な暗号化ソリューションです。主に次の2つの主要な機能を提供します。
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 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.
o認証に成功するには、サーバーだけでなくクライアントユーザーも、有効な登録済み資格情報（認証シークレット）を所有している必要があります。これは、フィッシング攻撃者がユーザーをだまして「本物」のサーバーであると思わせることができないことを意味します。 （これは、基本認証とダイジェスト認証には当てはまらないことに注意してください。たとえば、基本認証を使用するサーバーは、実際に認証をまったく確認せずに、すべてのクライアントに対して「はい」と応答できます。）クライアントユーザーは、通信するピアがいるかどうかを確認できます。本当に事前にアカウントを登録した「サーバー」です。つまり、サーバーとクライアント間の「真の」相互認証を提供します。
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ブラウザーに認証結果を表示する「安全な」方法があることを示唆しています。将来のブラウザーでこのようなユーザーインターフェイスを使用すると、Extended Validation 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で使用するための一般的なフレームワークです。上記の2つの主要な機能は、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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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)).
このドキュメントでは、ハッシュ関数の入力（ドメイン）と出力（コドメイン）の両方をオクテット文字列として扱います。ハッシュ関数の自然数出力が必要な場合、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:
さらに、この仕様に関連する次の2つの関連ドキュメントを参照します。
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]は、既存のWebシステムのアプリケーションレベルのセマンティクスをサポートできるように、現在のHTTP認証フレームワークに小さいながらも有用な拡張機能を定義しています。
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.
認証プロトコルは、相互認証を実行するために6種類のメッセージを使用します。これらのメッセージには、この仕様内で特定の名前があります。
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メッセージ：クライアントが新しい鍵交換を開始する必要があることを示すメッセージ。
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.
上記の6種類のメッセージに加えて、この仕様に関連する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
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応答に含まれる本文またはヘッダーの値を処理してはなりません（MUST NOT）。 （注：このケースは、適切に実装されたサーバーとクライアントの間でアクティブな攻撃が発生しないようにする必要があります。このようなシナリオは、中間者攻撃または不適切な実装が原因である可能性があります。）
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.
上記のように、最初の認証要求の一般的なフローには、3つの要求と応答のペアが必要です。プロトコルのオーバーヘッドを削減するために、プロトコルは、より少ないメッセージを必要とするいくつかのショートカットフローを有効にします。
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）メッセージを送信できます（MAY）。これにより、往復回数が1つ減ります。
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メッセージを直接送信できます（MAY）。これにより、往復回数がさらに1つ減少します。
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は、上記のショートカットフローを示しています。適切な設定と実装を使用する場合、リソースへのリクエストのほとんどは両方の基準を満たすことが期待されます。したがって、要求/応答のラウンドトリップは1つだけ必要になります。
Case A: Omit first request (2 round trips)
ケースA：最初のリクエストを省略（往復2回）
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 --- |
| |
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]ごとに次の要素が使用されています：DIGIT、ALPHA、SP、auth-scheme、quoted-string、auth-param、header-field、token、challenge、credentials 。
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.
相互認証プロトコルは3つのヘッダーを使用します：WWW-Authenticate（通常は401ステータスコードの応答）、Authorization（リクエスト）、および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要素を「相互」に設定する必要があります。 「相互」認証-スキームで使用される「チャレンジ」と「資格情報」の構文は、[RFC7235]で定義されている「token68」パラメータではなく、名前と値のペア（＃auth-param）である必要があります。
The Authentication-Info header used in this protocol SHALL follow the syntax defined in [RFC7615].
このプロトコルで使用されるAuthentication-Infoヘッダーは、[RFC7615]で定義された構文に従う必要があります（SHALL）。
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-Authenticateヘッダーに2つ以上のチャレンジが含まれる場合があります。クライアントの実装は、これらのケースを認識し、正しく処理できる必要があります（SHOULD）。
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].
「レルム」フィールドを除いて、上記の3つのヘッダーに含まれるすべてのパラメーターは、[RFC5987]で説明されているフレームワークを使用してISO 10646-1値に拡張できます（MAY）。すべてのサーバーとクライアントは、[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 value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the syntax used.
値（「レルム」ヘッダーを除く）に1つ以上の非ASCII文字が含まれている場合、[RFC5987]のセクション3.2で定義されている構文を使用して、パラメータを「ext-parameter」として送信する必要があります（SHOULD）。そのようなパラメーターは「UTF-8」の文字セット値を持たなければならず（MUST）、言語値は常に省略されなければなりません（空の値を持っています）。使用される構文に関係なく、同じパラメーターを複数回送信してはなりません（MUST NOT）。
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.
たとえば、値が「Renee of France」のパラメータ「user」は、<user = "Renee of France">として送信する必要があります。値が「Ren <e急性> 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]では、「レルム」パラメーターが（拡張「レルム*」パラメーターとしてではなく）プレーンな形式である必要があるため、RFC 5987で指定されている構文をこのパラメーターに使用してはなりません（MUST NOT）。
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セマンティクスに厳密に準拠して解析する必要があります（特に、文字列パラメーター値の引用符を外す）。このプロトコルでは、これらの値は、トークン（ベアトークンと拡張トークン）、文字列、整数、hex-fixed-number、およびbase64-fixed-numberの値タイプにさらに分類されます。
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
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.
トークン（ベアトークンと拡張トークン）は大文字と小文字を区別しません。送信者はこれらを小文字で送信する必要があり（SHOULD）、受信者は大文字と小文字の両方を受け入れる必要があります。トークンがハッシュ関数または他の数学関数への（部分的な）入力として使用される場合、それらは常に小文字で使用されなければなりません（MUST）。
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で説明されている手順を参照）または "-<bare-token>。<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）（ZERO WIDTH NO-BREAK SPACE、U + FEFF、EF BB BFとも呼ばれます）を含めてはなりません（MUST NOT）。両方のピアが、デコードのあいまいさを引き起こす可能性がある無効なUTF-8シーケンスを拒否することをお勧めします（たとえば、UTF-8エンコード文字の2番目以降のバイトに<">が含まれている）。
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プロトコルレイヤーで（たとえば、Host：ヘッダーで）使用されるときにエンコードする必要があります（SHOULD）。現在の規格では、[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"="
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.
hex-fixed-numberとして表される数値には、偶数の16進数字（つまり、8ビットの倍数）を含める必要があります。これらの値は大文字と小文字を区別せず、小文字で送信する必要があります。これらの値が暗号値から生成される場合、それらは「自然な長さ」を持つ必要があります。それらがハッシュ関数から生成される場合、それらの長さはハッシュサイズに対応します。それらが数学的セット（またはグループ）の要素を表す場合、それらの長さは、セット内のすべての要素を表す最短の長さである必要があります（SHALL）。たとえば、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.
整数および16進数の固定番号の標準形式は引用符で囲まれていないトークンであり、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.
このセクションでは、認証プロトコルで6種類のメッセージを定義し、各タイプのメッセージのヘッダーの形式と要件を示します。
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で定義されたタイプの1つであり、
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.
「アルゴリズム」パラメータの値によって決定されます。 「必須」とマークされたパラメータは、メッセージに含まれる必要があります。 「非必須」とマークされたパラメータは、メッセージに含まれるか、メッセージから省略される場合があります。各パラメーターは、各ヘッダーに最大で1回だけ表示する必要があります（SHALL）。
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:
すべての資格情報とチャレンジには、以下のセクションで明示的に指定されていないパラメーターが含まれる場合があります。そのようなパラメータを理解しない受信者は、それらを黙って無視しなければなりません（MUST）。ただし、すべての資格情報とチャレンジは、次の基準を満たしている必要があります。
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＃"（ "＃"は任意の10進整数を表す）、および "vks"は相互に排他的です。チャレンジには、2つ以上のパラメーターを含めることはできません。 「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＃」（「＃」は任意の10進整数を表す）と「vkc」は相互に排他的です。チャレンジには、2つ以上のパラメーターを含めることはできません。 「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ヘッダーが1つだけ含まれますチャレンジのパラメータ。チャレンジには、以下の「必須」とマークされたすべてのパラメーターが含まれている必要があり（SHALL）、「非必須」とマークされているパラメーターが含まれている場合があります（MAY）。
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]で指定されたトークンの1つまたは別の補足仕様でなければなりません。
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.
validation：（必須の広範なトークン）ホストの検証方法を指定します。値は、セクション7で説明されているトークンの1つ、または別の補足仕様で指定されているトークンでなければなりません。
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で説明されている文字列の1つである必要があります。値が省略された場合、セクション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.
レルム：（必須の文字列）は、認証スコープ内の認証レルムの名前を表す文字列です。 [RFC7235]で指定されているように、この値は常に引用文字列形式で送信する必要があり、[RFC5987]で指定されているエンコーディングを使用してはなりません（MUST NOT）。
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文字列である必要があります（SHOULD）。クライアントは、このフィールドで受け取った非ASCII値をバイナリBLOB、NFC正規化UTF-8文字列（「NFC」は「正規化フォームC」を表す）、またはエラーとして処理できます（MAY）。
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:
reason：（必須の広範なトークン）SHALLは、失敗した認証または許可の考えられる理由を説明する広範なトークンである必要があります。サーバーとクライアントの両方が、次の3つのトークンを理解してサポートする必要があります。
* initial: Authentication was not attempted because there was no Authorization header in the corresponding request.
* initial：対応するリクエストにAuthorizationヘッダーがなかったため、認証は試行されませんでした。
* stale-session: The provided sid in the request was either unknown to the server or expired in the server.
* stale-session：リクエストで提供されたsidはサーバーに認識されていないか、サーバーで有効期限が切れています。
* auth-failed: The authentication trial failed for some reason, possibly because of a bad authentication credential.
* auth-failed：何らかの理由で認証試行が失敗しました。認証資格情報が無効である可能性があります。
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".
実装は、以下のトークン、またはこの仕様の外で定義された拡張トークンをサポートしてもよい（MAY）。クライアントが未知のトークンを受け取った場合、それらは「認証失敗」または「初期」であるかのようにそれらを扱うべきです（SHOULD）。
* reauth-needed: The server-side application requires a new authentication trial, regardless of the current status.
* reauth-needed：現在のステータスに関係なく、サーバー側アプリケーションには新しい認証トライアルが必要です。
* invalid-parameters: The server did not attempt authentication because some parameters were not acceptable.
* invalid-parameters：一部のパラメーターが受け入れられなかったため、サーバーは認証を試みませんでした。
* internal-error: The server did not attempt authentication because there are some problems on the server side.
* internal-error：サーバー側に問題があるため、サーバーは認証を試みませんでした。
* 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.
* user-unknown：これは、auth-failedの特殊なケースです。指定されたユーザー名が無効であることを示しています。セキュリティ上の理由から、このパラメーターの使用は、意味のある特殊用途のアプリケーションを除いて、推奨されません。
* 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.
* invalid-credential：これは、auth-failedのもう1つの特殊なケースです。提供されたユーザー名は有効でしたが、認証に失敗したことを示しています。セキュリティ上の理由から、このパラメーターの使用はお勧めしません。
* 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-failed：認証は成功しましたが、指定されたリソースへのアクセスは特定の認証されたユーザーに許可されていません。 （これは、401（Unauthorized）または403（Forbidden）のいずれかのステータスコードとともに使用され、認証結果が認証失敗の既存の理由の1つであることを示します。
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メッセージは、「kc1」パラメーターを含む資格情報を持つAuthorizationヘッダーを含む有効なHTTP要求メッセージである必要があります（SHALL）。
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.
algorithm、validation、auth-scope、realm：サーバーから受信したものと同じ値でなければなりません。
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メッセージは、「ks1」パラメーターを含むチャレンジを持つWWW-Authenticateヘッダーを含む有効なHTTP 401（無許可）ステータス応答メッセージである必要があります（SHALL）。
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.
algorithm、validation、auth-scope、realm：クライアントから受信したものと同じ値でなければなりません。
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：（必須、16進固定番号）は、ランダムな整数であるセッション識別子である必要があります。 sidは、少なくとも80ビットの一意性、またはセッションテーブルで同時に利用可能な推定トランザクションの最大値の2乗のいずれか大きい方の一意性を持つ必要があります（SHOULD）。詳細については、セクション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：（必須、整数）は、サーバーが受け入れるノンス数の最大値です。
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：（必須、整数）は、サーバーが受け入れる利用可能なナンス番号スロットの数です。 「nc-window」パラメータの値は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」パラメータに含まれるすべてのパス要素は、指定されたauth-scope内にある必要があります。そうでない場合、クライアントはそのような要素を無視する必要があります。パフォーマンスを向上させるには、クライアントがこのパラメーターを認識して使用することが重要です。
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メッセージは、「vkc」パラメーターを含む資格情報を持つAuthorizationヘッダーを含む有効なHTTP要求メッセージである必要があります（SHALL）。
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.
algorithm、validation、auth-scope、realm：セッションのサーバーから受信したものと同じ値である必要があります。
sid: (mandatory, hex-fixed-number) MUST be one of the sid values that was received from the server for the same authentication realm.
sid：（必須、hex-fixed-number）は、同じ認証レルムについてサーバーから受信したsid値の1つである必要があります。
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：（必須、整数）は、同じsidを共有するリクエスト間で一意のnonceリクエスト番号です。 nonce番号の値は、セクション6で概説されているプロパティを満たす必要があります（SHOULD）。
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メッセージは、401（無許可）ステータスコードを持たない有効なHTTPメッセージである必要があり（SHALL）、「vks」パラメーターを持つAuthentication-Infoヘッダーが含まれている必要があります（SHALL）。
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：（必須、16進固定番号）は、クライアントから受信した値である必要があります。
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（Continue）」[RFC7231]応答がサーバーから送信される場合、Authentication-Infoヘッダーは、最終応答の代わりにその応答に含まれる必要があります（SHOULD）。
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）のセットとして定義されます。サーバーが、クライアントがすでに認証されている認証レルムの認証を要求すると、クライアントは既知の資格情報を使用して自動的に認証を実行します。ただし、異なる認証レルムの場合、クライアントは別のレルムのユーザー名とパスワードを自動的に再利用してはなりません（MUST NOT）。
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.
基本およびダイジェストアクセス認証プロトコルの場合と同様に、相互認証プロトコルは、各ホスト内に設定される複数の個別の保護スペースをサポートします。さらに、このプロトコルにより、単一の認証領域が同じインターネットドメイン内の複数のホストにまたがることができます。
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.
各認証レルムは、認証アルゴリズム、認証スコープ、および「レルム」パラメーターの3つの要素によって定義および識別されます。ただし、サーバーオペレーターが認証スコープとレルムの同じペアを異なる認証アルゴリズムで使用することはお勧めしません。
The "realm" parameter is a string as defined in Section 4. Authentication scopes are described in the remainder of this section.
「レルム」パラメータは、セクション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」に対して有効です。サーバーから送信されるドメイン後置文字列は、特定の組織に割り当てられた有効なインターネットドメインと同じか、含まれている必要があります。 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プロトコルで送信される方法で表す必要があります。つまり、これらのドメイン名は、アプリケーションの国際化ドメイン名（IDNA）仕様[RFC5890]で定義されているLDH（「文字、数字、ハイフン」）ラベルの形式である必要があります。 「ポート」は、最短の符号なし10進数表記で指定する必要があります。これらの要件に従わないと、有効な認証試行が失敗します。
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:
次の手順は、このような場合のあいまいさを解決するための1つの可能な戦略です。
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 他の場合では、最も具体的な認証スコープを表す認証レルムの1つを使用します。上記の可能なドメイン仕様のリストは、最も具体的なものから最も具体的でないものまであります。
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 同じ認証スコープのレルムがある場合、定義された優先順位はありません。クライアントは、可能な選択肢のいずれかを選択してもよい（MAY）。
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.
相互認証プロトコルでは、sidで表されるセッションは4つのメッセージ（最初の要求、401-INIT、req-KEX-C1、および401-KEX-S1）を使用してセットアップされ、その後に関連付けられたセッションシークレット（z）がセッションが確立されます。セッションのシークレットを相互に確立した後、このセッションをシークレットとともに使用して、同じサーバー上の同じレルムによって保護されているリソースに対する1つ以上の要求に使用できます。セッション管理はプロトコルの内部の詳細にすぎず、通常のユーザーには見えないことに注意してください。セッションの有効期限が切れた場合、クライアントとサーバーはユーザーに通知することなく自動的に別のセッションを再確立する必要があります（SHOULD）。
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.
認証スコープが複数のサーバーをカバーしている場合でも、セッションとセッション識別子は各サーバーに対してローカルです（スキーム、ホスト、ポートによって定義されます）。クライアントは、アクセスされるホストのポートごとに個別のセッションを確立する必要があります。さらに、セッションと識別子は、同じサーバーから提供されている場合でも、各認証レルムに対してローカルです。異なるサーバーまたは異なるレルムから提供された同じセッション識別子は、互いに独立しているものとして扱われなければなりません（MUST）。
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メッセージの「timeout」パラメーターで指定された時間枠内にサーバーに到達し、緊急の理由がない場合（そのような場合）、サーバーは各セッションで少なくとも1つのreq-VFY-C要求を受け入れる必要があります（SHOULD）。フラッディング攻撃として）セッションを忘れます。その後、サーバーは任意のセッションをいつでも破棄でき、そのセッションで受信したそれ以降のreq-VFY-C要求については、401-STALEメッセージを送信できます（MAY）。
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で指定された単一のセッションを使用して2つ以上のリクエストを送信できます（MAY）。ただし、そのようなすべてのリクエストでは、ナンス番号の各値（「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-max値よりも大きくありません。
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 これは（largest-nc-nc-window）より大きく、ここでmaximum-ncは、セッションで以前に送信されたncの最大値であり、nc-windowは、から受信された「nc-window」パラメーターの値です。セッションのサーバー。
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.
最後の条件により、サーバーは、関連するセッションで使用されるナンス番号の「現在の」値（nc-windowの値によって定義される）よりも「大幅に」小さいナンス番号を拒否できます。言い換えると、サーバーはそのようなナンス番号を「すでに受信済み」として扱うことができます。この制限により、サーバーはセッションごとに一定量のメモリで重複ナンス検出を実装できます。
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.
サーバーは受信したナンス番号の重複をチェックする必要があり、重複が検出された場合、サーバーはセッションを破棄し、セクション11で概説されているように、401-STALEメッセージで応答する必要があります（サーバーは他の無効なナンス番号（ nc-max制限を超えるものとして）、401-STALEメッセージを送信します。
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-window値が128で、nc-maxが400であり、クライアントがすでに次のnonce番号を使用していると想定します：{1-120、122、124、130-238、255- 360、363-372}。その後、次のリクエストに使用できるナンス番号は、セット{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による）を使用して黙ってそれらを切り捨ててはならない（MUST NOT） ^ 32）。代わりに、プロトコル全体が慎重に設計されているため、受信者はこのようなオーバーフローする値（2 ^ 80など）をある程度大きな最大代表整数（2 ^ 31-1など）に置き換えることができます（MAY）。
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:
「validation」パラメータの有効なトークンと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.
host：ホスト名の検証。値vhは次の形式のASCII文字列になります： "<scheme>：// <host>：<port>"、ここで<scheme>、<host>、および<port>はサーバーに対応するURIコンポーネントです現在アクセスされている側のリソース。スキームとホストは小文字であり、ポートは最短の10進表記でリストされます。リクエスト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-server-end-point：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-unique：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).
暗号化されていないチャネル（TCPおよびStream Control Transmission Protocol（SCTP）など）でHTTPが使用されている場合、検証タイプは「ホスト」である必要があります。 HTTP / TLS [RFC2818]（HTTPS）がサーバー証明書で使用される場合、検証タイプは「tls-server-end-point」でなければなりません。 HTTP / TLSが匿名のDiffie-Hellman鍵交換で使用される場合、検証タイプは「tls-unique」でなければなりません（以下の注を参照）。
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接続での検証の2つのバリアントを定義します。 「tls-unique」方式は、技術的にはより安全です。ただし、「tls-server-end-point」が望ましい状況がいくつかあります。
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 CONNECTメソッドを使用するクライアント側の「トンネリング」プロキシには当てはまりません。
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チャネルは、サーバーID検証を提供する必要があります。これは、（1）匿名のDiffie-Hellman鍵交換暗号スイートを使用してはならず（2）サーバーから提供されたサーバー証明書の検証を実行する必要があることを意味します。これは、認証されたページから参照される、IDが認証されていないスクリプトまたは動的コンテンツを読み込まないようにするためです。
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チャネルがサーバーID検証を実行しない場合、クライアントは、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-unique」検証値は、可能なTLS再ネゴシエーションによって変更され、相互運用性の問題を引き起こします。 TLS再ネゴシエーションは、いくつかのHTTPSサーバーの実装で、特定の応答にいくつかのセキュリティプロパティ（暗号強度など）を適用するために使用されます。
If an implementation supports the "tls-unique" verification method, the following precautions SHOULD be taken:
実装が「tls-unique」検証方法をサポートしている場合は、次の予防策を講じる必要があります。
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再ネゴシエーション要求に応答する前に、応答ヘッダーの先頭を受信する前に実行できることと、SHOULDであることです。
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-unique」チャネルバインディングメカニズムとマスターシークレットに関するセッション再開攻撃に注意する必要があります。緩和策として、[RFC7627]で定義されているTLS拡張は、「tls-unique」ホスト検証を使用する場合に使用する必要があります（SHOULD）。
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ブラウザなど）は、「auth-style」パラメータを除いて、必須ではない認証と[RFC8053]で定義されているAuthentication-Controlヘッダーをサポートすることをお勧めします。この仕様では、デフォルトの「auth-style」を「非モーダル」にすることも提案されています（ただし、必須ではありません）。ただし、Webアプリケーションは、これらのヘッダーをサポートしないクライアントの動作によるセキュリティへの影響を考慮する必要があります（SHOULD）。
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).
Optional-WWW-Authenticateヘッダーを含む認証初期化メッセージは、401-INIT応答が有効な場合にのみ使用されます。 401-STALEや401-KEX-S1など、他の401タイプのメッセージは置き換えられません。つまり、そのようなメッセージの「reason」フィールドは「initial」（またはセクション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.
どちらの場合も、文字列を正しく準備するのは送信者の義務です。通信の他のピアから準備されていない文字列を受信した場合、その受信者の動作は定義されていません。受信者は、そのような入力を受け入れるか拒否することができます。
Server applications SHOULD also prepare usernames and passwords accordingly upon registration of user credentials.
サーバーアプリケーションは、ユーザー資格情報の登録時にユーザー名とパスワードも準備する必要があります（SHOULD）。
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エンコーディングのみを実行）を省略してもよい（MAY）。文字列がオクテットblobとして既に格納されている場合、実装はそれをそのまま送信してもよい（MAY）。
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認証では、単一のユーザーレベルのリクエストにより、2つ以上の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 あらゆる種類の「通常の応答」は、シーケンスの最初の要求に対してのみ受け入れられる必要があります。シーケンスの2番目以降の要求に対して返された「通常の応答」は、無効であると見なされます。
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メッセージ）は、最初の要求に対してのみ受け入れられる必要があります。シーケンス。シーケンスの2番目以降の要求に対して返されたそのような応答は、無効であると見なされます。
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メッセージへの初期要求または応答として送信される場合があります。ただし、メッセージの無限ループを回避するために、1つの認証レルムのシーケンスでreq-KEX-C1メッセージを複数回送信してはなりません（SHOULD NOT）。対応する要求が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ステータスコードを含む応答が返された場合、対応するセッションシークレットを使用不可として破棄する必要があります（SHOULD）。
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メッセージを送信して新しいセッションの確立を試行する必要がありますが、要求/応答シーケンス内で1回だけです。
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値は常に正しい値に対してチェックされる必要があり、それが正しくない場合、応答全体が無効であると見なされるべきです（SHOULD）。
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-SUCCEED：シーケンス内のreq-VFY-C要求への応答として、正しいVK_s値を含む200-VFY-Sメッセージが返されました。
o AUTH-REQUIRED: Two cases exist:
o AUTH-REQUIRED：2つのケースが存在します：
* 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 UNAUTHENTICATED：シーケンス内のあらゆる種類の初期リクエストに対して「通常の応答」が返されます。
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".
上記のルールで明示的に許可されている応答以外の応答（「通常の応答」を含む）は、致命的な通信エラーとして解釈されるべきです（SHOULD）。そのような場合、クライアントはサーバーから送信されたデータ（応答本文およびその他のコンテンツ関連ヘッダー）を処理してはなりません（MUST NOT）。ただし、例外的なエラーのケースを処理するために、サーバーエラー（5xx）ステータスコードがある場合、クライアントはAuthentication-Infoヘッダーのないメッセージを受け入れることができます（MAY）。このような場合、コンテンツの本文の処理に注意する必要があり（中間の攻撃者によって偽造されている可能性があるため、これはまだ推奨されません）、クライアントのステータスは「非認証」になります。
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.
リクエストが別のリソースに含まれているリソース（埋め込み画像、スタイルシート、フレームなど）に対するサブリクエストである場合、クライアントは、AUTH-REQUESTEDステータスをUNAUTHENTICATEDステータスと同様に処理できます（MAY）。言い換えると、クライアントは、サブリクエストを介して新しい資格情報で認証を開始するというサーバーのリクエストを無視してもよい（MAY）。
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.
次のステートマシンは、上記の規範的なルールから導出された、可能な要求/応答シーケンスを示しています。実装者が上記のルールのセキュリティ結果に確信がない場合は、以下の決定手順に従うことを強くお勧めします。特に、クライアントは、ルールで明示的に許可されていない限り、「通常の応答」を受け入れるべきではありません（SHOULD NOT）。以下の手順のラベルは、情報提供のみを目的としています。各ステップ内のアクションエントリは、上から下の順序でチェックされ、満たされた最初の句に従います。
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（step_send_vfy_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（step_send_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（step_send_normal_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（step_send_vfy）：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（step_send_kex1）：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（step_rcvd_kex1）：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（step_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.
ステップ12（step_rcvd_init_unknown）：リクエストされたリソースは相互認証を必要とし、ユーザーはまだ認証されていません。クライアントは「AUTH-REQUESTED」ステータスになります。クライアントがサーバーから送信されたコンテンツを処理し、ユーザーにユーザー名とパスワードを要求することをお勧めします。それらがユーザーによって提供されたら、ステップ9に進みます。
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_failed）：おそらく認証されたリソースのパスワードまたはユーザー名が無効なため、何らかの理由で認証が失敗しました。認証レルムのユーザー提供の資格情報を忘れて、ステップ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（step_rcvd_vfy）：受信したメッセージは200-VFY-Sメッセージで、常に「vks」フィールドが含まれています。受信したVK_s値の有効性を確認してください。期待値と等しい場合、相互認証は成功しています。クライアントは「AUTH-SUCCEED」ステータスになります。
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 ) --------------
-----------------
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（largest-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.
* （largest-nc-nc-window + 1）とmax_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応答を送信します。作成されたセッションは偽物ではないとマークされ、その最大の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」パラメーターよりも大きい場合、または（largest-nc-nc-window）よりも大きくない場合（「authenticated」状態の場合）、サーバーは（必須ではありません。注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応答を送信します。セッションが「キー交換」状態であった場合、セッションは「認証済み」状態に変更する必要があります（SHOULD）。状態の最大の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.
いつでも、サーバーは「拒否」状態と「認証済み」状態の両方の状態エントリを「非アクティブ」状態に変更でき、「非アクティブ」状態をテーブルから破棄できます（MAY）。 「キー交換」状態のエントリは、サーバーの再起動やテーブル容量のオーバーフローなどの緊急事態が発生しない限り保持する必要があります（SHOULD）。
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メッセージは、Optional-WWW-Authenticateヘッダーを持つ成功した応答に置き換えることはできません。他のすべての401-INITは、Optional-WWW-Authenticateヘッダーを含む応答にすることができます。
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 クライアント側の認証資格情報piから派生したサーバー側の認証資格情報J。
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).
このプロトコルで使用されるすべてのアルゴリズムは、クライアントとサーバー間の安全な相互認証を提供し、ハッシュ関数Hと同等以上の強力な暗号化された共有秘密値（z）を生成する必要があります（SHOULD）。パスワード（またはパスフレーズまたは同等のもの、つまり、弱い秘密）が含まれている場合、攻撃者（盗聴者またはアクティブサーバー）が完全に検索可能なパスワードの候補リストを知っていても、これらはプロトコルで送信されるデータから推測できません（SHOULD NOT）。さらに、サーバー側の認証資格情報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".
仕様の整数は10進数、または「0x」が前に付いている場合は16進数です。
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の単一オクテットを含むオクテット文字列を生成します。演算子「|」は、オクテット文字列に適用される場合、2つのオペランドの連結を示します。
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であってはなりません。たとえば、VI（i）= octet（i）for i <128、およびVI（i）= octet（0x80 +（i >> 7））| 128 <= i <16384のオクテット（i＆127）。このエンコーディングは、ASN.1エンコーディング[ITU.X690.2015]でオブジェクト識別子のサブコンポーネントに使用されるエンコーディングと同じであり、「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
where length(s) is a number of octets (not characters) in s.
ここで、length（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@"
VS("") = "\000"
VS（ ""）= "\ 000"
VS("Tea") = "\003Tea"
VS（ "お茶"）= "\ 003お茶"
VS("Caf<e acute>" [in UTF-8]) = "\005Caf\303\251"
VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets)
VS（[10000 "a" s]）= "\ 316 \ 020aaaaa ..."（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.) 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".
（注：BasicおよびDigest HTTP認証スキームで使用されるコロンで区切られた形式とは異なり、VSエンコードされた文字列の連結によって生成される文字列は、エンコードされる文字列に含まれる文字に関係なく一意になります。）関数OCTETSは、整数を対応するradix-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のビッグエンディアン表記として扱われます。アイデンティティINT（OCTETS（n））= 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))
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.
アルゴリズム、レルム、および認証スコープの値は、401-INITメッセージに含まれている値から取得されます。パスワードがユーザー入力からのものである場合、セクション9で提示された方法に従って最初に準備する必要があります。次に、パスワードをUTF-8文字列としてエンコードする必要があります（SHALL）。
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_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))
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))
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 407（プロキシ認証が必要）ステータスコードは、401ステータスコードが使用される場所で送信および認識されます。
o The Proxy-Authenticate header is to be used in places where the WWW-Authenticate header is used,
o Proxy-Authenticateヘッダーは、WWW-Authenticateヘッダーが使用される場所で使用されます。
o The Proxy-Authorization header is to be used in places where the Authorization header is used,
o Proxy-Authorizationヘッダーは、Authorizationヘッダーが使用される場所で使用されます。
o The Proxy-Authentication-Info header is to be used in places where the Authentication-Info header is used,
o Proxy-Authentication-Infoヘッダーは、Authentication-Infoヘッダーが使用される場所で使用されます。
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メッセージの「パス」パラメーターを省略したことは、認証レルムがプロキシーによって処理されたすべての要求をカバーする可能性があることを意味します。
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」で始まり、その後に10進数の自然数が続くパラメーター（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 認証スキーム名：相互
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].
ベアトークンがauthentication-algorithmパラメータに使用される場合、それらは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 |
+----------------------+------------------------+----------------+
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は、トランスポートのセキュリティが保証されておらず、データの機密性が重要である場合に使用する必要があります（SHOULD）。
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.
クライアント側のパスワード認証情報は常に秘密にしておく必要があり、他の（おそらく安全でない）認証目的で使用してはなりません（SHOULD NOT）。資格情報の制御が失われると、対応するサーバー側アカウントの制御に直接影響します。
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.
このプロトコルには、アクティブなセッションのサーバー側のテーブルが必要です。これは、サーバーのリソース消費にとって重要なポイントになる可能性があります。適切な操作のために、プロトコルでは、セッションIDごとに少なくとも1つの鍵検証要求を処理する必要があります。その後、サーバーは、クライアントの運用上の問題を引き起こすことなく、いつでもセッションを内部的に破棄できます。その後、クライアントは静かに新しいセッションを再確立します。
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メッセージ）のみに対して大量のリクエストを送信すると、リソース不足が発生する可能性があります。このような重大な状況では、サーバーは、ステータスに関係なく、既存のあらゆる種類のセッションを破棄する場合があります。このような攻撃を軽減する1つの方法は、サーバーが未検証の保留中の鍵交換要求（「鍵交換」状態）の数と時間の制限を設定する可能性があることです。
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.
このプロトコルは、2つの目標を念頭に置いて設計されています。最初の目標は、既存の基本認証方式とダイジェスト認証方式の安全な代替手段を提供することです。 2番目の目標は、サーバーにユーザーの登録済みアカウントを模倣した（フィッシング攻撃などを介して）偽造された不正サーバーを検出する方法をユーザーに提供することです。
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.
このプロトコルがこのような攻撃への対策として効果的に機能するためには、クライアントのエンドユーザーに、このプロトコルによる相互認証の結果、特に「AUTH-SUCCEED」、「AUTH-REQUIRED」の3つの状態を通知することが非常に重要です。 、およびセクション10で定義されている「非認証」。HTTPインタラクティブクライアントの安全なユーザーインターフェースの設計は、このドキュメントの範囲外ですが、可能であれば、上記の3つの状態に対して何らかの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メッセージのAuthentication-Infoヘッダーを常にクライアントが検証する必要があります。検証が失敗した場合、クライアントは、メッセージとともに送信されたコンテンツ（他のヘッダーや本文部分を含む）を処理してはなりません（MUST NOT）。この要件に準拠しないと、フィッシング攻撃が可能になります。
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-server-end-point」検証メソッドを介して相互認証されたページから同じレルムで保護されているURI（「path」パラメーターで示される）にWebフォームが送信されると、ページが受信されてからサーバー証明書が変更されている場合は、 "Expect：100-continue"ヘッダーのreq-KEX-C1メッセージを使用してピアを再検証することをお勧めします。 「tls-unique」検証メソッドを介してページを受信した場合、および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 パスワードデータベースの盗用の可能性を防ぐために、ユーザーパスワードのサーバー側ストレージには、実際のパスワードやpiでハッシュされた値ではなく、一方向関数J（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サーバーが同じレルム内の相互認証スキームを要求すると、クライアントはユーザー名をクリアテキストで送信します。ユーザー名を（盗聴者から保護して）秘密にしておく必要がある場合、サーバーはfull-scheme-type "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：Keyed-Hashing for Message Authentication」、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。、「The 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、「The Transport Layer Security（TLS）Protocol Version 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。、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>。
[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。、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>。
[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 Authentication-Info and Proxy-Authentication-Info Response Header Fields」、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：Password-Based Cryptography Specification Version 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]大岩裕、渡辺博、高木博、前田健、林徹、井奥裕、「インタラクティブクライアント用の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コンソーシアム、「The Unicode Standard」、<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] 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勧告X .690、ISO / IEC 8825-1、2015年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.ローズ、「Post Office Protocol-Version 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。、「HTTP Over TLS」、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、「RFCで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。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、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 State Management Mechanism」、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。、「The Web Origin Concept」、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。、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>。
[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 Origin-Bound Authentication（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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（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 Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年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.、and M. Ray、 "Transport Layer Security（TLS）Session Hash and Extended Master Secret Extension"、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]大岩洋、渡辺博、高木博、前田健、林智、伊奥裕、「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 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
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
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
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 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
Kaoru Maeda Individual Contributor Email: kaorumaeda.ml@gmail.com
前田かおる個人投稿者メールアドレス：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
たつや はやし ぇぴづｍ こ。 Ｌｔｄ。 ゔぃっぁげ ささずか ３、 すいて ＃６０２ １ー３０ー３ ささずか しぶやーく、 ときょ じゃぱん えまいｌ： はやし＠ぇぴづｍ。こ。ｊｐ
Yuichi Ioku Individual Contributor Email: mutual-work@ioku.org
井奥雄一個人貢献者メール：mutual-work@ioku.org