Internet Engineering Task Force (IETF) D. Harkins
Request for Comments: 8146 HP Enterprise
Updates: 5931 April 2017
Category: Informational
ISSN: 2070-1721
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添加对salt密码数据库的支持
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 Challenge Handshake Authentication Protocol version 2（MSCHAPv2）风格的密码双散列，但不包括对附加密码的支持。有许多现有的salt密码数据库，允许它们与EAP pwd一起使用是可取的。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. 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
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.
存储密码的数据库是一个有吸引力的攻击目标——访问数据库，了解密码。为了混淆这些攻击，随机的“salt”与密码一起散列，结果摘要与salt一起存储，而不是原始密码。这具有随机化密码的效果；即使两个不同的用户选择了相同的密码，存储的密码和腌制的密码也会不同。它还要求危害存储数据库安全的对手对每个条目发起字典攻击，以恢复密码。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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基于“蜻蜓”密码认证密钥交换（PAKE）——请参阅[RFC7664]。这是一个平衡的PAKE，要求协议各方获得已处理密码的相同表示（见第4节）。因此，密码的盐析被视为EAP pwd的额外密码预处理技术。服务器将要使用的salt和摘要传送给对等方，并在修复密码元素之前对密码进行处理（参见[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:PBKDF2与SHA-256
o 0x09: PBKDF2 with SHA-512
o 0x09:PBKDF2与SHA-512
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-then UNIX-crypt（）
o 0x0E: OpaqueString then scrypt
o 0x0E:OpaqueString然后是scrypt
o 0x0F: OpaqueString then PBKDF2 with SHA-256
o 0x0F:带SHA-256的不透明字符串，然后是PBKDF2
o 0x10: OpaqueString then PBKDF2 with SHA-512
o 0x10：不透明字符串，然后是带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.
传递salt时，salt的大小应至少与使用的哈希算法的消息摘要一样长。无法保证已部署的salt数据库遵循此规则，并且为了互操作性的利益，如果交换期间传输的salt长度小于指定哈希算法的消息摘要，则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]）对传递的salt文件提出了额外的格式要求。见下文。
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已被弃用，但存在使用SASLprep处理的数据库；有必要为它们提供代码点。使用时
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，根据[RFC3454]，密码应视为“存储字符串”；因此，禁止未指定的代码点。SASLprep的输出应为已处理UTF-8字符串的二进制表示。SASLprep预处理中遇到的禁止输出和未分配代码点将导致预处理失败，且输出不得与EAP pwd一起使用。
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.
当执行一种预处理技术（0x0E-0x10）时，密码应为UTF-8字符串，并应通过将[RFC7613]中的不透明字符串配置文件的准备和实施步骤应用于密码进行预处理。OpaqueString（也是UTF-8字符串）的输出将成为EAP pwd密码，并应使用指定的算法进行散列。
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]样式的satting和hashing，但这些部署需要客户端（以及服务器）的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:
为了让双方都获得相同的salt密码，需要有一种规范的salt密码方法。当使用EAP pwd时，应使用指定的散列函数对密码进行散列，然后再对salt进行散列，从而对密码进行加密：
salted-password = Hash(password | salt)
salt密码=散列（密码| salt）
The server stores the salted-password, and the salt, in its database and the client derives the salted password on the fly.
服务器将salt密码和salt存储在其数据库中，客户机动态地获取salt密码。
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（）函数支持不同的算法。所使用的特定算法通过在传递的salt前面加上“setting”编码来表示。使用的特定算法对EAP pwd是不透明的，因为整个salt（包括编码的“设置”）作为不透明字符串传递，以供crypt（）解释。EAP pwd使用的salt密码应为crypt（）的输出：
salted-password = crypt(password, salt)
salt password=crypt（密码，salt）
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.
服务器将salt密码和编码算法加salt存储在其数据库中，客户机动态地获取salt密码。
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消息的“salt”字段中。参数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^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将salt密码直接用作身份验证凭据，并将使用计数器对其进行哈希运算，以获得有限字段中的秘密元素。因此，使用大于底层哈希函数生成的摘要长度的dkLen没有什么意义，但提供了这样做的功能。
The PBKDF2 function requires two parameters:
PBKDF2函数需要两个参数：
o c, the iteration count
o c、 迭代计数
o dkLen, the length of the output
o dkLen，输出的长度
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:
这些参数被编码到修改后的EAP pwd消息的“salt”字段中。参数应为网络顺序的16位整数。因此，在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将salt密码直接用作身份验证凭据，并将使用计数器对其进行哈希运算，以获得有限字段中的秘密元素。因此，使用大于底层哈希函数生成的摘要长度的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是由服务器启动的，客户端提供的初始标识对于身份验证没有用处。因此，服务器需要在知道客户机的真实身份之前指出其意图，包括它希望使用的密码预处理。这将防止服务器在单个密码数据库中同时支持多个salt摘要。为了同时支持多个salt摘要，有必要维护多个密码数据库，并在启动EAP pwd时使用客户端标识的可路由部分选择一个。
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/请求指示密码预处理技术。客户机表示接受密码预处理技术，并在EAP pwd ID/响应中标识自己。如果客户不接受所提供的任何预处理技术，则应终止交易所。在收到EAP pwd ID/响应后，服务器知道客户端的身份，并可以从数据库中查找客户端的salt密码和salt。服务器将salt的长度和salt本身添加到EAP pwd提交/请求消息中（参见第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.
一旦在数据库中查找了salt密码，服务器就可以修复密码元素（RFC5931的第2.8.3节）。不过，客户机需要等到收到服务器的EAP pwd提交/请求后才开始修复密码元素。
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交换过程中同意salt密码预处理技术时，将修改EAP pwd提交有效负载，以包括salt和salt长度（见图1）。服务器在EAP pwd提交/请求中传递salt和salt长度；客户端的EAP pwd提交/响应保持不变，并且它不能在其EAP pwd提交/响应中回显salt长度和salt。
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 +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：SALT EAP pwd提交/请求
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”应为非零，并以八位字节表示后面的salt长度。“Salt”应为二进制字符串。根据[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.
注意：当使用非salt密码预处理方法时，例如[RFC5931]中的任何方法，EAP pwd提交有效负载不得修改为包含salt和salt长度。
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客户端——因为不需要恢复明文密码，所以不需要字典攻击。虽然这种妥协的直接影响是服务器的妥协，但每个用户的salt仍然会阻止对手恢复密码，除非成功进行字典攻击，以用于其他目的。
Salted password databases used with EAP-pwd MUST be afforded the same level of protection as databases of plaintext passwords.
与EAP pwd一起使用的salt密码数据库必须提供与明文密码数据库相同的保护级别。
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].
用salt散列密码会增加攻击者获取明文密码的工作系数，但专用硬件使这种增加的工作系数在现实场景中变得越来越微不足道。明文密码数据库应采用使用顺序内存硬函数（如[RFC7914]）的方案进行保护。
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方法中进行隧道传输，则可以观察从服务器到身份验证器或从身份验证器到客户端的流量的对手将了解用于特定用户的salt。虽然对手对salt的了解可能有点可疑（使用的哈希函数的镜像前抵抗将保护客户端的密码，如上所述，salt密码数据库仍必须受到保护以防泄露），但它确实代表了不受信任的第三方手中潜在的额外元数据。
[CRY] Linux Programmer's Manual, "CRYPT(3)", August 2015, <http://man7.org/linux/man-pages/man3/crypt.3.html>.
[CRY]Linux程序员手册，“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，“国际化字符串的准备（“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，“基于scrypt密码的密钥派生函数”，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：基于密码的加密规范版本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]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-42015年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摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年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.，Ed.，“蜻蜓密钥交换”，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.
感谢Stefan Winter和eduroam项目对使用EAP pwd的持续兴趣。感谢Simon Josefsson就支持scrypt和PBKDF2提供的建议。
Author's Address
作者地址
Dan Harkins HP Enterprise 3333 Scott Boulevard Santa Clara, CA 95054 United States of America
美国加利福尼亚州圣克拉拉斯科特大道3333号Dan Harkins HP Enterprise 95054
Email: dharkins@arubanetworks.com
Email: dharkins@arubanetworks.com