[要約] RFC 8146は、EAP-pwdにソルト付きパスワードデータベースのサポートを追加するためのものです。目的は、EAP-pwdプロトコルを使用して認証を行う際に、セキュリティを向上させるためにソルト付きパスワードを使用することです。
Internet Engineering Task Force (IETF) D. Harkins
Request for Comments: 8146 HP Enterprise
Updates: 5931 April 2017
Category: Informational
ISSN: 2070-1721
Adding Support for Salted Password Databases to EAP-pwd
ソルトパスワードデータベースのサポートをEAP-pwdに追加
Abstract
概要
EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys and double hashing of a password in the style of Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd.
EAP-pwdは、辞書攻撃に耐性のある技術を使用して認証に共有パスワードを利用する拡張認証プロトコル（EAP）方式です。生のキーとMicrosoftチャレンジハンドシェイク認証プロトコルバージョン2（MSCHAPv2）のスタイルのパスワードのダブルハッシュのサポートが含まれますが、ソルトパスワードのサポートは含まれません。ソルトされたパスワードの多くの既存のデータベースがあり、EAP-pwdでの使用を許可することが望ましいです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8146.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8146で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Keyword Definition .........................................3
2. Salted Passwords in EAP-pwd .....................................3
2.1. Password Preprocessing .....................................3
2.2. The Salting of a Password ..................................5
2.3. Using UNIX crypt ...........................................5
2.4. Using scrypt ...............................................6
2.5. Using PBKDF2 ...............................................6
2.6. Protocol Modifications .....................................7
2.7. Payload Modifications ......................................8
3. IANA Considerations .............................................8
4. Security Considerations .........................................9
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References ....................................10
Acknowledgements ..................................................11
Author's Address ..................................................11
Databases of stored passwords present an attractive target for attack -- get access to the database, learn the passwords. To confound such attacks, a random "salt" was hashed with the password and the resulting digest stored, along with the salt, instead of the raw password. This has the effect of randomizing the password; even if two, distinct users have chosen the same password, the stored, and salted, password will be different. It also requires an adversary who has compromised the security of the stored database to launch a dictionary attack per entry to recover passwords.
保存されたパスワードのデータベースは、攻撃の魅力的な標的となります。データベースにアクセスし、パスワードを確認してください。このような攻撃を混乱させるために、ランダムな「塩」がパスワードでハッシュされ、結果のダイジェストが生のパスワードの代わりにソルトとともに保存されました。これには、パスワードをランダム化する効果があります。 2人の異なるユーザーが同じパスワードを選択した場合でも、保存され、ソルト処理されたパスワードは異なります。また、保存されたデータベースのセキュリティを危険にさらした攻撃者が、エントリごとに辞書攻撃を開始してパスワードを回復する必要があります。
Dictionary attacks, especially using custom hardware, represent real-world attacks and merely salting a password is insufficient to protect a password database. To address these attacks, a sequential memory hard function, such as described in [RFC7914], is used.
特にカスタムハードウェアを使用する辞書攻撃は、実際の攻撃を表しており、単にパスワードをソルトするだけでは、パスワードデータベースを保護するには不十分です。これらの攻撃に対処するには、[RFC7914]で説明されているようなシーケンシャルメモリハード機能を使用します。
While salting a password database is not sufficient to deal with many real-world attacks, the historic popularity of password salting means there are a large number of such databases deployed, and EAP-pwd needs to be able to support them. In addition, EAP-pwd needs to be able to support databases using more modern sequential memory hard functions for protection.
パスワードデータベースをソルティングすることは、実際の多くの攻撃に対処するには不十分ですが、パスワードソルティングの歴史的な人気は、そのようなデータベースが多数展開されており、EAP-pwdがそれらをサポートできる必要があることを意味します。さらに、EAP-pwdは、保護のために最新のシーケンシャルメモリハード機能を使用してデータベースをサポートできる必要があります。
EAP-pwd imposes an additional security requirement on a database of salted passwords that otherwise would not exist, see Section 4.
EAP-pwdは、他の方法では存在しないソルトパスワードのデータベースに追加のセキュリティ要件を課します。セクション4を参照してください。
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]で説明されているように解釈されます。
EAP-pwd is based on the "dragonfly" Password-Authenticated Key Exchange (PAKE) -- see [RFC7664]. This is a balanced PAKE and requires that each party to the protocol obtain an identical representation of a processed password (see Section 4). Therefore, salting of a password is treated as an additional password preprocessing technique of EAP-pwd. The salt and digest to use are conveyed to the peer by the server, and the password is processed prior to fixing the password element (see Section 2.8.3 of [RFC5931]).
EAP-pwdは「dragonfly」パスワード認証鍵交換（PAKE）に基づいています-[RFC7664]を参照してください。これはバランスの取れたPAKEであり、プロトコルの各当事者が処理されたパスワードの同一の表現を取得する必要があります（セクション4を参照）。したがって、パスワードのソルティングは、EAP-pwdの追加のパスワード前処理手法として扱われます。使用するソルトとダイジェストはサーバーによってピアに伝えられ、パスワードはパスワード要素を修正する前に処理されます（[RFC5931]のセクション2.8.3を参照）。
This memo defines eight (8) new password preprocessing techniques for EAP-pwd:
このメモは、EAP-pwdの8つの新しいパスワード前処理手法を定義しています。
o 0x03: a random salt with SHA-1
o 0x03：SHA-1のランダムなソルト
o 0x04: a random salt with SHA-256
o 0x04：SHA-256のランダムソルト
o 0x05: a random salt with SHA-512
o 0x05：SHA-512のランダムソルト
o 0x06: UNIX crypt()
o 0x06：UNIX crypt()
o 0x07: scrypt
o 0x07：scrypt
o 0x08: PBKDF2 with SHA-256
o 0x08：SHA-256を搭載したPBKDF2
o 0x09: PBKDF2 with SHA-512
o 0x09：SHA-512を搭載したPBKDF2
o 0x0A: SASLprep then a random salt with SHA-1
o 0x0A：SASLprep、SHA-1のランダムソルト
o 0x0B: SASLprep then a random salt with SHA-256
o 0x0B：SASLprep、SHA-256のランダムソルト
o 0x0C: SASLprep then a random salt with SHA-512
o 0x0C：SASLprep、SHA-512のランダムソルト
o 0x0D: SASLprep then UNIX crypt()
o 0x0D：SASLprep、次にUNIX crypt()
o 0x0E: OpaqueString then scrypt
o 0x0E：OpaqueStringはscrypt
o 0x0F: OpaqueString then PBKDF2 with SHA-256
o 0x0F：OpaqueString、次にSHA-256を使用したPBKDF2
o 0x10: OpaqueString then PBKDF2 with SHA-512
o 0x10：OpaqueString、次にSHA-512を使用したPBKDF2
When passing salt, the size of the salt SHOULD be at least as long as the message digest of the hash algorithm used. There is no guarantee that deployed salted databases have followed this rule, and in the interest of interoperability, an EAP peer SHOULD NOT abort an EAP-pwd exchange if the length of the salt conveyed during the exchange is less than the message digest of the indicated hash algorithm.
ソルトを渡す場合、ソルトのサイズは、使用するハッシュアルゴリズムのメッセージダイジェストと少なくとも同じ長さにする必要があります（SHOULD）。展開されたソルトデータベースがこのルールに従っていることは保証されていません。相互運用性の観点から、交換中に伝達されたソルトの長さが指定されたメッセージダイジェストより短い場合、EAPピアはEAP-pwd交換を中止しないでください。ハッシュアルゴリズム。
UNIX crypt() ([CRY]), scrypt ([RFC7914]), and PBKDF2 ([RFC8018]) impose additional formatting requirements on the passed salt. See below.
UNIX crypt()（[CRY]）、scrypt（[RFC7914]）、およびPBKDF2（[RFC8018]）は、渡されたソルトに追加のフォーマット要件を課します。下記参照。
Plain salting techniques using [SHS] are included for support of existing databases. scrypt and PBKDF2 techniques are RECOMMENDED for new password database deployments.
[SHS]を使用した単純なソルティング手法は、既存のデータベースをサポートするために含まれています。 scryptとPBKDF2の手法は、新しいパスワードデータベースの導入に推奨されます。
SASLprep has been deprecated, but databases treated with SASLprep exist; it is necessary to provide code points for them. When using SASLprep, a password SHALL be considered a "stored string" per [RFC3454]; therefore, unassigned code points are prohibited. The output of SASLprep SHALL be the binary representation of the processed UTF-8 character string. Prohibited output and unassigned code points encountered in SASLprep preprocessing SHALL cause a failure of preprocessing, and the output SHALL NOT be used with EAP-pwd.
SASLprepは廃止されましたが、SASLprepで処理されたデータベースが存在します。それらのコードポイントを提供する必要があります。 SASLprepを使用する場合、パスワードは[RFC3454]による「格納された文字列」と見なされるべきです（SHALL）。したがって、割り当てられていないコードポイントは禁止されています。 SASLprepの出力は、処理されたUTF-8文字列のバイナリ表現である必要があります（SHALL）。 SASLprepの前処理で禁止された出力と未割り当てのコードポイントが発生すると、前処理が失敗し、出力はEAP-pwdで使用されません（SHALL）。
When performing one of the preprocessing techniques (0x0E-0x10), the password SHALL be a UTF-8 string and SHALL be preprocessed by applying the Preparation and Enforcement steps of the OpaqueString profile in [RFC7613] to the password. The output of OpaqueString, also a UTF-8 string, becomes the EAP-pwd password and SHALL be hashed with the indicated algorithm.
前処理技法の1つ（0x0E-0x10）を実行する場合、パスワードはUTF-8文字列である必要があり（SHALL）、[RFC7613]のOpaqueStringプロファイルの準備および実施手順をパスワードに適用することによって前処理する必要があります。 OpaqueStringの出力（これもUTF-8文字列）はEAP-pwdパスワードになり、指定されたアルゴリズムでハッシュする必要があります（SHALL）。
There is a large number of deployed password databases that use salting and hashing in the style of [RFC7616], but these deployments require a nonce contribution by the client (as well as the server), and EAP-pwd does not have the capability to provide that information.
[RFC7616]の形式でソルティングとハッシュを使用する多数の展開済みパスワードデータベースがありますが、これらの展開にはクライアント（およびサーバー）によるnonceコントリビューションが必要であり、EAP-pwdには次の機能はありませんその情報を提供します。
For both parties to derive the same salted password, there needs to be a canonical method of salting a password. When using EAP-pwd, a password SHALL be salted by hashing the password followed by the salt using the designated hash function:
両方の当事者が同じソルト付きパスワードを導出するには、パスワードをソルトする正規の方法が必要です。 EAP-pwdを使用する場合、指定されたハッシュ関数を使用して、パスワードをハッシュしてからソルトを実行することにより、パスワードをソルトする必要があります。
salted-password = Hash(password | salt)
salted-password = Hash（password | salt）
The server stores the salted-password, and the salt, in its database and the client derives the salted password on the fly.
サーバーはソルト付きパスワードとソルトをデータベースに保存し、クライアントはオンザフライでソルト付きパスワードを導出します。
Different algorithms are supported with the UNIX crypt() function. The particular algorithm used is indicated by prepending an encoding of "setting" to the passed salt. The specific algorithm used is opaque to EAP-pwd as the entire salt, including the encoded "setting", is passed as an opaque string for interpretation by crypt(). The salted password used for EAP-pwd SHALL be the output of crypt():
UNIX crypt()関数では、さまざまなアルゴリズムがサポートされています。使用される特定のアルゴリズムは、渡されたソルトに「設定」のエンコーディングを付加することで示されます。使用される特定のアルゴリズムは、暗号化された「設定」を含むソルト全体がcrypt()による解釈のために不透明な文字列として渡されるため、EAP-pwdに対して不透明です。 EAP-pwdに使用されるソルトパスワードは、crypt()の出力である必要があります。
salted-password = crypt(password, salt)
salted-password = crypt（パスワード、ソルト）
The server stores the salted-password, and the encoded algorithm plus salt, in its database and the client derives the salted-password on-the-fly.
サーバーはソルト付きパスワード、およびエンコードされたアルゴリズムとソルトをデータベースに保存し、クライアントはオンザフライでソルト付きパスワードを導出します。
If the server indicates a crypt() algorithm that is unsupported by the client, the exchange fails and the client MUST terminate the connection.
サーバーがクライアントでサポートされていないcrypt()アルゴリズムを示している場合、交換は失敗し、クライアントは接続を終了する必要があります。
The scrypt function takes several parameters:
scrypt関数はいくつかのパラメーターを取ります。
o N, the cost parameter
o N、コストパラメータ
o r, the block size
o r、ブロックサイズ
o p, the parallelization parameter
o p、並列化パラメーター
o dkLen, the length of the output
o dkLen、出力の長さ
These parameters are encoded into the "salt" field of the modified EAP-pwd message. Parameters r and dkLen SHALL be 16-bit integers in network order. The other parameters SHALL each be 32-bit integers in network order. The "salt" field that gets transmitted in EAP-pwd SHALL therefore be:
これらのパラメータは、変更されたEAP-pwdメッセージの「塩」フィールドにエンコードされます。パラメータrおよびdkLenは、ネットワーク順で16ビット整数である必要があります。他のパラメータは、ネットワーク順に32ビット整数である必要があります。したがって、EAP-pwdで送信される「塩」フィールドは次のようにする必要があります。
N || r || p || dkLen || salt
N || r || p || dkLen ||塩
where || represents concatenation.
どこ||連結を表します。
The value of N represents the exponent taken to the power of two in order to determine the CPU/Memory cost of scrypt -- i.e., the value is 2^N. Per [RFC7914], the resulting CPU/Memory cost value SHALL be less than 2^(128 * r / 8), and the value p SHALL be less than or equal to ((2^32 - 1) * 32) / (128 * r).
Nの値は、scryptのCPU /メモリコストを決定するために、2の累乗の指数を表します。つまり、値は2 ^ Nです。 [RFC7914]により、結果のCPU /メモリコスト値は2 ^（128 * r / 8）未満である必要があり、値pは（（2 ^ 32-1）* 32）/（以下である必要があります） 128 * r）。
Note: EAP-pwd uses the salted password directly as the authentication credential and will hash it with a counter in order to obtain a secret element in a finite field. Therefore, it makes little sense to use dkLen greater than the length of the digest produced by the underlying hash function, but the capability is provided to do so anyway.
注：EAP-pwdは、ソルトされたパスワードを認証資格情報として直接使用し、有限フィールドの秘密要素を取得するためにそれをカウンターでハッシュします。したがって、基になるハッシュ関数によって生成されるダイジェストの長さよりも大きいdkLenを使用することはほとんど意味がありませんが、とにかくそうする機能が提供されています。
The PBKDF2 function requires two parameters:
PBKDF2関数には2つのパラメーターが必要です。
o c, the iteration count
o c、反復回数
o dkLen, the length of the output These parameters are encoded into the "salt" field of the modified EAP-pwd message. The parameters SHALL be 16-bit integers in network order. The "salt" field that gets transmitted in EAP-pwd SHALL therefore be:
o dkLen、出力の長さこれらのパラメーターは、変更されたEAP-pwdメッセージの「salt」フィールドにエンコードされます。パラメータは、ネットワーク順で16ビット整数である必要があります（SHALL）。したがって、EAP-pwdで送信される「塩」フィールドは次のようにする必要があります。
c || dkLen || salt
c || dkLen ||塩
where || represents concatenation.
どこ||連結を表します。
Note: EAP-pwd uses the salted password directly as the authentication credential and will hash it with a counter in order to obtain a secret element in a finite field. Therefore, it makes little sense to use a dkLen greater than the length of the digest produced by the underlying hash function, but the capability is provided to do so anyway.
注：EAP-pwdは、ソルトされたパスワードを認証資格情報として直接使用し、有限フィールドの秘密要素を取得するためにそれをカウンターでハッシュします。したがって、基になるハッシュ関数によって生成されるダイジェストの長さよりも大きいdkLenを使用することはほとんど意味がありませんが、とにかくそうする機能が提供されています。
Like all EAP methods, EAP-pwd is server initiated, and the initial identity supplied by the client is not useful for authentication purposes. Because of this, the server is required to indicate its intentions, including the password preprocessing it wishes to use, before it knows the true identity of the client. This prevents the server from supporting multiple salt digests simultaneously in a single password database. To support multiple salt digests simultaneously, it is necessary to maintain multiple password databases and use the routable portion of the client identity to select one when initiating EAP-pwd.
すべてのEAP方式と同様に、EAP-pwdはサーバーによって開始され、クライアントから提供される初期IDは認証には役立ちません。このため、サーバーは、クライアントの真の身元を知る前に、使用したいパスワードの前処理を含め、その意図を示す必要があります。これにより、サーバーが単一のパスワードデータベースで同時に複数のソルトダイジェストをサポートすることを防ぎます。複数のソルトダイジェストを同時にサポートするには、複数のパスワードデータベースを維持し、クライアントIDのルーティング可能な部分を使用して、EAP-pwdの開始時に1つを選択する必要があります。
The server uses the EAP-pwd-ID/Request to indicate the password preprocessing technique. The client indicates its acceptance of the password preprocessing technique and identifies itself in the EAP-pwd-ID/Response. If the client does not accept any of the offered preprocessing techniques, it SHALL terminate the exchange. Upon receipt of the EAP-pwd-ID/Response, the server knows the identity of the client and can look up the client's salted password and the salt from the database. The server adds the length of the salt and the salt itself to the EAP-pwd-Commit/Request message (see Section 2.7).
サーバーはEAP-pwd-ID / Requestを使用して、パスワードの前処理手法を示します。クライアントは、パスワード前処理手法の受け入れを示し、EAP-pwd-ID / Responseで自身を識別します。クライアントが提供された前処理手法のいずれも受け入れない場合は、交換を終了する必要があります。 EAP-pwd-ID / Responseを受信すると、サーバーはクライアントのIDを認識し、データベースからクライアントのソルトパスワードとソルトを検索できます。サーバーはソルトの長さとソルト自体をEAP-pwd-Commit / Requestメッセージに追加します（セクション2.7を参照）。
The server can fix the password element (Section 2.8.3 of [RFC5931]) as soon as the salted password has been looked up in the database. The client, though, is required to wait until receipt of the server's EAP-pwd-Commit/Request before it begins fixing the password element.
ソルトされたパスワードがデータベースで検索されるとすぐに、サーバーはパスワード要素を修正できます（[RFC5931]のセクション2.8.3）。ただし、クライアントは、パスワード要素の修正を開始する前に、サーバーのEAP-pwd-Commit / Requestを受信するまで待機する必要があります。
When a salted password preprocessing technique is agreed upon during the EAP-pwd-ID exchange, the EAP-pwd-Commit payload is modified to include the salt and salt length (see Figure 1). The server passes the salt and salt length in the EAP-pwd-Commit/Request; the client's EAP-pwd-Commit/Response is unchanged, and it MUST NOT echo the salt length and salt in its EAP-pwd-Commit/Response.
EAP-pwd-ID交換中にソルトパスワード前処理手法が合意されると、EAP-pwd-Commitペイロードがソルトとソルトの長さを含むように変更されます（図1を参照）。サーバーはソルトとソルトの長さをEAP-pwd-Commit / Requestで渡します。クライアントのEAP-pwd-Commit / Responseは変更されず、EAP-pwd-Commit / Responseのソルト長とソルトをエコーしてはなりません（MUST NOT）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt-len | |
+-+-+-+-+-+-+-+-+ ~
~ Salt +-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Element ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Scalar +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Salted EAP-pwd-Commit/Request
図1：Salted EAP-pwd-Commit / Request
The "salt-len" SHALL be non-zero, and it indicates the length, in octets, of the salt that follows. The "Salt" SHALL be a binary string. The "Element" and "Scalar" are encoded according to Section 3.3 of [RFC5931].
"salt-len"は0以外である必要があり、それに続くソルトの長さをオクテットで示します。 「塩」はバイナリ文字列である必要があります。 「要素」と「スカラー」は、[RFC5931]のセクション3.3に従ってエンコードされます。
Note: when a non-salted password preprocessing method is used, for example, any of the methods from [RFC5931], the EAP-pwd-Commit payload MUST NOT be modified to include the salt and salt length.
注：[RFC5931]のメソッドなど、ソルト化されていないパスワードの前処理メソッドを使用する場合、EAP-pwd-Commitペイロードを変更してソルトとソルト長を含めることはできません。
IANA has allocated fourteen (14) values from the "password preprocessing method registry" established by [RFC5931].
IANAは、[RFC5931]によって確立された「パスワード前処理メソッドレジストリ」から14個の値を割り当てました。
EAP-pwd requires each side to produce an identical representation of the (processed) password before the password element can be fixed. This symmetry undercuts one of the benefits to salting a password database because the salted password from a compromised database can be used directly to impersonate the EAP-pwd client -- since the plaintext password need not be recovered, no dictionary attack is needed. While the immediate effect of such a compromise would be compromise of the server, the per-user salt would still prevent the adversary from recovering the password, barring a successful dictionary attack, to use for other purposes.
EAP-pwdでは、パスワード要素を修正する前に、両側で（処理された）パスワードの同一の表現を生成する必要があります。この対称性は、侵害されたデータベースのソルトパスワードを直接使用してEAP-pwdクライアントを偽装できるため、パスワードデータベースをソルトする利点の1つを下回ります-プレーンテキストのパスワードを回復する必要がないため、辞書攻撃は必要ありません。このような侵害の直接の影響はサーバーの侵害ですが、ユーザーごとのソルトは、他の目的で使用するために、攻撃者がパスワードを回復し、辞書攻撃が成功しないようにします。
Salted password databases used with EAP-pwd MUST be afforded the same level of protection as databases of plaintext passwords.
EAP-pwdで使用されるソルトパスワードデータベースは、プレーンテキストパスワードのデータベースと同じレベルの保護を提供する必要があります。
Hashing a password with a salt increases the work factor for an attacker to obtain the cleartext password, but dedicated hardware makes this increased work factor increasingly negligible in real-world scenarios. Cleartext password databases SHOULD be protected with a scheme that uses a sequential memory hard function such as [RFC7914].
ソルトを使用してパスワードをハッシュすると、攻撃者が平文パスワードを取得するための作業係数が増加しますが、専用のハードウェアにより、この増加した作業係数は実際のシナリオでは無視できるほど大きくなります。クリアテキストパスワードデータベースは、[RFC7914]などのシーケンシャルメモリハード機能を使用するスキームで保護する必要があります（SHOULD）。
EAP-pwd sends the salt in the clear. If EAP-pwd is not tunneled in another, encrypting, EAP method, an adversary that can observe traffic from server to authenticator or from authenticator to client would learn the salt used for a particular user. While knowledge of a salt by an adversary may be of a somewhat dubious nature (pre-image resistance of the hash function used will protect the client's password and, as noted above, the database of salted passwords must still be protected from disclosure), it does represent potential additional meta-data in the hands of a untrusted third party.
EAP-pwdは平文でソルトを送信します。 EAP-pwdが別の暗号化EAP方式でトンネリングされていない場合、サーバーからオーセンティケーターへの、またはオーセンティケーターからクライアントへのトラフィックを監視できる攻撃者は、特定のユーザーに使用されるソルトを学習します。敵対者によるソルトの知識は、いくぶん疑わしい性質のものである可能性があります（使用されるハッシュ関数のイメージ前の耐性は、クライアントのパスワードを保護し、前述のように、ソルトされたパスワードのデータベースは開示から保護する必要があります）。信頼できない第三者の手に渡る潜在的な追加のメタデータを表します。
[CRY] Linux Programmer's Manual, "CRYPT(3)", August 2015, <http://man7.org/linux/man-pages/man3/crypt.3.html>.
[CRY] Linux Programmer's Manual、「CRYPT（3）」、2015年8月、<http://man7.org/linux/man-pages/man3/crypt.3.html>。
[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>。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <http://www.rfc-editor.org/info/rfc3454>.
[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、DOI 10.17487 / RFC3454、2002年12月、<http://www.rfc-editor.org/info/ rfc3454>。
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, DOI 10.17487/RFC5931, August 2010, <http://www.rfc-editor.org/info/rfc5931>.
[RFC5931] Harkins、D。およびG. Zorn、「パスワードのみを使用した拡張認証プロトコル（EAP）認証」、RFC 5931、DOI 10.17487 / RFC5931、2010年8月、<http://www.rfc-editor.org/ info / rfc5931>。
[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>。
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, August 2016, <http://www.rfc-editor.org/info/rfc7914>.
[RFC7914] Percival、C。およびS. Josefsson、「The scrypt Password-Based Key Derivation Function」、RFC 7914、DOI 10.17487 / RFC7914、2016年8月、<http://www.rfc-editor.org/info/rfc7914 >。
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, <http://www.rfc-editor.org/info/rfc8018>.
[RFC8018] Moriarty、K.、Ed。、Kaliski、B。、およびA. Rusch、「PKCS＃5：Password-Based Cryptography Specification Version 2.1」、RFC 8018、DOI 10.17487 / RFC8018、2017年1月、<http：/ /www.rfc-editor.org/info/rfc8018>。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[SHS]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<http://csrc.nist.gov/ Publications / fips / fips180-4 / fips-180-4.pdf>。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D。、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<http：//www.rfc- editor.org/info/rfc7616>。
[RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 10.17487/RFC7664, November 2015, <http://www.rfc-editor.org/info/rfc7664>.
[RFC7664] Harkins、D。、編、「Dragonfly Key Exchange」、RFC 7664、DOI 10.17487 / RFC7664、2015年11月、<http://www.rfc-editor.org/info/rfc7664>。
Acknowledgements
謝辞
Thanks to Stefan Winter and the eduroam project for its continued interest in using EAP-pwd. Thanks to Simon Josefsson for his advice on support for scrypt and PBKDF2.
EAP-pwdの使用に継続的に関心を寄せてくれたStefan Winterとeduroamプロジェクトに感謝します。 scryptとPBKDF2のサポートに関するアドバイスをくれたSimon Josefssonに感謝します。
Author's Address
著者のアドレス
Dan Harkins HP Enterprise 3333 Scott Boulevard Santa Clara, CA 95054 United States of America
Dan Harkins HP Enterprise 3333 Scott Boulevard Santa Clara、CA 95054アメリカ合衆国
Email: dharkins@arubanetworks.com