Internet Engineering Task Force (IETF) C. Newman
Request for Comments: 5802 Oracle
Category: Standards Track A. Menon-Sen
ISSN: 2070-1721 Oryx Mail Systems GmbH
A. Melnikov
Isode, Ltd.
N. Williams
Oracle
July 2010
Salted Challenge Response Authentication Mechanism (SCRAM)
SASL and GSS-API Mechanisms
Abstract
抽象
The secure 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 challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.
安全な認証メカニズムで最も広く展開し、インターネットアプリケーションプロトコルによって使用されるには、トランスポート層セキュリティ（TLS）によって保護されたチャネルを介してクリアテキストのパスワードを送信することです。 TLSで保護されたチャレンジ・レスポンス認証メカニズムを使用することによって対処することができ、そのメカニズムを持ついくつかの重要なセキュリティ上の問題があります。残念ながら、現在の規格上のチャレンジレスポンスメカニズムは、すべてが普及展開するために必要な要件を満たしていない、とだけ限定的に使用して成功を収めている追跡します。
This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards.
この仕様は、簡易認証セキュリティー層の家族記述する（SASLを、RFC 4422）認証メカニズムは、セキュリティ上の懸念に対処し、展開性の要件を満たしている塩漬けチャレンジレスポンス認証メカニズム（SCRAM）と呼ばれます。 TLSまたは同等のセキュリティ層と組み合わせて使用する場合は、この家族からのメカニズムは、アプリケーションプロトコルの認証のための現状を改善し、将来のアプリケーションプロトコル規格の実装に必須のメカニズムのための適切な選択を提供することができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5802.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5802で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Notation ...................................................6
3. SCRAM Algorithm Overview ........................................7
4. SCRAM Mechanism Names ...........................................8
5. SCRAM Authentication Exchange ...................................9
5.1. SCRAM Attributes ..........................................10
5.2. Compliance with SASL Mechanism Requirements ...............13
6. Channel Binding ................................................14
6.1. Default Channel Binding ...................................15
7. Formal Syntax ..................................................15
8. SCRAM as a GSS-API Mechanism ...................................19
8.1. GSS-API Principal Name Types for SCRAM ....................19
8.2. GSS-API Per-Message Tokens for SCRAM ......................20
8.3. GSS_Pseudo_random() for SCRAM .............................20
9. Security Considerations ........................................20
10. IANA Considerations ...........................................22
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Normative References for GSS-API Implementors ............24
12.3. Informative References ...................................25
Appendix A. Other Authentication Mechanisms .......................27
Appendix B. Design Motivations ....................................27
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 Appendix A and Appendix B). When used in combination with Transport Layer Security (TLS; see [RFC5246]) or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards.
この仕様は、より広く、過去の試みよりチャレンジレスポンスメカニズムを展開するために必要な要件に対応塩漬けチャレンジレスポンス認証メカニズム（SCRAM）（付録Aと付録Bを参照）と呼ばれる認証メカニズムのファミリーを記載しています。トランスポート層セキュリティ（TLS; [RFC5246]を参照）と組み合わせて使用する場合または同等のセキュリティ層、この家族からのメカニズムは、アプリケーションプロトコルの認証のために現状を改善し、ための実装に必須のメカニズムのための適切な選択を提供することができ将来のアプリケーションプロトコル標準。
For simplicity, this family of mechanisms does not presently include negotiation of a security layer [RFC4422]. It is intended to be used with an external security layer such as that provided by TLS or SSH, with optional channel binding [RFC5056] to the external security layer.
簡単にするために、メカニズムのこのファミリは、現在のセキュリティレイヤ[RFC4422]の交渉が含まれていません。外部のセキュリティ層への任意のチャンネル結合[RFC5056]を用いて、そのようなTLSまたはSSHによって提供されるような外部セキュリティ層を使用することを意図されています。
SCRAM is specified herein as a pure Simple Authentication and Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new bridge between SASL and the Generic Security Service Application Program Interface (GSS-API) called "GS2" [RFC5801]. This means that this document defines both, a SASL mechanism and a GSS-API mechanism.
SCRAMは、純粋な簡易認証セキュリティー層（SASL）[RFC4422]メカニズムとしてここに指定されているが、それはSASLと「GS2」[RFC5801]と呼ばれる一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）との間に新しい橋に準拠しています。これは、このドキュメントでは、両方の、SASLメカニズムとGSS-APIメカニズムを定義することを意味します。
SCRAM provides the following protocol features:
SCRAMは、以下のプロトコルの機能を提供します。
o The authentication information stored in the authentication database is not sufficient by itself to impersonate the client. The information is salted to prevent 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).
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相互認証がサポートされているが、唯一のクライアントが命名された（すなわち、サーバは名前がありません）。
o When used as a SASL mechanism, SCRAM is capable of transporting authorization identities (see [RFC4422], Section 2) from the client to the server.
SASLメカニズムとして使用する場合は、O、SCRAMは、クライアントからサーバへ（[RFC4422]、セクション2を参照）の認可アイデンティティを輸送することができます。
A separate document defines a standard LDAPv3 [RFC4510] attribute that enables storage of the SCRAM authentication information in LDAP. See [RFC5803].
別の文書は、LDAPにSCRAM認証情報の格納を可能にする標準のLDAPv3 [RFC4510]の属性を定義します。 [RFC5803]を参照してください。
For an in-depth discussion of why other challenge response mechanisms are not considered sufficient, see Appendix A. For more information about the motivations behind the design of this mechanism, see Appendix B.
他のチャレンジ応答メカニズムが十分考慮されていない理由の詳細な議論については、付録Bを参照してください、このメカニズムの設計の背後にある動機についての詳細は、付録Aを参照してください。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "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 [RFC4949] ("Internet Security Glossary") 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]（「インターネットセキュリティ用語集」）で定義されているいくつかの用語を使用しています、のman-in-the-middle、ナンス、一方向暗号化機能、パスワード、リプレイ攻撃、および塩。これらの用語に慣れていない読者は、参照としてその用語集を使用する必要があります。
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, "StoredKey" and "ServerKey" (as defined in the algorithm overview) for each supported cryptographic hash function.
O認証情報：SCRAMクライアントによって要求されたアイデンティティを検証するために使用される情報。 SCRAMアイデンティティの認証情報は、サポートされている各暗号ハッシュ関数のために（アルゴリズムの概要で定義される）塩、繰り返し回数、「StoredKey」および「サーバキー」から成ります。
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
O認証データベース：特定のIDに関連付けられた認証情報を検索するために使用するデータベース。アプリケーションプロトコルのために、LDAPv3のは（[RFC4510]を参照）頻繁に
used as the authentication database. For network-level protocols such as PPP or 802.11x, the use of RADIUS [RFC2865] is more common.
認証データベースとして使用します。そのようなPPPまたは802.11xのようなネットワーク・レベルのプロトコルのために、RADIUS [RFC2865]の使用がより一般的です。
o Base64: An encoding mechanism defined in [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]で定義された符号化メカニズム。 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 notations:
アルゴリズムの擬似コード記述は以下の表記法を使用しています：
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 "]" may not be included in the result under some circumstances. See the associated text for a description of those circumstances.
O「[]」で囲まれた表現の部分「[」と「]」いくつかの状況下で、結果に含まれていなくてもよいです。このような状況の説明については、関連するテキストを参照してください。
o Normalize(str): Apply the SASLprep profile [RFC4013] of the "stringprep" algorithm [RFC3454] as the normalization algorithm to a UTF-8 [RFC3629] encoded "str". The resulting string is also in UTF-8. When applying SASLprep, "str" is treated as a "stored strings", which means that unassigned Unicode codepoints are prohibited (see Section 7 of [RFC3454]). Note that implementations MUST either implement SASLprep or disallow use of non US-ASCII Unicode codepoints in "str".
Oノーマライズ（STR）は：UTF-8 [RFC3629]に正規化アルゴリズムが "STR" に符号化される "文字列準備" アルゴリズム[RFC3454]のSASLprepプロファイル[RFC4013]を適用します。結果の文字列はUTF-8でもあります。 SASLprepを適用する場合、「STR」が割り当てられていないのUnicodeコードポイントが禁止されることを意味し、「保存された文字列」、（[RFC3454]のセクション7を参照）として扱われます。実装がSASLprepを実装するか、「STR」内の非US-ASCII Unicodeのコードポイントの使用を禁止しなければならないのいずれかのことに注意してください。
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 20 octets for SHA-1 (see [RFC3174]).
O HMAC（キー、STR）：入力文字列としてキーとオクテット列「STR」と「キー」で表されるオクテットストリングを使用して（[RFC2104]で定義される）HMAC鍵付きハッシュアルゴリズムを適用します。結果のサイズは、使用されているハッシュ関数のハッシュ結果のサイズです。例えば、（[RFC3174]を参照）、SHA-1の20オクテットです。
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.
XOR○：この演算子の右側のオクテット文字列で、この演算子の左側のオクテット文字列を結合する排他的論理和演算を適用します。出力の長さと2つの入力のそれぞれは、この用途のために同じです。
o Hi(str, salt, i):
こんにちはO（STR、塩、I）：
U1 := HMAC(str, salt + INT(1)) U2 := HMAC(str, U1) ... Ui-1 := HMAC(str, Ui-2) Ui := HMAC(str, Ui-1)
U1 = U2 HMAC = HMAC（STR、U1）... UI-1 = HMAC（STR、UI-2）U = HMAC（STR、UI-1）（STR + INT（1）ジャンプ）
Hi := U1 XOR U2 XOR ... XOR Ui
こんにちは：= U1 XOR U2 XOR ... XOR宇井
where "i" is the iteration count, "+" is the string concatenation operator, and INT(g) is a 4-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（）、HMAC（）擬似ランダム関数（PRF）として、およびHMACのdkLen ==出力長（と）Hの==出力長（）と本質的に、PBKDF2 [RFC2898]です。
The following is a description of a full, uncompressed SASL SCRAM authentication exchange. Nothing in SCRAM prevents either sending the client-first message with the SASL authentication request defined by an application protocol ("initial client response"), or sending the server-final message as additional data of the SASL outcome of authentication exchange defined by an application protocol. See [RFC4422] for more details.
以下は、完全な、圧縮されていないSASL SCRAMの認証交換の記述です。 SCRAMに何もいずれかのアプリケーションプロトコル（「初期のクライアント応答」）によって定義されたSASL認証要求にクライアント最初のメッセージを送信しない、またはアプリケーションによって定義された認証交換のSASL転帰の付加データとしてサーバ最終的なメッセージを送信することを防止しますプロトコル。詳細については、[RFC4422]を参照してください。
Note that this section omits some details, such as client and server nonces. See Section 5 for more details.
このセクションでは、クライアントとサーバのナンスなどいくつかの詳細を、省略することに注意してください。詳細は、第5章を参照してください。
To begin with, the SCRAM client is in possession of a username and password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends the username to the server, which retrieves the corresponding authentication information, i.e., a salt, StoredKey, ServerKey, and the 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クライアントは、ユーザー名とパスワード（*）（またはClientKey /サーバキー、またはSaltedPassword）を所有しています。これは、対応する認証情報、すなわち、塩、StoredKey、サーバキー、および反復回数Iを取得し、サーバにユーザ名を送信します。 （サーバーの実装は、すべてのアカウントに同じ反復回数を使用するように選択することがあります。）サーバは、塩、その後、次の値を計算し、サーバにClientProofを送信し、クライアントへの反復回数を送信します。
(*) Note that both the username and the password MUST be encoded in UTF-8 [RFC3629].
（*）ユーザ名とパスワードの両方がUTF-8 [RFC3629]で符号化されなければならないことに留意されたいです。
Informative Note: Implementors are encouraged to create test cases that use both usernames and passwords with non-ASCII codepoints. In particular, it's useful to test codepoints whose "Unicode Normalization Form C" and "Unicode Normalization Form KC" are different. Some examples of such codepoints include Vulgar Fraction One Half (U+00BD) and Acute Accent (U+00B4).
有益な注意：実装者は、非ASCIIコードポイントでユーザー名とパスワードの両方を使用してテストケースを作成することをお勧めします。特に、それは、「Unicode正規化形式C」と「Unicodeの正規化形式KC」は異なっているそのコードポイントをテストするために便利です。そのようなコードポイントのいくつかの例は、常分数半分（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)
SaltedPassword：=こんにちは（ノーマライズ（パスワード）、塩、I）ClientKey：= HMAC（SaltedPassword、 "クライアントキー"）StoredKey：= H（ClientKey）AuthMessage：=クライアント・ファースト・メッセージ裸+ "" +サーバ - 最初のメッセージ+ "" +クライアント - 最終メッセージなしプルーフClientSignature：= HMAC（StoredKey、AuthMessage）ClientProof：= ClientKey XOR ClientSignatureサーバキー：= HMAC（SaltedPassword、 "サーバキー"）ServerSignature：= HMAC（サーバキー、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.
サーバーはClientProofでClientKeyを回復することClientSignature、排他的論理和を計算し、ハッシュ関数を適用し、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, it proves that the server had access to the user's ServerKey.
同様に、クライアントはServerSignatureを計算し、サーバによって送信された値と比較することによって、サーバを認証します。 2が等しい場合は、サーバがユーザのサーバキーへのアクセス権を持っていたことを証明しています。
The AuthMessage is computed by concatenating messages from the authentication exchange. The format of these messages is defined in Section 7.
AuthMessageは、認証交換からのメッセージを連結することにより計算されます。これらのメッセージの形式はセクション7で定義されています。
A SCRAM mechanism name 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), optionally followed by the suffix "-PLUS" (see below). Note that SASL mechanism names are limited to 20 octets, which means that only hash function names with lengths shorter or equal to 9 octets (20-length("SCRAM-")-length("-PLUS") can be used. For cases when the underlying hash function name is longer than 9 octets, an alternative 9-octet (or shorter) name can be used to construct the corresponding SCRAM mechanism name, as long as this alternative name doesn't conflict with any other hash function name from the IANA "Hash Function Textual Names" registry. In order to prevent future conflict, such alternative names SHOULD be registered in the IANA "Hash Function Textual Names" registry.
スクラム・メカニズム名は、オプションの接尾辞に続いて、（http://www.iana.orgを参照）、レジストリIANA「ハッシュ関数テキスト名」から取られた基本的なハッシュ関数の大文字名が続く文字列「SCRAM-」であります"-Plus"（下記参照）。ケース用）を使用することができる） - - 長さ（「プラス」。 - より短い又は9つのオクテット（20長さ（「SCRAM」に等しい長さだけ、ハッシュ関数名があることを意味名前が20個のオクテットに限定されるSASL機構を、注意してください基礎となるハッシュ関数名は9つのオクテット、代替9オクテット（または短い）名よりも長い場合に限り、この代替名が他のハッシュ関数名からと競合しないように、対応するSCRAM機構名を構築することができますIANA「ハッシュ関数テキスト名」レジストリ。将来の紛争を防ぐために、そのような代替名はIANA「ハッシュ関数テキスト名」レジストリに登録する必要があります。
For interoperability, all SCRAM clients and servers MUST implement the SCRAM-SHA-1 authentication mechanism, i.e., an authentication mechanism from the SCRAM family that uses the SHA-1 hash function as defined in [RFC3174].
相互運用性のために、すべてのSCRAMクライアントとサーバは、SCRAM-SHA-1認証機構を実装する必要があり、すなわち、[RFC3174]で定義されるようにSHA-1ハッシュ関数を使用SCRAMファミリーからの認証メカニズム。
The "-PLUS" suffix is used only when the server supports channel binding to the external channel. If the server supports channel binding, it will advertise both the "bare" and "plus" versions of whatever mechanisms it supports (e.g., if the server supports only SCRAM with SHA-1, then it will advertise support for both SCRAM-SHA-1 and SCRAM-SHA-1-PLUS). If the server does not support channel binding, then it will advertise only the "bare" version of the mechanism (e.g., only SCRAM-SHA-1). The "-PLUS" exists to allow negotiation of the use of channel binding. See Section 6.
「-Plus」サフィックスは、サーバーが外部チャネルへの結合チャネルをサポートしている場合にのみ使用されます。サーバは、チャネルバインディングをサポートしている場合、サーバーはSHA-1を有する唯一のSCRAMをサポートしている場合、それは、例えばそれがサポートするどんなメカニズム（の「裸」と「プラス」バージョンの両方をアドバタイズします、それは両方のSCRAM-SHA-のサポートをアドバタイズします1とSCRAM-SHA-1-PLUS）。サーバはチャネル結合をサポートしていない場合、それは機構の唯一の「裸の」バージョン（例えば、唯一SCRAM-SHA-1）をアドバタイズします。 「-Plusは、」チャネルバインディングの使用の交渉を許可するように存在しています。第6章を参照してください。
SCRAM is a SASL mechanism whose client response and server challenge messages are text-based messages containing one or more attribute-value pairs separated by commas. Each attribute has a one-letter name. The messages and their attributes are described in Section 5.1, and defined in Section 7.
SCRAMは、そのクライアントのレスポンスとサーバのチャレンジメッセージをカンマで区切られた1つ以上の属性と値のペアを含むテキストベースのメッセージですSASLメカニズムです。各属性は、1文字の名前を持っています。メッセージとその属性は、セクション5.1で説明され、第7節で定義されています。
SCRAM is a client-first SASL mechanism (see [RFC4422], Section 5, item 2a), and returns additional data together with a server's indication of a successful outcome.
SCRAMは、クライアント最初のSASL機構である（[RFC4422]、セクション5、項目2Aを参照）、成功した結果のサーバの指示と一緒に追加のデータを返します。
This is a simple example of a SCRAM-SHA-1 authentication exchange when the client doesn't support channel bindings (username 'user' and password 'pencil' are used):
これは、クライアントがチャネルバインディング（ユーザー名「ユーザー」とパスワード「鉛筆」が使用されている）をサポートしていませんSCRAM-SHA-1認証交換の簡単な例です：
C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92, i=4096 C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Q：N ,, N =ユーザー、R = fyko + d2lbbFgONRv9qkxdawL S：R = fyko + d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j、S = QSXCR + Q6sek8bf92、I = 4096 C：C =紫、R = fyko + d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j、P = S = v0X8v3Bz2T0CJGbJQyF0X + HI4Ts ：V = rmF9pqV8S7suAoZWja4dJRkFsKQ =
First, the client sends the "client-first-message" containing:
まず、クライアントが含む「クライアント・ファースト・メッセージ」を送信します。
o a GS2 header consisting of a flag indicating whether channel binding is supported-but-not-used, not supported, or used, and an optional SASL authorization identity;
結合チャネルがサポートされている、しかし、利用されていないかどうかを示すフラグからなるGS2ヘッダは、サポートされている、または使用しない、O、および任意のSASL認証アイデンティティ。
o SCRAM username and a random, unique nonce attributes.
O SCRAMのユーザー名とランダムな、ユニークなナンス属性。
Note that the client's first message will always start with "n", "y", or "p"; otherwise, the message is invalid and authentication MUST fail. This is important, as it allows for GS2 extensibility (e.g., to add support for security layers).
クライアントの最初のメッセージは、常に「n」は、「Y」、または「P」で始まることに注意してください。そうでない場合、メッセージは無効であり、認証が失敗しなければなりません。それはGS2の拡張（例えば、セキュリティ層のためのサポートを追加すること）が可能になり、これは重要です。
In response, the server sends a "server-first-message" containing the user's iteration count i and the user's salt, and appends its own nonce to the client-specified one.
応答では、サーバーはユーザーの繰り返し回数iと、ユーザの塩を含有する「サーバー・ファースト・メッセージ」を送信し、クライアントが指定したものに、独自のnonceを追加します。
The client then responds by sending a "client-final-message" with the same nonce and a ClientProof computed using the selected hash function as explained earlier.
クライアントは、同じノンスと先に説明したように選択されたハッシュ関数を用いて計算ClientProofと「クライアント最終メッセージ」を送信することによって応答します。
The server verifies the nonce and the proof, verifies that the authorization identity (if supplied by the client in the first message) is authorized to act as the authentication identity, and, finally, it responds with a "server-final-message", concluding the authentication exchange.
サーバは、ナンスや証拠を検証し、認可アイデンティティは（最初のメッセージには、クライアントによって提供されている場合）、認証IDとして行動する権限を与えていることを確認し、そして、最終的には、それが「サーバー・ファイナル・メッセージ」で応答し、認証交換を締結。
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が異なる場合、クライアントは認証交換が失敗であることを考慮しなければならない、そしてそれは、接続をドロップする必要がある場合があります。
This section describes the permissible attributes, their use, and the format of their values. All attribute names are single US-ASCII letters and are case-sensitive.
このセクションでは、許容属性、その使用、およびその値の形式について説明します。すべての属性名は、単一のUS-ASCII文字で、大文字と小文字が区別されます。
Note that the order of attributes in client or server messages is fixed, with the exception of extension attributes (described by the "extensions" ABNF production), which can appear in any order in the designated positions. See Section 7 for authoritative reference.
指定された位置に、任意の順序で表示されます（「拡張子」ABNF生産によって記述）拡張属性を除いて、クライアントまたはサーバのメッセージ内の属性の順序が固定されていることに注意してください。権威の参照については、セクション7を参照してください。
o a: This is an optional attribute, and is part of the GS2 [RFC5801] bridge between the GSS-API and SASL. This attribute specifies an authorization identity. A client may include it in its first message to the server if it wants to authenticate as one user, but subsequently act as a different user. This is typically used by an administrator to perform some management task on behalf of another user, or by a proxy in some situations.
O：これはオプションの属性であり、GSS-APIとSASL間GS2 [RFC5801]ブリッジの一部です。この属性は、認可IDを指定します。クライアントは1人のユーザーとして認証したい場合は、サーバーへの最初のメッセージに含めるが、その後別のユーザーとして作用することができます。これは通常、別のユーザーに代わって、またはいくつかの状況でプロキシによっていくつかの管理タスクを実行するには、管理者によって使用されます。
Upon the receipt of this value the server verifies its
correctness according to the used SASL protocol profile.
Failed verification results in failed authentication exchange.
If this attribute is omitted (as it normally would be), the authorization identity is assumed to be derived from the username specified with the (required) "n" attribute.
（それが通常であるように）この属性が省略された場合、認可ID（必須）「N」属性で指定されたユーザ名に由来しているものとします。
The server always authenticates the user specified by the "n" attribute. If the "a" attribute specifies a different user, the server associates that identity with the connection after successful authentication and authorization checks.
サーバーは常に「n」は属性で指定したユーザーを認証します。 「」属性が別のユーザーを指定した場合、サーバは成功した認証と承認のチェック後に接続して、そのIDを関連付けます。
The syntax of this field is the same as that of the "n" field with respect to quoting of '=' and ','.
このフィールドの構文は、「」「=」の引用に関して、「N」フィールドと同じです。
o n: This attribute specifies the name of the user whose password is used for authentication (a.k.a. "authentication identity" [RFC4422]). A client MUST include it in its first message to the server. If the "a" attribute is not specified (which would normally be the case), this username is also the identity that will be associated with the connection subsequent to authentication and authorization.
N O：この属性は、パスワード認証（別称、「認証アイデンティティ」[RFC4422]）のために使用されているユーザーの名前を指定します。クライアントは、サーバーへの最初のメッセージにそれを含まなければなりません。 「」属性が（通常のケースであると思われる）が指定されていない場合は、このユーザ名は、認証と承認の後に、接続に関連付けられますIDです。
Before sending the username to the server, the client SHOULD
prepare the username using the "SASLprep" profile [RFC4013] of
the "stringprep" algorithm [RFC3454] treating it as a query
string (i.e., unassigned Unicode code points are allowed). If
the preparation of the username fails or results in an empty
string, the client SHOULD abort the authentication exchange
(*).
(*) An interactive client can request a repeated entry of the username value.
（*）、対話型クライアントは、ユーザー名値の繰り返し入力を要求することができます。
Upon receipt of the username by the server, the server MUST either prepare it using the "SASLprep" profile [RFC4013] of the "stringprep" algorithm [RFC3454] treating it as a query string (i.e., unassigned Unicode codepoints are allowed) or otherwise be prepared to do SASLprep-aware string comparisons and/or index lookups. If the preparation of the username fails or results in an empty string, the server SHOULD abort the authentication exchange. Whether or not the server prepares the username using "SASLprep", it MUST use it as received in hash calculations.
サーバによるユーザ名を受信すると、サーバはクエリ文字列として扱い、「文字列準備」アルゴリズム[RFC3454]の「SASLprep」プロファイル[RFC4013]を使用して作成しなければならないのいずれか（すなわち、未割り当てのUnicodeコードポイントが許可されている）、またはそうでなければ文字列の比較および/またはインデックス検索SASLprep認識を行うために準備します。ユーザ名の準備が失敗した場合や、空の文字列での結果ならば、サーバーは認証交換を中止すべきです。ハッシュ計算で受信したサーバは「SASLprep」を使用して、ユーザー名を用意するかどうかにかかわらず、それを使用しなければなりません。
The characters ',' or '=' in usernames are sent as '=2C' and '=3D' respectively. If the server receives a username that contains '=' not followed by either '2C' or '3D', then the server MUST fail the authentication.
ユーザ名の文字は、「」または 『=』は、それぞれ 『= 2C』と 『= 3D』として送信されます。サーバは「=」が含まれたユーザ名を受信した場合のいずれかの「2C」または「3D」が続いていない場合、サーバーは認証が失敗しなければなりません。
o m: This attribute is reserved for future extensibility. In this version of SCRAM, its presence in a client or a server message MUST cause authentication failure when the attribute is parsed by the other end.
OのM：この属性は将来の拡張のために予約されています。属性はもう一方の端によって解析されたときにSCRAMのこのバージョンでは、クライアントまたはサーバ・メッセージ中のその存在は、認証の失敗の原因としなければなりません。
o r: This attribute specifies a sequence of random printable ASCII characters excluding ',' (which forms the nonce used as input to the hash function). No quoting is applied to this string. As described earlier, the client supplies an initial value in its first message, and the server augments that value with its own nonce in its first response. It is important that this value be different for each authentication (see [RFC4086] for more details on how to achieve this). The client MUST verify that the initial part of the nonce used in subsequent messages is the same as the nonce it initially specified. The server MUST verify that the nonce sent by the client in the second message is the same as the one sent by the server in its first message.
R O：この属性は、（ハッシュ関数への入力として使用ナンスを形成する）「」を除くランダム印字可能なASCII文字列を指定します。何引用は、この文字列には適用されません。前述したように、クライアントは、その最初のメッセージに初期値を供給し、サーバがその最初の応答では、独自のnonceとその値を強化します。この値は、各認証のために異なること（これを達成する方法の詳細については、[RFC4086]を参照）ことが重要です。クライアントは、後続のメッセージで使用されるナンスの最初の部分は、それが最初に指定されたナンスと同じであることを確かめなければなりません。サーバは、第2のメッセージ内のクライアントによって送信されたナンスは、その最初のメッセージでサーバから送信されたものと同じであることを確認しなければなりません。
o c: This REQUIRED attribute specifies the base64-encoded GS2 header and channel binding data. It is sent by the client in its second authentication message. The attribute data consist of:
入出力C：この必須属性は、base64エンコードGS2ヘッダおよびチャネル結合データを特定します。それは、その第二認証メッセージ内のクライアントによって送信されます。属性データは、から構成されます。
* the GS2 header from the client's first message (recall that the GS2 header contains a channel binding flag and an optional authzid). This header is going to include channel binding type prefix (see [RFC5056]), if and only if the client is using channel binding;
*クライアントの最初のメッセージからGS2ヘッダは（GS2ヘッダはチャネル結合フラグと任意authzidはが含まれていることを思い出してください）。そして、クライアントは結合チャネルを使用している場合にのみ場合は、このヘッダには、（[RFC5056]を参照）タイププレフィックスを結合チャネルを含むしようとしています。
* followed by the external channel's channel binding data, if and only if the client is using channel binding.
そして、クライアントは結合チャネルを使用している場合にだけ*、外部チャネルのチャネルバインディングデータが続きます。
o s: This attribute specifies the base64-encoded salt used by the server for this user. It is sent by the server in its first message to the client.
O S：この属性は、ユーザーのために、サーバが使用するbase64でエンコードされた塩を指定します。これは、クライアントへの最初のメッセージには、サーバによって送信されます。
o i: This attribute specifies an iteration count for the selected hash function and user, and MUST be sent by the server along with the user's salt.
O I：この属性は、選択したハッシュ関数とユーザーのための繰り返し回数を指定し、ユーザの塩と一緒にサーバによって送らなければなりません。
For the SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism, servers
SHOULD announce a hash iteration-count of at least 4096. Note
that a client implementation MAY cache ClientKey&ServerKey (or
just SaltedPassword) for later reauthentication to the same
service, as it is likely that the server is going to advertise
the same salt value upon reauthentication. This might be
useful for mobile clients where CPU usage is a concern.
o p: This attribute specifies a base64-encoded ClientProof. The client computes this value as described in the overview and sends it to the server.
OのP：この属性は、base64エンコードClientProofを指定します。クライアントは、概要で説明したように、この値を計算し、それをサーバーに送信します。
o v: This attribute specifies a base64-encoded ServerSignature. It is sent by the server in its final message, and is used by the client to verify that the server has access to the user's authentication information. This value is computed as explained in the overview.
O V：この属性は、base64エンコードServerSignatureを指定します。それは、最終的なメッセージにサーバによって送信され、サーバがユーザの認証情報へのアクセス権を持っていることを確認するために、クライアントによって使用されます。概要で説明したように、この値が計算されます。
o e: This attribute specifies an error that occurred during authentication exchange. It is sent by the server in its final message and can help diagnose the reason for the authentication exchange failure. On failed authentication, the entire server-final-message is OPTIONAL; specifically, a server implementation MAY conclude the SASL exchange with a failure without sending the server-final-message. This results in an application-level error response without an extra round-trip. If the server-final-message is sent on authentication failure, then the "e" attribute MUST be included.
O E：この属性は、認証交換中に発生したエラーを指定します。それは、最終的なメッセージにサーバによって送信され、認証交換の失敗の原因を診断するのに役立ちます。失敗した認証では、サーバ全体-最終メッセージはオプションです。具体的には、サーバの実装は、サーバ最終メッセージを送信せず故障とSASL交換を結論付けることができます。これは、余分なラウンドトリップすることなく、アプリケーション・レベルのエラー応答をもたらします。サーバー・ファイナル・メッセージが認証失敗で送信されている場合は、「e」の属性が含まれなければなりません。
o As-yet unspecified mandatory and optional extensions. Mandatory extensions are encoded as values of the 'm' attribute (see ABNF for reserved-mext in section 7). Optional extensions use as-yet unassigned attribute names.
AS-まだ未指定の必須およびオプションの拡張O。必須の拡張は（セクション7に貯留、文部科学省のためのABNFを参照）「M」属性の値として符号化されます。オプションの拡張機能は、AS-まだ割り当てられていない属性名を使用します。
Mandatory extensions sent by one peer but not understood by the other MUST cause authentication failure (the server SHOULD send the "extensions-not-supported" server-error-value).
一方のピアによって送信されたが、他のことで理解されていない必須の拡張機能は、認証失敗（サーバは、「拡張-サポートされていない」サーバエラー値を送信する必要があります）が発生しなければなりません。
Unknown optional extensions MUST be ignored upon receipt.
不明なオプションの拡張機能は、受信時に無視しなければなりません。
This section describes compliance with SASL mechanism requirements specified in Section 5 of [RFC4422].
このセクションでは、[RFC4422]のセクション5で指定されたSASL機構の要件への準拠を記述する。
1) "SCRAM-SHA-1" and "SCRAM-SHA-1-PLUS".
1） "SCRAM-SHA-1" 及び "SCRAM-SHA-1-PLUS"。
2a) SCRAM is a client-first mechanism.
2A）SCRAMは、クライアント最初のメカニズムです。
2b) SCRAM sends additional data with success.
図2b）SCRAMは、成功して追加データを送信します。
3) SCRAM is capable of transferring authorization identities from the client to the server.
3）SCRAMは、クライアントからサーバへの認証IDを転送することが可能です。
4) SCRAM does not offer any security layers (SCRAM offers channel binding instead).
4）SCRAMは、すべてのセキュリティレイヤを提供していません（SCRAM）は、チャネルではなく、結合提供しています。
5) SCRAM has a hash protecting the authorization identity.
5）SCRAMは、認証アイデンティティを保護するハッシュを持っています。
SCRAM supports channel binding to external secure channels, such as TLS. Clients and servers may or may not support channel binding, therefore the use of channel binding is negotiable. SCRAM does not provide security layers, however, therefore it is imperative that SCRAM provide integrity protection for the negotiation of channel binding.
SCRAMは、TLSなどの外部安全なチャンネルへの結合チャネルをサポートしています。クライアントとサーバーは、または結合チャネルをサポートしていない可能性があり、したがって、チャネルバインディングの使用は交渉です。スクラムは、セキュリティレイヤを提供していない、しかし、そのためには、スクラムが結合チャネルの交渉のための完全性の保護を提供することが不可欠です。
Use of channel binding is negotiated as follows:
次のように結合チャネルの使用が交渉されます。
o Servers that support the use of channel binding SHOULD advertise both the non-PLUS (SCRAM-<hash-function>) and PLUS-variant (SCRAM-<hash-function>-PLUS) mechanism name. If the server cannot support channel binding, it SHOULD advertise only the non-PLUS-variant. If the server would never succeed in the authentication of the non-PLUS-variant due to policy reasons, it MUST advertise only the PLUS-variant.
O結合チャネルの使用をサポートするサーバーは、非PLUS（SCRAM- <ハッシュ関数>）の両方をアドバタイズし、PLUS-バリアント（SCRAM- <ハッシュ関数> -Plus）機構名べきです。サーバが結合チャネルをサポートできない場合は、それが唯一の非PLUS-バリアントを宣伝すべきです。サーバがポリシー上の理由による非PLUSバリアントの認証に成功したことがないならば、それだけPLUS-バリアントを宣伝しなければなりません。
o If the client supports channel binding and the server does not appear to (i.e., the client did not see the -PLUS name advertised by the server), then the client MUST NOT use an "n" gs2-cbind-flag.
クライアントは、チャネル結合およびサーバーが表示されないサポートされている場合は、O（すなわち、クライアントがサーバによってアドバタイズ-Plus名を見ていない）、クライアントは「n」はGS2-CBINDフラグを使用してはなりません。
o Clients that support mechanism negotiation and channel binding MUST use a "p" gs2-cbind-flag when the server offers the PLUS-variant of the desired GS2 mechanism.
サーバが希望GS2機構のPLUS-バリアントを提供するとき、O結合機構交渉とチャネルをサポートするクライアントは、「P」GS2-CBINDフラグを使用しなければなりません。
o If the client does not support channel binding, then it MUST use an "n" gs2-cbind-flag. Conversely, if the client requires the use of channel binding then it MUST use a "p" gs2-cbind-flag. Clients that do not support mechanism negotiation never use a "y" gs2- cbind-flag, they use either "p" or "n" according to whether they require and support the use of channel binding or whether they do not, respectively.
クライアントは結合チャネルをサポートしていない場合は、O、それは「n」はGS2-CBINDフラグを使用しなければなりません。逆に、クライアントはそれが「P」GS2-CBINDフラグを使用しなければならない結合チャネルを使用する必要がある場合。メカニズム交渉は「Y」gs2- CBIND-フラグを使用することはありませんサポートしていないクライアントは、彼らが必要とし、彼らがいない、それぞれ行うかどうかの結合またはチャネルの使用をサポートしているかどうかに応じて、「P」または「N」のいずれかを使用します。
o Upon receipt of the client-first message, the server checks the channel binding flag (gs2-cbind-flag).
Oクライアント最初のメッセージを受信すると、サーバはチャネル結合フラグ（GS2-CBINDフラグ）をチェックします。
* If the flag is set to "y" and the server supports channel binding, the server MUST fail authentication. This is because if the client sets the channel binding flag to "y", then the client must have believed that the server did not support channel binding -- if the server did in fact support channel binding, then this is an indication that there has been a downgrade attack (e.g., an attacker changed the server's mechanism list to exclude the -PLUS suffixed SCRAM mechanism name(s)).
*フラグが「Y」に設定し、サーバーが結合チャネルをサポートしている場合は、サーバーが認証を失敗しなければなりません。クライアントが「Y」にフラグを結合チャネルを設定した場合、クライアントはサーバが結合チャネルをサポートしていませんでしたと信じていなければならないので、これがある - サーバーがバインド実際のサポートチャネルで行った場合、これはそこに持っていることを示すものですダウングレード攻撃して（例えば、攻撃者がスクラム機構名（複数可）サフィックス-Plusを除外するために、サーバーのメカニズムのリストを変更しました）。
* If the channel binding flag was "p" and the server does not support the indicated channel binding type, then the server MUST fail authentication.
*チャネルバインディングフラグが「p」がだったとサーバがバインディングタイプを示しチャンネルをサポートしていない場合は、サーバーが認証を失敗しなければなりません。
The server MUST always validate the client's "c=" field. The server does this by constructing the value of the "c=" attribute and then checking that it matches the client's c= attribute value.
サーバーは、常にクライアントの「C =」フィールドを検証する必要があります。サーバーは、「C =」属性の値を構築し、それは、クライアントのC =属性値と一致することを確認することでこれを行います。
For more discussions of channel bindings, and the syntax of channel binding data for various security protocols, see [RFC5056].
より多くのチャネルバインディングの議論、およびさまざまなセキュリティプロトコルのためのデータを結合チャネルの構文については、[RFC5056]を参照してください。
A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows.
次のように自分のチャンネル結合型の契約を提供していないすべてのSASLのアプリケーションプロトコルのデフォルトチャネル結合型合意プロセスが提供されます。
'tls-unique' is the default channel binding type for any application that doesn't specify one.
「TLS-ユニーク」は1を指定していない任意のアプリケーションのデフォルトチャネルバインディングタイプです。
Servers MUST implement the "tls-unique" [RFC5929] channel binding type, if they implement any channel binding. Clients SHOULD implement the "tls-unique" [RFC5929] channel binding type, if they implement any channel binding. Clients and servers SHOULD choose the highest-layer/innermost end-to-end TLS channel as the channel to which to bind.
彼らはバインディング任意のチャンネルを実装する場合、サーバーは、「TLS-ユニークな」[RFC5929]チャネル結合タイプを実装しなければなりません。彼らはバインディング任意のチャンネルを実装する場合、クライアントは、「TLS-ユニークな」[RFC5929]チャネル結合タイプを実装する必要があります。クライアントとサーバーはバインドするためのチャネルとして最高層/最も内側のエンドツーエンドのTLSチャネルを選択する必要があります。
Servers MUST choose the channel binding type indicated by the client, or fail authentication if they don't support it.
サーバーは、クライアントによって示されたチャネルバインディングタイプを選択するか、彼らはそれをサポートしていない場合、認証に失敗しなければなりません。
The following syntax specification uses the Augmented Backus-Naur form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [RFC3629].
以下の構文仕様は、[RFC5234]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。 "UTF8-2"、 "UTF8-3"、および "UTF8-4" 非末端は[RFC3629]で定義されています。
ALPHA = <as defined in RFC 5234 appendix B.1> DIGIT = <as defined in RFC 5234 appendix B.1> UTF8-2 = <as defined in RFC 3629 (STD 63)> UTF8-3 = <as defined in RFC 3629 (STD 63)> UTF8-4 = <as defined in RFC 3629 (STD 63)>
RFCに定義されてUTF8-2 = <RFC 3629で定義されている（STD 63）> UTF8-3 = <<RFC 5234付録B.1に定義されているよう> DIGIT = <RFC 5234付録B.1に定義されているよう> ALPHA = 3629（STD 63）> UTF8-4 = <RFC 3629で定義されている（STD 63）>
attr-val = ALPHA "=" value ;; Generic syntax of any attribute sent ;; by server or client
ATTR-VAL = ALPHA "=" 値;;送信された任意の属性の一般的な構文;;サーバーまたはクライアントによる
value = 1*value-char
値= 1 *値、CHAR
value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / UTF8-2 / UTF8-3 / UTF8-4 ;; UTF8-char except NUL, "=", and ",".
値セーフ・チャー=％x01-2B /％x2D-3C /％のSpark Proの-7F / UTF8-2 / UTF8-3 / UTF8-4 ;; UTF8-CHAR NULを除いて、 "="、および ""。
value-char = value-safe-char / "="
値-CHAR =値セーフ-CHAR / "="
printable = %x21-2B / %x2D-7E ;; Printable ASCII except ",". ;; Note that any "printable" is also ;; a valid "value".
印刷可能=％x21-2B /％x2D-7E ;;除く印刷可能なASCII ""。 ;;いずれかの「印刷可能」もあることに注意してください;;有効な「価値」。
base64-char = ALPHA / DIGIT / "/" / "+"
base64で文字= ALPHA / DIGIT / "/" / "+"
base64-4 = 4base64-char
Bsi64-4 = 4 Bs64 4
base64-3 = 3base64-char "="
Basit4-3 = 3 Basit4-CHAR "="
base64-2 = 2base64-char "=="
Bsi64-2 = 2 Bs64 4 "=="
base64 = *base64-4 [base64-3 / base64-2]
BASE64 = * base64-4 [base64-3 / base64-2]
posit-number = %x31-39 *DIGIT ;; A positive number.
POSIT番号=％のx31-39 * DIGIT ;;正の数。
saslname = 1*(value-safe-char / "=2C" / "=3D") ;; Conforms to <value>.
saslname = 1 *（値セーフ-チャー/ "= 2C" / "= 3D"）;; <値>に準拠しています。
authzid = "a=" saslname ;; Protocol specific.
authzidは= "A =" saslname ;;プロトコル特定。
cb-name = 1*(ALPHA / DIGIT / "." / "-") ;; See RFC 5056, Section 7. ;; E.g., "tls-server-end-point" or ;; "tls-unique".
CB-名= 1 *（ALPHA / DIGIT / / "" " - "）;; RFC 5056、セクション7を参照してください;;例えば、 "TLS-サーバー・エンドポイント" または;; "TLS-ユニーク"。
gs2-cbind-flag = ("p=" cb-name) / "n" / "y" ;; "n" -> client doesn't support channel binding. ;; "y" -> client does support channel binding ;; but thinks the server does not. ;; "p" -> client requires channel binding. ;; The selected channel binding follows "p=".
GS2-CBINDフラグ=（ "P =" CB-名）/ "N" / "Y" ;; 「N」 - >クライアントは、チャネルバインディングをサポートしていません。 ;; 「Y」 - >サポートチャネルが;;クライアントバインディングありませんしかし、サーバーにはないと考えています。 ;; 「p」は - >クライアントは、チャネルバインディングが必要です。 ;;結合選択されたチャネルは、「= P」の後に続きます。
gs2-header = gs2-cbind-flag "," [ authzid ] "," ;; GS2 header for SCRAM ;; (the actual GS2 header includes an optional ;; flag to indicate that the GSS mechanism is not ;; "standard", but since SCRAM is "standard", we ;; don't include that flag).
GS2ヘッダー= GS2-CBINDフラグ "" [authzidは "" ;; SCRAMためGS2ヘッダ;; （実際のGS2ヘッダがGSS機構は;;「標準」ではないことを示すために、オプションの;;フラグを含むが、SCRAMが「標準」であるので、我々は、そのフラグを含まない;;）。
username = "n=" saslname ;; Usernames are prepared using SASLprep.
ユーザ名=「と=」サルマン;;ユーザー名はSASLprepを用いて調製されます。
reserved-mext = "m=" 1*(value-char) ;; Reserved for signaling mandatory extensions. ;; The exact syntax will be defined in ;; the future.
予約、文部科学省= "M =" 1 *（値-CHAR）;;必須の拡張機能をシグナリングのために予約されています。 ;;正確な構文は、で定義されます;;未来。
channel-binding = "c=" base64 ;; base64 encoding of cbind-input.
チャネル結合= "C =" BASE64 ;; CBIND入力のBase64エンコード。
proof = "p=" base64
証明= "P =" BASE64
nonce = "r=" c-nonce [s-nonce] ;; Second part provided by server.
ノンス= "R =" C-ノンス[S-ノンス] ;;サーバーによって提供される第2の部分。
c-nonce = printable
C-ナンス=印刷可能
s-nonce = printable
S-ナンス=印刷可能
salt = "s=" base64
塩= "S =" BASE64
verifier = "v=" base64 ;; base-64 encoded ServerSignature.
検証= "V =" base64で;;ベース64はServerSignatureをコードしていました。
iteration-count = "i=" posit-number ;; A positive number.
反復カウント=「I =」POSIT番号;;正の数。
client-first-message-bare = [reserved-mext ","] username "," nonce ["," extensions]
クライアント・ファースト・メッセージ裸= [予約-文部科学省 " "]ユーザ名"、" ナンス[ "" 拡張子]
client-first-message = gs2-header client-first-message-bare
クライアント・ファースト・メッセージ= GS2ヘッダクライアント・ファースト・メッセージ裸
server-first-message = [reserved-mext ","] nonce "," salt "," iteration-count ["," extensions]
サーバ・ファースト・メッセージ=ノンス[「 『 - 文部科学省予約]』、」塩「」反復カウント[「」拡張]
client-final-message-without-proof = channel-binding "," nonce ["," extensions]
クライアント最終メッセージ無しプルーフ=チャネル結合「」ナンス[「」拡張]
client-final-message = client-final-message-without-proof "," proof
クライアント - 最終メッセージ=クライアント-最終メッセージなしプルーフ「」証拠
server-error = "e=" server-error-value
サーバーエラー=「E =」サーバーエラー値
server-error-value = "invalid-encoding" / "extensions-not-supported" / ; unrecognized 'm' value "invalid-proof" / "channel-bindings-dont-match" / "server-does-support-channel-binding" / ; server does not support channel binding "channel-binding-not-supported" / "unsupported-channel-binding-type" / "unknown-user" / "invalid-username-encoding" / ; invalid username encoding (invalid UTF-8 or ; SASLprep failed) "no-resources" / "other-error" / server-error-value-ext ; Unrecognized errors should be treated as "other-error". ; In order to prevent information disclosure, the server ; may substitute the real reason with "other-error".
サーバー・エラー値=「無効なエンコーディング」/「エクステンション-サポートされていません」/。認識されない「m」の値が「無効プルーフ」/「チャンネル・バインディング・ドント・マッチ」/「サーバませ支援チャンネル結合」/;サーバーは、チャネル結合「チャネル結合-サポートされていません」/「サポートされていないチャンネル結合型」/「不明ユーザー」/「無効なユーザ名エンコーディング」/をサポートしていません。無効なユーザー名エンコーディング（無効なUTF-8または; SASLprepが失敗した） "非資源" / "その他のエラー" /サーバー・エラー値-EXT。認識できないエラーは、「その他のエラー」として扱われるべきです。 ;情報開示を防止するために、サーバと「その他のエラー」との本当の理由を代えることができます。
server-error-value-ext = value ; Additional error reasons added by extensions ; to this document.
サーバー・エラー値-EXT =値;拡張で追加された追加のエラーの理由。このドキュメントへ。
server-final-message = (server-error / verifier) ["," extensions]
サーバ最終メッセージ=（サーバーエラー/検証）「」拡張]
extensions = attr-val *("," attr-val) ;; All extensions are optional, ;; i.e., unrecognized attributes ;; not defined in this document ;; MUST be ignored.
拡張子= attrの-VAL *（ "" のattr-VAL）;;すべての拡張機能は、オプションです;;すなわち、認識されていない属性;;この文書で定義されていません;;無視しなければなりません。
cbind-data = 1*OCTET cbind-input = gs2-header [ cbind-data ] ;; cbind-data MUST be present for ;; gs2-cbind-flag of "p" and MUST be absent ;; for "y" or "n".
CBINDデータ= 1 *オクテットCBIND入力= GS2ヘッダ[CBINDデータ] ;; CBINDデータがために存在しなければならない;; 「P」のGS2-CBINDフラグ及び存在してはならない;; "Y" または "N" のため。
This section and its sub-sections and all normative references of it not referenced elsewhere in this document are INFORMATIONAL for SASL implementors, but they are NORMATIVE for GSS-API implementors.
このドキュメントの他の場所で参照されていないこのセクションとそのサブセクションとそれのすべての引用規格は、SASLの実装のための情報ですが、彼らはGSS-APIの実装のための規範です。
SCRAM is actually also a GSS-API mechanism. The messages are the same, but a) the GS2 header on the client's first message and channel binding data is excluded when SCRAM is used as a GSS-API mechanism, and b) the RFC2743 section 3.1 initial context token header is prefixed to the client's first authentication message (context token).
SCRAMはまた、実際にGSS-APIメカニズムです。メッセージは同じであるが、SCRAMはGSS-API機構として使用する場合A）、クライアントの最初のメッセージ及びチャネル結合データにGS2ヘッダは除外され、およびb）RFC2743のセクション3.1初期コンテキストトークンヘッダがクライアントに前置されています最初の認証メッセージ（コンテキストトークン）。
The GSS-API mechanism OID for SCRAM-SHA-1 is 1.3.6.1.5.5.14 (see Section 10).
SCRAM-SHA-1用のGSS-API機構のOIDは1.3.6.1.5.5.14（セクション10を参照）です。
SCRAM security contexts always have the mutual_state flag (GSS_C_MUTUAL_FLAG) set to TRUE. SCRAM does not support credential delegation, therefore SCRAM security contexts alway have the deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
スクラムのセキュリティコンテキストは常にmutual_stateフラグ（GSS_C_MUTUAL_FLAG）がTRUEに設定されています。 SCRAMは、したがって、スクラムのセキュリティコンテキストがなかれFALSEに設定deleg_stateフラグ（GSS_C_DELEG_FLAG）を持っている、資格の委譲をサポートしていません。
SCRAM does not explicitly name acceptor principals. However, the use of acceptor principal names to find or prompt for passwords is useful. Therefore, SCRAM supports standard generic name syntaxes for acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). Implementations should use the target name passed to GSS_Init_sec_context(), if any, to help retrieve or prompt for SCRAM passwords.
SCRAMは、明示的に受容プリンシパルを指していません。しかし、発見やパスワードの入力を要求するアクセプタプリンシパル名の使用が便利です。したがって、SCRAMは（[RFC2743]、セクション4.1を参照）などGSS_C_NT_HOSTBASED_SERVICEとしてアクセプターのための標準的な一般名構文をサポートしています。もしあれば、実装は取得したり、スクラムのパスワードの入力を求める支援するために、もしGSS_Init_sec_context（に渡されたターゲット名）を使用する必要があります。
SCRAM supports only a single name type for initiators: GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for SCRAM.
GSS_C_NT_USER_NAME：SCRAMは、イニシエータのための唯一の単一の名前タイプをサポートしています。 GSS_C_NT_USER_NAMEはスクラムのデフォルトの名前タイプです。
There is no name canonicalization procedure for SCRAM beyond applying SASLprep as described in Section 5.1.
5.1節で説明したようにSASLprepを適用越えてSCRAMには名前の正規化の手順はありません。
The query, display, and exported name syntaxes for SCRAM principal names are all the same. There are no SCRAM-specific name syntaxes (SCRAM initiator principal names are free-form); -- applications should use generic GSS-API name types such as GSS_C_NT_USER_NAME and
SCRAMプリンシパル名のクエリ、表示、およびエクスポートされた名前の構文はすべて同じです。何SCRAM固有の名前の構文が（SCRAMイニシエータプリンシパル名は自由形式です）はありません。 - アプリケーションは、GSS_C_NT_USER_NAMEなどの一般的なGSS-API名のタイプを使用する必要がありますし、
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported name token does, of course, conform to [RFC2743], Section 3.2, but the "NAME" part of the token is just a SCRAM user name.
GSS_C_NT_HOSTBASED_SERVICE（[RFC2743]、セクション4を参照）。エクスポートされた名前トークンは、もちろん、[RFC2743]、セクション3.2に準拠んが、トークンの「NAME」の部分は、ちょうどSCRAMのユーザー名です。
The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the same as those for the Kerberos V GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections), using the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
GSS-API機構としてSCRAMごとのメッセージトークンは、Kerberos V「AES128-CTS-HMACを使用して、ケルベロスV GSS-APIメカニズム[RFC4121]（セクション4.2およびサブセクションを参照）と同じでなければなりません-sha1-96" のenctype [RFC3962]。
The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail (GSS_C_CONF_FLAG) security context flags are always set to TRUE.
replay_det_state（GSS_C_REPLAY_FLAG）、sequence_state（GSS_C_SEQUENCE_FLAG）、conf_avail（GSS_C_CONF_FLAG）とinteg_avail（GSS_C_CONF_FLAG）セキュリティコンテキストフラグは常にTRUEに設定されています。
The 128-bit session "protocol key" SHALL be derived by using the least significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session key" || ClientKey || AuthMessage). "Specific keys" are then derived as usual as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962].
128ビットのセッション "プロトコル・キー" が使用して導出することがSHALL最下位（右端）128 HMACのビット（StoredKey、 "GSS-APIセッションキー" || || ClientKey AuthMessage）。 [RFC4121]、[RFC3961]及び[RFC3962]のセクション2で説明したように「特定キー」は、その後通常通り導出されます。
The terms "protocol key" and "specific key" are Kerberos V5 terms [RFC3961].
用語「プロトコル・キー」と「特定キー」は、ケルベロスV5用語[RFC3961]です。
SCRAM does support PROT_READY, and is PROT_READY on the initiator side first upon receipt of the server's reply to the initial security context token.
SCRAMはPROT_READYをサポートし、そしてPROT_READYは、最初の初期のセキュリティコンテキストトークンへのサーバの応答を受信すると、イニシエータ側にあります。
The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for the Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor-asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random(). The protocol key to be used for the GSS_Pseudo_random() SHALL be the same as the key defined in Section 8.2.
SCRAM用GSS_Pseudo_random（）[RFC4401]はケルベロスV GSS-APIメカニズム[RFC4402]と同じでなければなりません。スクラムのためのアクセプターアサートサブセッションキーがありません、これGSS_C_PRF_KEY_FULLとGSS_C_PRF_KEY_PARTIALは（）SCRAMのGSS_Pseudo_randomの等価です。 GSS_Pseudo_randomに使用されるプロトコルキー（）セクション8.2で定義されたキーと同じでなければなりません。
If the authentication exchange is performed without a strong security layer (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. An external security layer with strong encryption will prevent this attack.
認証交換が（そのようなデータの機密性とTLSなど）強力なセキュリティ層なしで実行されている場合は、受動的盗聴者は、ユーザーのパスワードを回復するために使用することができ、オフライン辞書やブルートフォース攻撃をマウントするのに十分な情報を得ることができます。この攻撃のために必要な時間の量は、選択された暗号ハッシュ関数、パスワードの強度、およびサーバから提供される反復回数に依存します。強力な暗号化と外部のセキュリティ層は、この攻撃を防ぐことができます。
If the external security layer used to protect the SCRAM exchange uses an anonymous key exchange, then the SCRAM channel binding mechanism can be used to detect a man-in-the-middle attack on the security layer and cause the authentication to fail as a result. However, the man-in-the-middle attacker will have gained sufficient information to mount an offline dictionary or brute-force attack. For this reason, SCRAM allows to increase the iteration count over time. (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.)
SCRAM交換を保護するために使用される外部セキュリティ層が匿名鍵交換を使用する場合、結合機構SCRAMチャネルは、セキュリティ層のman-in-the-middle攻撃を検出し、認証は、結果として失敗する原因とするために使用することができます。しかし、のman-in-the-middle攻撃者は、オフライン辞書やブルートフォース攻撃をマウントするのに十分な情報を得ています。このため、SCRAMは、時間をかけて反復回数を増やすことができます。 （唯一の「StoredKey」と「サーバキー」を所有しているサーバが自動的に認証が成功すると、反復回数を増やすことはできません。このような増加は、ユーザーのパスワードをリセットする必要になります。）
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 EKE class of mechanisms). RFC 2945 [RFC2945] is an example of such technology. The WG elected not to use EKE like mechanisms as a basis for SCRAM.
認証情報が認証データベースから盗まれている場合は、オフライン辞書やブルートフォース攻撃は、ユーザーのパスワードを回復するために使用することができます。塩の使用は、各パスワードに別の攻撃を要求することによって、多少この攻撃を軽減します。この攻撃から保護する認証メカニズム（例えば、機構のEKEクラス）利用可能です。 RFC 2945 [RFC2945]は、そのような技術の一例です。 WGはスクラムの基礎としてのメカニズムのようなEKEを使用しないことを選択しました。
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.
攻撃者は、認証リポジトリから認証情報を取得し、いずれかの認証交換に盗聴またはサーバーを偽装した場合、攻撃者はすべて同じハッシュ関数を使用してSCRAMへのアクセスを提供するサーバー、パスワード、反復回数にそのユーザーを偽装する能力を獲得し、塩。このため、ランダムに生成されたsalt値を使用することが重要です。
SCRAM does not negotiate a hash function to use. Hash function negotiation is left to the SASL 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 appropriate mechanism to use from 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 a successor to SHA-1 may be preferred over SCRAM with SHA-1).
SCRAMは、ハッシュ関数を使用するように交渉していません。ハッシュ関数交渉はSASLメカニズムの交渉に委ねられています。クライアントは、クライアントがサーバのアドバタイズされたメカニズムのリストから使用するための適切なメカニズムを選ぶことができるように好みによってメカニズムのローカルで利用可能なリストを並べ替えることができることが重要です。それはローカルの問題であるとして、この優先順位は、ここで指定されていません。優先順位は、機構暗号の強さ（例えば、SHA-1の後継とSCRAMは、SHA-1とSCRAMよりも好ましいことがある。）の客観的および主観的概念を含むべきです。
Note that to protect the SASL mechanism negotiation applications normally must list the server mechanisms twice: once before and once after authentication, the latter using security layers. Since SCRAM does not provide security layers, the only ways to protect the mechanism negotiation are a) use channel binding to an external channel, or b) use an external channel that authenticates a user-provided server name.
二回サーバー・メカニズムをリストする必要があり、通常はSASLメカニズム交渉アプリケーションを保護することに注意してください。前に一度と一度認証した後、後者の使用セキュリティ層。 SCRAMセキュリティ層を提供していないため、機構のネゴシエーションを保護するための唯一の方法は、A）は、外部チャンネルに結合チャネルを使用する、またはb）ユーザ提供サーバ名を認証した外部チャネルを使用しています。
SCRAM does not protect against downgrade attacks of channel binding types. The complexities of negotiating a channel binding type, and handling down-grade attacks in that negotiation, were intentionally left out of scope for this document.
SCRAMは、チャネル結合タイプのダウングレード攻撃から保護することはできません。チャネルバインディングタイプを交渉し、その交渉におけるダウングレード攻撃を扱うの複雑さは、意図的にこのドキュメントのための範囲の外に残っていました。
A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value.
敵対的なサーバは、大きな反復カウント値を送信することにより、クライアント上の計算サービス拒否攻撃を行うことができます。
See [RFC4086] for more information about generating randomness.
ランダム性の生成の詳細については、[RFC4086]を参照してください。
IANA has added the following family of SASL mechanisms to the SASL Mechanism registry established by [RFC4422]:
IANAは[RFC4422]によって確立SASLメカニズムレジストリにSASLメカニズムの以下のファミリーを追加しました。
To: iana@iana.org Subject: Registration of a new SASL family SCRAM
To：iana@iana.org件名：新しいSASLファミリSCRAMの登録
SASL mechanism name (or prefix for the family): SCRAM-* Security considerations: Section 7 of [RFC5802] Published specification (optional, recommended): [RFC5802] Person & email address to contact for further information: IETF SASL WG <sasl@ietf.org> Intended usage: COMMON Owner/Change controller: IESG <iesg@ietf.org> Note: Members of this family MUST be explicitly registered using the "IETF Review" [RFC5226] registration procedure. Reviews MUST be requested on the SASL mailing list <sasl@ietf.org> (or a successor designated by the responsible Security AD).
SASLメカニズム名（または家族のための接頭辞）：SCRAM- *セキュリティ上の考慮事項：[RFC5802]公開仕様（オプション、推奨）のセクション7：詳細のために連絡するために[RFC5802]人とEメールアドレス：IETF SASL WG <SASL @ ietf.org>意図している用法：COMMON所有者/変更コントローラ：IESG <iesg@ietf.org>注：このファミリーのメンバーは、明示的に「IETFレビュー」[RFC5226]登録手順を使用して登録しなければなりません。レビューはSASLメーリングリスト<sasl@ietf.org>（または責任のセキュリティADで指定された後継者）に要求しなければなりません。
Note to future SCRAM-mechanism designers: each new SCRAM-SASL mechanism MUST be explicitly registered with IANA and MUST comply with SCRAM-mechanism naming convention defined in Section 4 of this document.
将来SCRAM-機構設計者への注意：それぞれの新しいSCRAM-SASLメカニズムは、明示的にIANAに登録しなければなりませんし、このドキュメントのセクション4で定義されたスクラム機構の命名規則を遵守しなければなりません。
IANA has added the following entries to the SASL Mechanism registry established by [RFC4422]:
IANAは[RFC4422]によって確立SASLメカニズムのレジストリに次のエントリを追加しました。
To: iana@iana.org Subject: Registration of a new SASL mechanism SCRAM-SHA-1
To：iana@iana.org件名：新しいSASLメカニズムの登録SCRAM-SHA-1
SASL mechanism name (or prefix for the family): SCRAM-SHA-1 Security considerations: Section 7 of [RFC5802] Published specification (optional, recommended): [RFC5802] Person & email address to contact for further information: IETF SASL WG <sasl@ietf.org> Intended usage: COMMON Owner/Change controller: IESG <iesg@ietf.org> Note:
SASLメカニズム名（または家族のための接頭辞）：SCRAM-SHA-1セキュリティの考慮事項：[RFC5802]公開仕様（オプション、推奨）のセクション7：[RFC5802]人とEメールアドレス詳細のために連絡する：IETF SASL WG < sasl@ietf.org>意図している用法：COMMON所有者/変更コントローラ：IESG <iesg@ietf.org>注：
To: iana@iana.org Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS
To：iana@iana.org件名：新しいSASLメカニズムSCRAM-SHA-1-PLUSの登録
SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS Security considerations: Section 7 of [RFC5802] Published specification (optional, recommended): [RFC5802] Person & email address to contact for further information: IETF SASL WG <sasl@ietf.org> Intended usage: COMMON Owner/Change controller: IESG <iesg@ietf.org> Note:
SASLメカニズム名（または家族のための接頭辞）：SCRAM-SHA-1-PLUSのセキュリティの考慮事項：[RFC5802]公開仕様（オプション、推奨）のセクション7：[RFC5802]人とEメールアドレス詳細のために連絡する：IETF SASL WG <sasl@ietf.org>意図している用法：COMMON所有者/変更コントローラ：IESG <iesg@ietf.org>注：
Per this document, IANA has assigned a GSS-API mechanism OID for SCRAM-SHA-1 from the iso.org.dod.internet.security.mechanisms prefix (see "SMI Security for Mechanism Codes" registry).
このドキュメントごとに、IANAはSCRAM-SHA-1 iso.org.dod.internet.security.mechanismsプレフィックスから（「SMIセキュリティメカニズム・コードのための」レジストリを参照）のためのGSS-API機構OIDが割り当てられています。
This document benefited from discussions on the SASL WG mailing list. The authors would like to specially thank Dave Cridland, Simon Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen, Ben Campbell, Peter Saint-Andre, and Tobias Markmann for their contributions to this document. A special thank you to Simon Josefsson for shepherding this document and for doing one of the first implementations of this specification.
この文書では、SASL WGメーリングリストでの議論の恩恵を受けました。作者は特別に、この文書への貢献のためにデイブCridland、サイモンJosefsson氏、ジェフリーHutzelman、クルトZeilenga、パシEronen、ベン・キャンベル、ピーター・サン・アンドレ、およびトビアスMarkmannに感謝したいと思います。特別には、この文書を牧するために、この仕様の最初の実装の1つを行うためのサイモンJosefsson氏にお願いします。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレイク、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム1（SHA1）を確保"、RFC 3174、2001年9月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929]アルトマン、J.、ウィリアムズ、N.、およびL.朱、 "TLSのチャネルバインディング"、RFC 5929、2010年7月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]レイバーン、K.、 "暗号化とケルベロス5チェックサムの仕様"、RFC 3961、2005年2月。
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962]レイバーン、K.、 "Kerberos 5のためのAdvanced Encryption Standard（AES）暗号化"、RFC 3962、2005年2月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]朱、L.、Jaganathan、K.、およびS.ハートマン、 "Kerberosバージョン5の汎用セキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズム：バージョン2"、RFC 4121、2005年7月。
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4401]ウィリアムズ、N.、RFC 4401 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース（GSS-API）のための擬似ランダム関数（PRF）APIの拡張"、2006年2月。
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[RFC4402]ウィリアムズ、N.、RFC 4402、2006年2月、 "ケルベロスVジェネリックセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズムのための擬似ランダム関数（PRF）"。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
、RFC 5801、2010年7月： "GS2メカニズム家族簡易認証セキュリティー層（SASL）で一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズムを使用して" [RFC5801] Josefsson氏、S.およびN.ウィリアムズ、。
[CRAMHISTORIC] Zeilenga, K., "CRAM-MD5 to Historic", Work in Progress, November 2008.
[CRAMHISTORIC] Zeilenga、K.、 "歴史的にCRAM-MD5"、進歩、2008年11月の作業。
[DIGESTHISTORIC] Melnikov, A., "Moving DIGEST-MD5 to Historic", Work in Progress, July 2008.
[DIGESTHISTORIC]メルニコフ、A.、 "歴史的にDIGEST-MD5の移動"、進歩、2008年7月に作業。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898] Kaliski、B.、 "PKCS＃5：パスワードベースの暗号化仕様バージョン2.0"、RFC 2898、2000年9月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945]呉、T.、 "SRP認証と鍵交換システム"、RFC 2945、2000年9月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"、RFC 4510、2006年6月。
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4616] Zeilenga、K.、 "PLAIN簡易認証セキュリティー層（SASL）メカニズム"、RFC 4616、2006年8月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R.、 "インターネットセキュリティ用語集、バージョン2"、RFC 4949、2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5803] Melnikov, A., "Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets", RFC 5803, July 2010.
、RFC 5803、2010年7月[RFC5803]メルニコフ、A.、 "塩漬けチャレンジレスポンス認証メカニズム（SCRAM）秘密を格納するためのLDAP（Lightweight Directory Access Protocol）スキーマ"。
[tls-server-end-point] IANA, "Registration of TLS server end-point channel bindings", available from http://www.iana.org, June 2008.
[TLS-サーバー・エンドポイント] IANA、http://www.iana.orgから入手可能な "TLSサーバのエンドポイントのチャネルバインディングの登録"、2008年6月。
Appendix A. Other Authentication Mechanisms
付録A.その他の認証メカニズム
The DIGEST-MD5 [DIGESTHISTORIC] mechanism has proved to be too complex to implement and test, and thus has poor interoperability. The security layer is often not implemented, and almost never used; everyone uses TLS instead. For a more complete list of problems with DIGEST-MD5 that led to the creation of SCRAM, see [DIGESTHISTORIC].
DIGEST-MD5 [DIGESTHISTORIC]メカニズムが実装してテストするには余りにも複雑であることが判明し、したがって乏しい相互運用性を有しています。セキュリティ層は、多くの場合、実装されていない、ほとんど使われることはありません。誰もが代わりにTLSを使用しています。 SCRAMの創出につながっDIGEST-MD5で問題のより完全なリストについては、[DIGESTHISTORIC]を参照してください。
The CRAM-MD5 SASL mechanism, while widely deployed, also has some problems. In particular, it is missing some modern SASL features such as support for internationalized usernames and passwords, support for passing of authorization identity, and support for channel bindings. It also doesn't support server authentication. For a more complete list of problems with CRAM-MD5, see [CRAMHISTORIC].
CRAM-MD5 SASLメカニズム、広く展開されている一方で、また、いくつかの問題があります。特に、このような国際化ユーザー名とパスワードのサポート、認証アイデンティティの通過のためのサポート、およびチャネルバインディングのサポートなど、いくつかの近代的なSASLの機能が不足しています。また、サーバーの認証をサポートしていません。 CRAM-MD5で問題のより完全なリストについては、[CRAMHISTORIC]を参照してください。
The PLAIN [RFC4616] SASL mechanism allows a malicious server or eavesdropper to impersonate the authenticating user to any other server for which the user has the same password. It also sends the password in the clear over the network, unless TLS is used. Server authentication is not supported.
PLAIN [RFC4616] SASLメカニズムは、悪意のあるサーバや盗聴者は、ユーザが同じパスワードを持っている他のサーバに認証ユーザを偽装することを可能にします。 TLSが使用されていない限り、それはまた、ネットワーク上で明確でパスワードを送信します。サーバー認証がサポートされていません。
Appendix B. Design Motivations
付録B.デザイン動機
The following design goals shaped this document. Note that some of the goals have changed since the initial version of the document.
以下の設計目標は、この文書を形。目標のいくつかは、文書の最初のバージョンから変更されていることに注意してください。
o The SASL mechanism has all modern SASL features: support for internationalized usernames and passwords, support for passing of authorization identity, and support for channel bindings.
SASLメカニズムoをすべてのモダンなSASLの機能を備えています。国際化ユーザー名とパスワードのサポート、認証アイデンティティの通過のためのサポート、およびチャネルバインディングのサポートを。
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 DIGEST-MD5 in both clients and servers.
Oメカニズムは、クライアントとサーバの両方でDIGEST-MD5よりも実装が容易です。
Authors' Addresses
著者のアドレス
Chris Newman Oracle 800 Royal Oaks Monrovia, CA 91016 USA
クリス・ニューマンオラクル800のロイヤルオークスモンロビア、CA 91016 USA
EMail: chris.newman@oracle.com
メールアドレス：chris.newman@oracle.com
Abhijit Menon-Sen Oryx Mail Systems GmbH
Abhijitメノンセンオリックスメールシステム社
EMail: ams@toroid.org
メールアドレス：ams@toroid.org
Alexey Melnikov Isode, Ltd.
アレクセイ・メルニコフISODE、株式会社
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Nicolas Williams Oracle 5300 Riata Trace Ct Austin, TX 78727 USA
ニコラス・ウィリアムズOracleの5300 RiataトレースのCtオースティン、TX 78727 USA
EMail: Nicolas.Williams@oracle.com
メールアドレス：Nicolas.Williams@oracle.com