[要約] RFC 7804は、ソルト付きのチャレンジレスポンスHTTP認証メカニズムに関する仕様です。このRFCの目的は、セキュリティを向上させるために、パスワードの保護と認証の手法を提供することです。
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 7804 Isode Ltd
Category: Experimental March 2016
ISSN: 2070-1721
Salted Challenge Response HTTP Authentication Mechanism
ソルトチャレンジレスポンスHTTP認証メカニズム
Abstract
概要
This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.
この仕様では、ソルトチャレンジレスポンス認証メカニズム（SCRAM）と呼ばれるHTTP認証メカニズムのファミリーについて説明しています。これは、トランスポート層セキュリティ（TLS）で保護された平文パスワードよりも堅牢な認証メカニズムを提供し、以前のTLSで保護されたデプロイメントの障害を回避しますチャレンジ/レスポンス認証メカニズム。
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 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7804.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7804で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. One Round-Trip Reauthentication . . . . . . . . . . . . . 10
6. Use of the Authentication-Info Header Field with SCRAM . . . 12
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
The authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the HTTP Digest challenge response mechanism presently on the Standards Track failed widespread deployment and has had only limited success.
インターネットアプリケーションプロトコルで最も広く展開および使用されている認証メカニズムは、トランスポート層セキュリティ（TLS）で保護されたチャネルを介したクリアテキストパスワードの送信です。そのメカニズムには、TLSで保護されたチャレンジレスポンス認証メカニズムを使用することで対処できる重要なセキュリティ上の懸念があります。残念ながら、現在スタンダードトラックにあるHTTPダイジェストチャレンジレスポンスメカニズムは、広範囲にわたる展開に失敗し、限られた成功しか収めていません。
This specification describes a family of authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the requirements necessary to deploy a challenge response mechanism more widely than past attempts (see [RFC5802]). In particular, it addresses some of the issues identified with HTTP Digest, as described in [RFC6331], such as the complexity of implementation and protection of the whole authentication exchange in order to protect against certain man-in-the-middle attacks.
この仕様では、ソルトチャレンジレスポンス認証メカニズム（SCRAM）と呼ばれる認証メカニズムのファミリーについて説明しています。これは、チャレンジレスポンスメカニズムを過去の試みよりも広く展開するために必要な要件に対応しています（[RFC5802]を参照）。特に、[RFC6331]で説明されているように、特定のman-in-the-middle攻撃から保護するための認証交換全体の保護や保護など、HTTPダイジェストで識別されるいくつかの問題に対処します。
HTTP SCRAM is an adaptation of [RFC5802] for use in HTTP. The SCRAM data exchanged is identical to what is defined in [RFC5802]. This document also adds a 1 round-trip reauthentication mode.
HTTP SCRAMは、[RFC5802]をHTTPで使用するために改造したものです。交換されるSCRAMデータは、[RFC5802]で定義されているものと同じです。このドキュメントでは、1往復の再認証モードも追加されています。
HTTP SCRAM provides the following protocol features:
HTTP SCRAMは、次のプロトコル機能を提供します。
o The authentication information stored in the authentication database is not sufficient by itself (without a dictionary attack) to impersonate the client. The information is salted to make it harder to do a pre-stored dictionary attack if the database is stolen.
o 認証データベースに格納されている認証情報だけでは（辞書攻撃なしでは）クライアントを偽装するには不十分です。データベースが盗まれた場合、事前に格納された辞書攻撃を実行するのを困難にするために、情報はソルト化されます。
o The server does not gain the ability to impersonate the client to other servers (with an exception for server-authorized proxies), unless it performs a dictionary attack.
o サーバーは、ディクショナリ攻撃を実行しない限り、クライアントを他のサーバーに偽装する機能を取得しません（サーバー承認プロキシを除く）。
o The mechanism permits the use of a server-authorized proxy without requiring that proxy to have super-user rights with the back-end server.
o このメカニズムでは、バックエンドサーバーとのスーパーユーザー権限を持つプロキシを必要とせずに、サーバー承認プロキシを使用できます。
o Mutual authentication is supported, but only the client is named (i.e., the server has no name).
o 相互認証はサポートされていますが、名前が付けられるのはクライアントのみです（つまり、サーバーには名前がありません）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Formal syntax is defined by [RFC5234] including the core rules defined in Appendix B of [RFC5234].
正式な構文は、[RFC5234]の付録Bで定義されているコアルールを含め、[RFC5234]で定義されています。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
「C：」で始まる行の例はクライアントによって送信され、「S：」で始まる行はサーバーによって送信されます。単一の「C：」または「S：」ラベルが複数の行に適用される場合、それらの行の間の改行は編集上の明確さのためだけであり、実際のプロトコル交換の一部ではありません。
This document uses several terms defined in the "Internet Security Glossary" [RFC4949], including the following: authentication, authentication exchange, authentication information, brute force, challenge-response, cryptographic hash function, dictionary attack, eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, one-way encryption function, password, replay attack, and salt. Readers not familiar with these terms should use that glossary as a reference.
このドキュメントでは、「インターネットセキュリティ用語集」[RFC4949]で定義されているいくつかの用語を使用しています。認証、認証交換、認証情報、ブルートフォース、チャレンジ/レスポンス、暗号化ハッシュ関数、辞書攻撃、盗聴、ハッシュ結果、キー付きハッシュ、中間者、ノンス、一方向の暗号化機能、パスワード、リプレイアタック、ソルト。これらの用語に詳しくない読者は、その用語集を参照として使用してください。
Some clarifications and additional definitions follow:
次に、いくつかの説明と追加の定義を示します。
o Authentication information: Information used to verify an identity claimed by a SCRAM client. The authentication information for a SCRAM identity consists of salt, iteration count, the StoredKey, and the ServerKey (as defined in the algorithm overview) for each supported cryptographic hash function.
o 認証情報：SCRAMクライアントによって要求されたIDを検証するために使用される情報。 SCRAM IDの認証情報は、サポートされている各暗号化ハッシュ関数のソルト、反復カウント、StoredKey、および（アルゴリズムの概要で定義されている）ServerKeyで構成されています。
o Authentication database: The database used to look up the authentication information associated with a particular identity. For application protocols, LDAPv3 (see [RFC4510]) is frequently used as the authentication database. For lower-layer protocols such as PPP or 802.11x, the use of RADIUS [RFC2865] is more common.
o 認証データベース：特定のIDに関連付けられた認証情報を検索するために使用されるデータベース。アプリケーションプロトコルでは、LDAPv3（[RFC4510]を参照）が認証データベースとして頻繁に使用されます。 PPPや802.11xなどの下位層プロトコルでは、RADIUS [RFC2865]の使用がより一般的です。
o Base64: An encoding mechanism defined in Section 4 of [RFC4648] that converts an octet string input to a textual output string that can be easily displayed to a human. The use of base64 in SCRAM is restricted to the canonical form with no whitespace.
o Base64：[RFC4648]のセクション4で定義されているエンコードメカニズムで、オクテット文字列の入力を、人間が簡単に表示できるテキスト出力文字列に変換します。 SCRAMでのbase64の使用は、空白のない正規形式に制限されています。
o Octet: An 8-bit byte.
o オクテット：8ビットのバイト。
o Octet string: A sequence of 8-bit bytes.
o オクテット文字列：8ビットバイトのシーケンス。
o Salt: A random octet string that is combined with a password before applying a one-way encryption function. This value is used to protect passwords that are stored in an authentication database.
o ソルト：一方向の暗号化関数を適用する前にパスワードと組み合わせられるランダムなオクテット文字列。この値は、認証データベースに保管されているパスワードを保護するために使用されます。
The pseudocode description of the algorithm uses the following notation:
アルゴリズムの疑似コードの説明では、次の表記法を使用しています。
o ":=": The variable on the left-hand side represents the octet string resulting from the expression on the right-hand side.
o "：="：左側の変数は、右側の式から得られるオクテット文字列を表します。
o "+": Octet string concatenation.
o "+"：オクテット文字列連結。
o "[ ]": A portion of an expression enclosed in "[" and "]" is optional in the result under some circumstances. See the associated text for a description of those circumstances.
o 「[]」：「[」と「]」で囲まれた式の一部は、状況によっては結果でオプションになります。それらの状況の説明については、関連するテキストを参照してください。
o Normalize(str): Apply the Preparation and Enforcement steps according to the OpaqueString profile (see [RFC7613]) to a UTF-8 [RFC3629] encoded "str". The resulting string is also in UTF-8. Note that implementations MUST either implement OpaqueString profile operations from [RFC7613] or disallow the use of non US-ASCII Unicode codepoints in "str". The latter is a particular case of compliance with [RFC7613].
o Normalize（str）：OpaqueStringプロファイル（[RFC7613]を参照）に従って準備および実施の手順をUTF-8 [RFC3629]でエンコードされた「str」に適用します。結果の文字列もUTF-8です。実装は、[RFC7613]からのOpaqueStringプロファイル操作を実装するか、 "str"でUS-ASCII以外のUnicodeコードポイントを使用できないようにする必要があることに注意してください。後者は、[RFC7613]に準拠する特定のケースです。
o HMAC(key, str): Apply the HMAC-keyed hash algorithm (defined in [RFC2104]) using the octet string represented by "key" as the key and the octet string "str" as the input string. The size of the result is the hash result size for the hash function in use. For example, it is 32 octets for SHA-256 and 20 octets for SHA-1 (see [RFC6234]).
o HMAC（key、str）： "key"で表されるオクテット文字列をキーとして、オクテット文字列 "str"を入力文字列として使用して、HMACキー付きハッシュアルゴリズム（[RFC2104]で定義）を適用します。結果のサイズは、使用中のハッシュ関数のハッシュ結果サイズです。たとえば、SHA-256の場合は32オクテット、SHA-1の場合は20オクテットです（[RFC6234]を参照）。
o H(str): Apply the cryptographic hash function to the octet string "str", producing an octet string as a result. The size of the result depends on the hash result size for the hash function in use.
o H（str）：オクテット文字列 "str"に暗号化ハッシュ関数を適用し、結果としてオクテット文字列を生成します。結果のサイズは、使用しているハッシュ関数のハッシュ結果サイズによって異なります。
o XOR: Apply the exclusive-or operation to combine the octet string on the left of this operator with the octet string on the right of this operator. The length of the output and each of the two inputs will be the same for this use.
o XOR：この演算子の左側のオクテット文字列とこの演算子の右側のオクテット文字列を組み合わせるために、排他的論理和演算を適用します。この用途では、出力と2つの入力のそれぞれの長さは同じになります。
o Hi(str, salt, i):
o こんにちは（str、salt、i）：
U1 := HMAC(str, salt + INT(1))
U2 := HMAC(str, U1)
...
Ui-1 := HMAC(str, Ui-2)
Ui := HMAC(str, Ui-1)
Hi := U1 XOR U2 XOR ... XOR Ui
こんにちは：= U1 XOR U2 XOR ... XOR Ui
where "i" is the iteration count, "+" is the string concatenation operator, and INT(g) is a four-octet encoding of the integer g, most significant octet first.
ここで、 "i"は反復回数、 "+"は文字列連結演算子、INT（g）は整数gの4オクテットエンコーディングで、最も重要なオクテットが最初です。
Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the Pseudorandom Function (PRF) and with dkLen == output length of HMAC() == output length of H().
Hi()は基本的に、PBKDF2 [RFC2898]であり、疑似ランダム関数（PRF）としてHMAC()を使用し、dkLen == HMAC()の出力長== H()の出力長を使用します。
The following is a description of a full HTTP SCRAM authentication exchange. Note that this section omits some details, such as client and server nonces. See Section 5 for more details.
以下は、完全なHTTP SCRAM認証交換の説明です。このセクションでは、クライアントやサーバーのナンスなど、一部の詳細が省略されていることに注意してください。詳細については、セクション5を参照してください。
To begin with, the SCRAM client is in possession of a username and password, both encoded in UTF-8 [RFC3629] (or a ClientKey/ServerKey, or SaltedPassword). It sends the username to the server, which retrieves the corresponding authentication information: a salt, a StoredKey, a ServerKey, and an iteration count ("i"). (Note that a server implementation may choose to use the same iteration count for all accounts.) The server sends the salt and the iteration count to the client, which then computes the following values and sends a ClientProof to the server:
まず、SCRAMクライアントは、UTF-8 [RFC3629]（またはClientKey / ServerKey、またはSaltedPassword）でエンコードされたユーザー名とパスワードを所有しています。ユーザー名をサーバーに送信し、サーバーは対応する認証情報（salt、StoredKey、ServerKey、および反復カウント（ "i"））を取得します。 （サーバーの実装では、すべてのアカウントに同じ反復カウントを使用する場合があることに注意してください。）サーバーはソルトと反復カウントをクライアントに送信し、クライアントは次の値を計算して、ClientProofをサーバーに送信します。
Informative Note: Implementors are encouraged to create test cases that use both usernames and passwords with non-ASCII codepoints. In particular, it is useful to test codepoints whose Unicode Normalization Canonical Composition (NFC) and Unicode Normalization Form Compatibility Composition (NFKC) are different (see [Unicode-UAX15]). Some examples of such codepoints include Vulgar Fraction One Half (U+00BD) and Acute Accent (U+00B4).
参考情報：実装者は、非ASCIIコードポイントでユーザー名とパスワードの両方を使用するテストケースを作成することをお勧めします。特に、Unicode正規化正規構成（NFC）とUnicode正規化フォーム互換性構成（NFKC）が異なるコードポイントをテストするのに役立ちます（[Unicode-UAX15]を参照）。そのようなコードポイントのいくつかの例には、下品な分数の半分（U + 00BD）と急性アクセント（U + 00B4）が含まれます。
SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," +
server-first-message + "," +
client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof := ClientKey XOR ClientSignature
ServerKey := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage)
The server authenticates the client by computing the ClientSignature, exclusive-ORing that with the ClientProof to recover the ClientKey, and verifying the correctness of the ClientKey by applying the hash function and comparing the result to the StoredKey. If the ClientKey is correct, this proves that the client has access to the user's password.
サーバーは、ClientSignatureを計算し、それをClientProofと排他的論理和してClientKeyを回復し、ハッシュ関数を適用して結果をStoredKeyと比較することにより、ClientKeyの正当性を検証することにより、クライアントを認証します。 ClientKeyが正しい場合、これはクライアントがユーザーのパスワードにアクセスできることを証明します。
Similarly, the client authenticates the server by computing the ServerSignature and comparing it to the value sent by the server. If the two are equal, this proves that the server had access to the user's ServerKey.
同様に、クライアントは、ServerSignatureを計算し、それをサーバーから送信された値と比較することにより、サーバーを認証します。 2つが等しい場合、これはサーバーがユーザーのServerKeyにアクセスできたことを証明します。
For initial authentication, the AuthMessage is computed by concatenating decoded "data" attribute values from the authentication exchange. The format of each of these 3 decoded "data" attributes is defined in [RFC5802].
初期認証の場合、AuthMessageは、認証交換からのデコードされた「データ」属性値を連結することによって計算されます。これら3つのデコードされた「データ」属性のそれぞれの形式は、[RFC5802]で定義されています。
A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" followed by the uppercased name of the underlying hash function taken from the IANA "Hash Function Textual Names" registry (see <http://www.iana.org/assignments/hash-function-text-names>).
SCRAMメカニズム名（認証スキーム）は、文字列「SCRAM-」の後に、IANAの「ハッシュ関数のテキスト名」レジストリから取得された、基礎となるハッシュ関数の大文字の名前が続きます（<http://www.iana.org/assignmentsを参照） / hash-function-text-names>）。
For interoperability, all HTTP clients and servers supporting SCRAM MUST implement the SCRAM-SHA-256 authentication mechanism, i.e., an authentication mechanism from the SCRAM family that uses the SHA-256 hash function as defined in [RFC7677].
相互運用性のために、SCRAMをサポートするすべてのHTTPクライアントおよびサーバーは、SCRAM-SHA-256認証メカニズム、つまり、[RFC7677]で定義されているSHA-256ハッシュ関数を使用するSCRAMファミリーの認証メカニズムを実装する必要があります。
HTTP SCRAM is an HTTP Authentication mechanism whose client response (<credentials-scram>) and server challenge (<challenge-scram>) messages are text-based messages containing one or more attribute-value pairs separated by commas. The messages and their attributes are described below and defined in Section 7.
HTTP SCRAMは、クライアント認証（<credentials-scram>）およびサーバーチャレンジ（<challenge-scram>）メッセージが、カンマで区切られた1つ以上の属性と値のペアを含むテキストベースのメッセージであるHTTP認証メカニズムです。メッセージとその属性については、以下で説明し、セクション7で定義します。
challenge-scram = scram-name [1*SP 1#auth-param] ; Complies with <challenge> ABNF from RFC 7235. ; Included in the WWW-Authenticate header field.
challenge-scram = scram-name [1 * SP 1＃auth-param]; RFC 7235の<challenge> ABNFに準拠。 WWW-Authenticateヘッダーフィールドに含まれています。
credentials-scram = scram-name [1*SP 1#auth-param] ; Complies with <credentials> from RFC 7235. ; Included in the Authorization header field.
credentials-scram = scram-name [1 * SP 1＃auth-param]; RFC 7235の<credentials>に準拠しています。 Authorizationヘッダーフィールドに含まれています。
scram-name = "SCRAM-SHA-256" / "SCRAM-SHA-1" / other-scram-name
; SCRAM-SHA-256 and SCRAM-SHA-1 are registered by this RFC.
;
; SCRAM-SHA-1 is registered for database compatibility
; with implementations of RFC 5802 (such as IMAP or Extensible
Messaging and Presence Protocol (XMPP)
; servers), but it is not recommended for new deployments.
other-scram-name = "SCRAM-" hash-name
; hash-name is a capitalized form of names from IANA.
; "Hash Function Textual Names" registry.
; Additional SCRAM names must be registered in both
; the IANA "SASL Mechanisms" registry
; and the IANA "HTTP Authentication Schemes" registry.
This is a simple example of a SCRAM-SHA-256 authentication exchange (no support for channel bindings, as this feature is not currently supported by HTTP). Username 'user' and password 'pencil' are used. Note that long lines are folded for readability.
これは、SCRAM-SHA-256認証交換の簡単な例です（この機能は現在HTTPでサポートされていないため、チャネルバインディングはサポートされていません）。ユーザー名「user」とパスワード「pencil」が使用されます。読みやすいように長い行は折り返されています。
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com"
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: SCRAM-SHA-256
sid=AAAABBBBCCCCDDDD,
data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK
S: [...]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD,
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
TUhnc3FtbWl6N0FuZFZRPQo=
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
In the above example, the first client request contains a "data"
attribute that base64 decodes as follows:
n,,n=user,r=rOprNGfwEbeRWgbNEkqO
n ,, n = user、r = rOprNGfwEbeRWgbNEkqO
The server then responds with a "data" attribute that base64 decodes as follows:
次にサーバーは、base64が次のようにデコードする「データ」属性で応答します。
r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,s=W22ZaJ0SNY7soE
sUEjb6gQ==,i=4096
The next client request contains a "data" attribute that base64 decodes as follows:
次のクライアント要求には、base64が次のようにデコードする「データ」属性が含まれています。
c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZap
WIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=
The final server response contains a "data" attribute that base64 decodes as follows:
最終的なサーバー応答には、base64が次のようにデコードする「データ」属性が含まれます。
v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=
Note that in the example above, the client can also initiate SCRAM authentication without first being prompted by the server.
上記の例では、クライアントは最初にサーバーからプロンプトを表示することなくSCRAM認証を開始することもできます。
Initial "SCRAM-SHA-256" authentication starts with sending the Authorization request header field (defined by HTTP/1.1, Part 7 [RFC7235]) containing the "SCRAM-SHA-256" authentication scheme and the following attributes:
最初の「SCRAM-SHA-256」認証は、「SCRAM-SHA-256」認証スキームと次の属性を含むAuthorizationリクエストヘッダーフィールド（HTTP / 1.1、パート7 [RFC7235]で定義）を送信することから始まります。
o A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. As specified in [RFC7235], the "realm" attribute MUST NOT appear more than once. The "realm" attribute only appears in the first SCRAM message to the server and in the first SCRAM response from the server.
o HTTP / 1.1、パート7 [RFC7235]で説明されている方法で保護の範囲を示すために、「レルム」属性が含まれる場合があります。 [RFC7235]で指定されているように、「レルム」属性は複数回出現してはなりません。 「レルム」属性は、サーバーへの最初のSCRAMメッセージとサーバーからの最初のSCRAM応答にのみ表示されます。
o The client also includes the "data" attribute that contains the base64-encoded "client-first-message" [RFC5802] containing:
o クライアントには、base64でエンコードされた「client-first-message」[RFC5802]を含む「data」属性も含まれます。
* a header consisting of a flag indicating whether channel binding is supported-but-not-used, not supported, or used. Note that this version of SCRAM doesn't support HTTP channel bindings, so this header always starts with "n"; otherwise, the message is invalid and authentication MUST fail.
* チャネルバインディングがサポートされているが使用されていない、サポートされていない、または使用されているかどうかを示すフラグで構成されるヘッダー。このバージョンのSCRAMはHTTPチャネルバインディングをサポートしていないため、このヘッダーは常に「n」で始まります。それ以外の場合、メッセージは無効であり、認証は失敗する必要があります。
* SCRAM username and a random, unique "nonce" attribute.
* SCRAMユーザー名とランダムで一意の「nonce」属性。
In an HTTP response, the server sends the WWW-Authenticate header field containing a unique session identifier (the "sid" attribute) plus the "data" attribute containing the base64-encoded "server-first-message" [RFC5802]. The "server-first-message" contains the user's iteration count i, the user's salt, and the nonce with a concatenation of the client-specified one (taken from the "client-first-message") with a freshly generated server nonce.
HTTP応答では、サーバーは、一意のセッション識別子（「sid」属性）と、base64でエンコードされた「server-first-message」[RFC5802]を含む「data」属性を含むWWW-Authenticateヘッダーフィールドを送信します。 「server-first-message」には、ユーザーの反復回数i、ユーザーのソルト、および新しく指定されたサーバーnonceをクライアント指定の（「client-first-message」から取得した）を連結したnonceが含まれています。
The client then responds with another HTTP request with the Authorization header field, which includes the "sid" attribute received in the previous server response, together with the "data" attribute containing base64-encoded "client-final-message" data. The latter has the same nonce as in "server-first-message" and a ClientProof computed using the selected hash function (e.g., SHA-256) as explained earlier.
次に、クライアントは、前のサーバー応答で受信した「sid」属性と、base64でエンコードされた「client-final-message」データを含む「data」属性を含む、Authorizationヘッダーフィールドを含む別のHTTP要求で応答します。後者は、「server-first-message」と同じノンスと、前に説明したように、選択されたハッシュ関数（SHA-256など）を使用して計算されたClientProofを持っています。
The server verifies the nonce and the proof, and, finally, it responds with a 200 HTTP response with the Authentication-Info header field [RFC7615] containing the "sid" attribute (as received from the client) and the "data" attribute containing the base64-encoded "server-final-message", concluding the authentication exchange.
サーバーはナンスと証明を検証し、最後に、「sid」属性（クライアントから受信したもの）と「data」属性を含むAuthentication-Infoヘッダーフィールド[RFC7615]を含む200 HTTP応答で応答します。認証交換を終了する、base64でエンコードされた「server-final-message」。
The client then authenticates the server by computing the ServerSignature and comparing it to the value sent by the server. If the two are different, the client MUST consider the authentication exchange to be unsuccessful, and it might have to drop the connection.
次に、クライアントは、ServerSignatureを計算し、それをサーバーから送信された値と比較することにより、サーバーを認証します。 2つが異なる場合、クライアントは認証交換が失敗したと見なさなければならず、接続をドロップする必要がある場合があります。
If the server supports SCRAM reauthentication, the server sends in its initial HTTP response a WWW-Authenticate header field containing the "realm" attribute (as defined earlier), the "sr" attribute that contains the server part of the "r" attribute (see s-nonce in [RFC5802]), and an optional "ttl" attribute (which contains the "sr" value validity in seconds).
サーバーがSCRAM再認証をサポートしている場合、サーバーは最初のHTTP応答で、「レルム」属性（前述の定義）、「r」属性のサーバー部分を含む「sr」属性を含むWWW-Authenticateヘッダーフィールドを送信します（ [RFC5802]のs-nonceを参照）、およびオプションの "ttl"属性（秒単位の "sr"値の有効性を含む）。
If the client has authenticated to the same realm before (i.e., it remembers "i" and "s" attributes for the user from earlier authentication exchanges with the server), it can respond to that with "client-final-message". When constructing the "client-final-message", the client constructs the c-nonce part of the "r" attribute as on initial authentication and the s-nonce part as follows: s-nonce is a concatenation of nonce-count and the "sr" attribute (in that order). The nonce-count is a positive integer that is equal to the user's "i" attribute on first reauthentication and is incremented by 1 on each successful reauthentication.
クライアントが以前に同じレルムに認証されている場合（つまり、以前のサーバーとの認証交換からのユーザーの「i」および「s」属性を記憶している場合）、「client-final-message」でそれに応答できます。 「client-final-message」を作成するとき、クライアントは初期認証と同様に「r」属性のc-nonce部分を構成し、s-nonce部分を次のように構成します。s-nonceはnonce-countと「sr」属性（この順序で）。 nonce-countは、最初の再認証でのユーザーの「i」属性に等しい正の整数で、再認証が成功するたびに1ずつ増加します。
The purpose of the nonce-count is to allow the server to detect request replays by maintaining its own copy of this count -- if the same nonce-count value is seen twice, then the request is a replay.
nonce-countの目的は、サーバーがこのカウントの独自のコピーを維持することでリクエストのリプレイを検出できるようにすることです。同じnonce-count値が2回見られる場合、リクエストはリプレイです。
If the server considers the s-nonce part of the "nonce" attribute (the "r" attribute) to still be valid (i.e., the nonce-count part is as expected (see above) and the "sr" part is still fresh), it will provide access to the requested resource (assuming the client hash verifies correctly, of course). However, if the server considers that the server part of the nonce is stale (for example, if the "sr" value is used after the "ttl" seconds), the server returns "401 Unauthorized" containing the SCRAM mechanism name with the following attributes: a new "sr", "stale=true", and an optional "ttl". The "stale" attribute signals to the client that there is no need to ask the user for the password.
サーバーが「nonce」属性（「r」属性）のs-nonce部分がまだ有効である（つまり、nonce-count部分が期待どおり（上記を参照）であり、「sr」部分がまだ新鮮である）と見なす場合）、それは要求されたリソースへのアクセスを提供します（もちろん、クライアントのハッシュが正しく検証されると仮定します）。ただし、ナンスのサーバー部分が古くなっているとサーバーが判断した場合（たとえば、「tr」秒の後に「sr」値が使用された場合）、サーバーは次のSCRAMメカニズム名を含む「401 Unauthorized」を返します。属性：新しい「sr」、「stale = true」、およびオプションの「ttl」。 「stale」属性は、ユーザーにパスワードを要求する必要がないことをクライアントに知らせます。
Formally, the "stale" attribute is defined as a flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE (case-insensitive), the client may wish to simply retry the request with a new encrypted response without reprompting the user for a new username and password. The server should only set stale to TRUE if it receives a request for which the nonce is invalid but with a valid digest for that nonce (indicating that the client knows the correct username/password). If stale is FALSE or anything other than TRUE, or the stale directive is not present, the username and/or password are invalid, and new values must be obtained.
正式には、「stale」属性はフラグとして定義されており、nonce値が古くなっているため、クライアントからの前の要求が拒否されたことを示しています。 staleがTRUE（大文字と小文字を区別しない）の場合、クライアントは、ユーザーに新しいユーザー名とパスワードの再入力を求めずに、新しい暗号化された応答で要求を再試行するだけです。サーバーは、nonceが無効であるがそのnonceの有効なダイジェスト（クライアントが正しいユーザー名/パスワードを知っていることを示す）を含む要求を受信した場合にのみ、staleをTRUEに設定する必要があります。 staleがFALSEまたはTRUE以外の場合、またはstaleディレクティブが存在しない場合、ユーザー名またはパスワード、あるいはその両方が無効であり、新しい値を取得する必要があります。
When constructing AuthMessage (see Section 3) to be used for calculating client and server proofs, "client-first-message-bare" and "server-first-message" are reconstructed from data known to the client and the server.
クライアントとサーバーの証明の計算に使用するAuthMessage（セクション3を参照）を構築する場合、「client-first-message-bare」と「server-first-message」は、クライアントとサーバーに既知のデータから再構築されます。
Reauthentication can look like this:
再認証は次のようになります。
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@example.com",
Digest realm="realm2@example.com",
Digest realm="realm3@example.com",
SCRAM-SHA-256 realm="realm3@example.com",
SCRAM-SHA-256 realm="testrealm@example.com", sr=%hvYDpWUa2RaTC
AfuxFIlj)hNlF
SCRAM-SHA-256 realm="testrealm2@example.com", sr=AAABBBCCCDDD,
ttl=120
S: [...]
[The client authenticates as usual to realm "testrealm@example.com"] [Some time later, client decides to reauthenticate. It will use the cached "i" (4096) and "s" (W22ZaJ0SNY7soEsUEjb6gQ==) from earlier exchanges. It will use the nonce-value of 4096 together with the server advertised "sr" value as the server part of the "r".]
[クライアントは通常どおりレルム「testrealm@example.com」に対して認証します] [しばらくして、クライアントは再認証することを決定します。以前の交換でキャッシュされた「i」（4096）と「s」（W22ZaJ0SNY7soEsUEjb6gQ ==）を使用します。 「r」のサーバー部分として、サーバーアドバタイズされた「sr」値と一緒に4096のnonce値を使用します。]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM
lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX
pqZk1IZ3NxbW1pejdBbmRWUT0K
C: [...]
C：[...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: sid=AAAABBBBCCCCDDDD,
data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5N
Uc0PQo=
S: [...Other header fields and resource body...]
When used with SCRAM, the Authentication-Info header field is allowed in the trailer of an HTTP message transferred via chunked transfer-coding.
SCRAMで使用する場合、Authentication-Infoヘッダーフィールドは、チャンク転送コーディングを介して転送されるHTTPメッセージのトレーラーで許可されます。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
次の構文仕様は、[RFC5234]で指定されているAugmented Backus-Naur Form（ABNF）表記を使用しています。
ALPHA = <as defined in RFC 5234 Appendix B.1>
DIGIT = <as defined in RFC 5234 Appendix B.1>
base64-char = ALPHA / DIGIT / "/" / "+"
base64-4 = 4base64-char
base64-3 = 3base64-char "="
単純な4-3 = 3つの単純な4文字 "="
base64-2 = 2base64-char "=="
base64 = *base64-4 [base64-3 / base64-2]
sr = "sr=" s-nonce ;; s-nonce is defined in RFC 5802.
sr = "sr =" s-nonce ;; s-nonceはRFC 5802で定義されています。
data = "data=" base64
;; The "data" attribute value is base64-encoded
;; SCRAM challenge or response defined in
;; RFC 5802.
ttl = "ttl=" 1*DIGIT ;; "sr" value validity in seconds. ;; No leading 0s.
ttl = "ttl =" 1 * DIGIT ;;秒単位の「sr」値の有効性。 ;;先頭に0はありません。
reauth-s-nonce = nonce-count s-nonce
nonce-count = posit-number
;; posit-number is defined in RFC 5802.
;; The initial value is taken from the "i"
;; attribute for the user and is incremented
;; by 1 on each successful reauthentication.
sid = "sid=" token ;; See token definition in RFC 7235.
sid = "sid ="トークン;; RFC 7235のトークン定義を参照してください。
stale = "stale=" ( "true" / "false" )
realm = "realm=" <as defined in RFC 7235>
If the authentication exchange is performed without a strong session encryption (such as TLS with data confidentiality), then a passive eavesdropper can gain sufficient information to mount an offline dictionary or brute-force attack that can be used to recover the user's password. The amount of time necessary for this attack depends on the cryptographic hash function selected, the strength of the password, and the iteration count supplied by the server. SCRAM allows the server/server administrator to increase the iteration count over time in order to slow down the above attacks. (Note that a server that is only in possession of StoredKey and ServerKey can't automatically increase the iteration count upon successful authentication. Such an increase would require resetting the user's password.) An external security layer with strong encryption will prevent these attacks.
強力なセッション暗号化（データの機密性を備えたTLSなど）なしで認証交換が実行される場合、パッシブ盗聴者は、ユーザーのパスワードを回復するために使用できるオフライン辞書またはブルートフォース攻撃をマウントするための十分な情報を入手できます。この攻撃に必要な時間は、選択した暗号化ハッシュ関数、パスワードの強度、およびサーバーから提供された反復回数によって異なります。 SCRAMを使用すると、サーバー/サーバー管理者は、上記の攻撃を遅くするために、時間の経過に伴って反復回数を増やすことができます。 （StoredKeyとServerKeyのみを保持しているサーバーは、認証が成功したときに自動的に反復回数を増やすことができないことに注意してください。このような増加には、ユーザーのパスワードをリセットする必要があります。）強力な暗号化を備えた外部セキュリティレイヤーは、これらの攻撃を防ぎます。
If the authentication information is stolen from the authentication database, then an offline dictionary or brute-force attack can be used to recover the user's password. The use of salt mitigates this attack somewhat by requiring a separate attack on each password. Authentication mechanisms that protect against this attack are available (e.g., the Encrypted Key Exchange (EKE) class of mechanisms). RFC 2945 [RFC2945] is an example of such technology.
認証データベースから認証情報が盗まれた場合、オフライン辞書またはブルートフォース攻撃を使用して、ユーザーのパスワードを回復できます。 saltを使用すると、パスワードごとに個別の攻撃が必要になるため、この攻撃はある程度緩和されます。この攻撃から保護する認証メカニズムが利用可能です（メカニズムの暗号化キー交換（EKE）クラスなど）。 RFC 2945 [RFC2945]は、そのようなテクノロジーの例です。
If an attacker obtains the authentication information from the authentication repository and either eavesdrops on one authentication exchange or impersonates a server, the attacker gains the ability to impersonate that user to all servers providing SCRAM access using the same hash function, password, iteration count, and salt. For this reason, it is important to use randomly generated salt values.
攻撃者が認証リポジトリから認証情報を取得し、1つの認証交換で盗聴するか、サーバーを偽装する場合、攻撃者は同じハッシュ関数、パスワード、反復回数を使用してSCRAMアクセスを提供するすべてのサーバーにそのユーザーを偽装することができます。塩。このため、ランダムに生成されたソルト値を使用することが重要です。
SCRAM does not negotiate which hash function to use. Hash function negotiation is left to the HTTP authentication mechanism negotiation. It is important that clients be able to sort a locally available list of mechanisms by preference so that the client may pick the most preferred of a server's advertised mechanism list. This preference order is not specified here as it is a local matter. The preference order should include objective and subjective notions of mechanism cryptographic strength (e.g., SCRAM with SHA-256 should be preferred over SCRAM with SHA-1).
SCRAMは、使用するハッシュ関数についてネゴシエートしません。ハッシュ関数のネゴシエーションは、HTTP認証メカニズムのネゴシエーションに任されています。クライアントがローカルで利用可能なメカニズムのリストを優先的に並べ替えることができるようにすることが重要です。これにより、クライアントはサーバーのアドバタイズされたメカニズムリストのうち最も好ましいものを選択できます。この優先順位はローカルの問題であるため、ここでは指定しません。優先順位には、メカニズムの暗号強度の客観的および主観的な概念を含める必要があります（たとえば、SHA-256のSCRAMは、SHA-1のSCRAMよりも優先されます）。
This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1 is registered for database compatibility with implementations of RFC 5802 (such as IMAP or XMPP servers) that want to also expose HTTP access to a related service, but it is not recommended for new deployments.
このドキュメントでは、SHA-256ハッシュでSCRAMを使用することを推奨しています。 SCRAM-SHA-1は、関連サービスへのHTTPアクセスも公開する必要があるRFC 5802の実装（IMAPサーバーやXMPPサーバーなど）とのデータベース互換性のために登録されていますが、新しい展開にはお勧めしません。
A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value. In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).
悪意のあるサーバーは、大きなイテレーションカウント値を送信することにより、クライアントに計算サービス拒否攻撃を実行できます。これを防ぐために、クライアント実装は、使用できる最大の反復回数を選択し、そのしきい値を超える値を拒否することができます（このような場合、クライアントはもちろん、認証に失敗する必要があります）。
See [RFC4086] for more information about generating randomness.
ランダム性の生成の詳細については、[RFC4086]を参照してください。
New mechanisms in the SCRAM family are registered according to the IANA procedure specified in [RFC5802].
SCRAMファミリの新しいメカニズムは、[RFC5802]で指定されているIANA手順に従って登録されます。
Note to future "SCRAM-" mechanism designers: Each new "SCRAM-" HTTP authentication mechanism MUST be explicitly registered with IANA and MUST comply with "SCRAM-" mechanism naming convention defined in Section 4 of this document.
今後の「SCRAM-」メカニズム設計者への注意：新しい「SCRAM-」HTTP認証メカニズムはそれぞれ、IANAに明示的に登録されなければならず、このドキュメントのセクション4で定義された「SCRAM-」メカニズム命名規則に準拠しなければなりません。
IANA has added the following entries to the "HTTP Authentication Schemes" registry defined in HTTP/1.1, Part 7 [RFC7235]:
IANAは、HTTP / 1.1、パート7 [RFC7235]で定義されている「HTTP認証方式」レジストリに次のエントリを追加しました。
Authentication Scheme Name: SCRAM-SHA-256 Pointer to specification text: RFC 7804 Notes (optional): (none)
認証方式名：SCRAM-SHA-256仕様テキストへのポインター：RFC 7804注（オプション）：（なし）
Authentication Scheme Name: SCRAM-SHA-1 Pointer to specification text: RFC 7804 Notes (optional): (none)
認証方式名：SCRAM-SHA-1仕様テキストへのポインター：RFC 7804注釈（オプション）：（なし）
The following design goals shaped this document. Note that some of the goals have changed since the initial draft version of the document.
次の設計目標は、このドキュメントを形成しました。ドキュメントの最初のドラフトバージョン以降、いくつかの目標が変更されていることに注意してください。
o The HTTP authentication mechanism has all modern features: support for internationalized usernames and passwords.
o HTTP認証メカニズムには、国際化されたユーザー名とパスワードのサポートなど、最新の機能がすべて備わっています。
o The protocol supports mutual authentication.
o プロトコルは相互認証をサポートします。
o The authentication information stored in the authentication database is not sufficient by itself to impersonate the client.
o 認証データベースに格納されている認証情報だけでは、クライアントを偽装するには不十分です。
o The server does not gain the ability to impersonate the client to other servers (with an exception for server-authorized proxies), unless such other servers allow SCRAM authentication and use the same salt and iteration count for the user.
o 他のサーバーがSCRAM認証を許可し、ユーザーに同じソルトとイテレーションカウントを使用しない限り、サーバーはクライアントを他のサーバーに偽装する機能を獲得しません（サーバー承認プロキシを除く）。
o The mechanism is extensible, but (hopefully) not over-engineered in this respect.
o メカニズムは拡張可能ですが、（うまくいけば）この点で過度に設計されていません。
o The mechanism is easier to implement than HTTP Digest in both clients and servers.
o このメカニズムは、クライアントとサーバーの両方でHTTPダイジェストよりも実装が簡単です。
o The protocol supports 1 round-trip reauthentication.
o このプロトコルは、1回のラウンドトリップ再認証をサポートしています。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：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]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, <http://www.rfc-editor.org/info/rfc5802>.
[RFC5802]ニューマン、C。、メノンセン、A。、メルニコフ、A。、およびN.ウィリアムズ、「ソルトチャレンジレスポンス認証メカニズム（SCRAM）SASLおよびGSS-APIメカニズム」、RFC 5802、DOI 10.17487 / RFC5802、 2010年7月、<http://www.rfc-editor.org/info/rfc5802>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<http：//www.rfc- editor.org/info/rfc6234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.
[RFC7613] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 7613、DOI 10.17487 / RFC7613、2015年8月、<http：//www.rfc- editor.org/info/rfc7613>。
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>.
[RFC7615] Reschke、J。、「HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields」、RFC 7615、DOI 10.17487 / RFC7615、2015年9月、<http://www.rfc-editor.org/info/ rfc7615>。
[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", RFC 7677, DOI 10.17487/RFC7677, November 2015, <http://www.rfc-editor.org/info/rfc7677>.
[RFC7677] Hansen、T。、「SCRAM-SHA-256およびSCRAM-SHA-256-PLUS単純認証およびセキュリティ層（SASL）メカニズム」、RFC 7677、DOI 10.17487 / RFC7677、2015年11月、<http：// www .rfc-editor.org / info / rfc7677>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<http：/ /www.rfc-editor.org/info/rfc2865>。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, <http://www.rfc-editor.org/info/rfc2898>.
[RFC2898] Kaliski、B。、「PKCS＃5：Password-Based Cryptography Specification Version 2.0」、RFC 2898、DOI 10.17487 / RFC2898、2000年9月、<http://www.rfc-editor.org/info/rfc2898> 。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, DOI 10.17487/RFC2945, September 2000, <http://www.rfc-editor.org/info/rfc2945>.
[RFC2945] Wu、T。、「The SRP Authentication and Key Exchange System」、RFC 2945、DOI 10.17487 / RFC2945、2000年9月、<http://www.rfc-editor.org/info/rfc2945>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, DOI 10.17487/RFC4510, June 2006, <http://www.rfc-editor.org/info/rfc4510>.
[RFC4510] Zeilenga、K。、編、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ」、RFC 4510、DOI 10.17487 / RFC4510、2006年6月、<http://www.rfc-editor.org/ info / rfc4510>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, DOI 10.17487/RFC6331, July 2011, <http://www.rfc-editor.org/info/rfc6331>.
[RFC6331] Melnikov、A。、「Moving DIGEST-MD5 to Historic」、RFC 6331、DOI 10.17487 / RFC6331、2011年7月、<http://www.rfc-editor.org/info/rfc6331>。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", June 2015, <http://www.unicode.org/reports/tr15/>.
[Unicode-UAX15] Unicodeコンソーシアム、「Unicode Standard Annex＃15：Unicode Normalization Forms」、2015年6月、<http://www.unicode.org/reports/tr15/>。
Acknowledgements
謝辞
This document benefited from discussions on the mailing lists for the HTTPAuth, SASL, and Kitten working groups. The author would like to specially thank the co-authors of [RFC5802] from which lots of text was copied.
このドキュメントは、HTTPAuth、SASL、およびKittenワーキンググループのメーリングリストでの議論の恩恵を受けました。多くのテキストがコピーされた[RFC5802]の共著者に特に感謝します。
Thank you to Martin Thomson for the idea of adding the "ttl" attribute.
"ttl"属性を追加するアイデアを提供してくれたMartin Thomsonに感謝します。
Thank you to Julian F. Reschke for corrections regarding use of the Authentication-Info header field.
Authentication-Infoヘッダーフィールドの使用に関する修正について、Julian F. Reschkeに感謝します。
A special thank you to Tony Hansen for doing an early implementation and providing extensive comments on the document.
初期の実装を行い、ドキュメントに広範なコメントを提供してくれたTony Hansenに特に感謝します。
Thank you to Russ Housley, Stephen Farrell, Barry Leiba, and Tim Chown for doing detailed reviews of the document.
文書の詳細なレビューを行ってくれたRuss Housley、Stephen Farrell、Barry Leiba、Tim Chownに感謝します。
Author's Address
著者のアドレス
Alexey Melnikov Isode Ltd
Alexey Melnikov Isode Ltd
Email: Alexey.Melnikov@isode.com