Internet Research Task Force (IRTF) J. Schmidt
Request for Comments: 8125 secunet Security Networks
Category: Informational April 2017
ISSN: 2070-1721
Internet Research Task Force (IRTF) J. Schmidt
Request for Comments: 8125 secunet Security Networks
Category: Informational April 2017
ISSN: 2070-1721
Requirements for Password-Authenticated Key Agreement (PAKE) Schemes
密码认证密钥协议（PAKE）方案的要求
Abstract
摘要
Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG).
密码认证密钥协议（PAKE）方案是一种交互式协议，允许参与者相互认证，并使用（较弱的）共享密码导出共享密钥。本文件审查了不同类型的PAKE方案。此外，它还向新方案的设计者提出了要求和建议。它是加密论坛研究小组（CFRG）的产品。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究工作组（IRTF）加密论坛研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见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/rfc8125.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8125.
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. PAKE Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Storage of the Password . . . . . . . . . . . . . . . . . 3
3.2. Transmission of Public Keys . . . . . . . . . . . . . . . 4
3.3. Two Party versus Multiparty . . . . . . . . . . . . . . . 4
4. Security of PAKEs . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Implementation Aspects . . . . . . . . . . . . . . . . . 6
4.2. Special Case: Elliptic Curves . . . . . . . . . . . . . . 6
5. Protocol Considerations and Applications . . . . . . . . . . 7
6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. PAKE Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Storage of the Password . . . . . . . . . . . . . . . . . 3
3.2. Transmission of Public Keys . . . . . . . . . . . . . . . 4
3.3. Two Party versus Multiparty . . . . . . . . . . . . . . . 4
4. Security of PAKEs . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Implementation Aspects . . . . . . . . . . . . . . . . . 6
4.2. Special Case: Elliptic Curves . . . . . . . . . . . . . . 6
5. Protocol Considerations and Applications . . . . . . . . . . 7
6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Passwords are the predominant method of accessing the Internet today due, in large part, to their intuitiveness and ease of use. Since a user needs to enter passwords repeatedly in many connections and applications, these passwords tend to be easy to remember and can be entered repeatedly with a low probability of error. They tend to be low-grade and not-so-random secrets that are susceptible to brute-force guessing attacks.
密码是当今访问互联网的主要方法，这在很大程度上是由于其直观性和易用性。由于用户需要在许多连接和应用程序中重复输入密码，因此这些密码易于记忆，并且可以以较低的错误概率重复输入。它们往往是低级的、不那么随机的秘密，容易受到暴力猜测攻击。
A Password-Authenticated Key Exchange (PAKE) attempts to address this issue by constructing a cryptographic key exchange that does not result in the password, or password-derived data, being transmitted across an unsecured channel. Two parties in the exchange prove possession of the shared password without revealing it. Such exchanges are therefore resistant to offline, brute-force dictionary attacks. The idea was initially described by Bellovin and Merritt in [BM92] and has received considerable cryptographic attention since then. PAKEs are especially interesting due to the fact that they can achieve mutual authentication without requiring any Public Key Infrastructure (PKI).
密码认证密钥交换（PAKE）试图通过构造不会导致密码或密码衍生数据通过不安全通道传输的加密密钥交换来解决此问题。交易所中的两方证明拥有共享密码，但不泄露密码。因此，此类交换可以抵抗离线、暴力字典攻击。这个想法最初由Bellovin和Merritt在[BM92]中描述，并从那时起受到了相当大的密码关注。PAKEs特别有趣，因为它们可以在不需要任何公钥基础设施（PKI）的情况下实现相互身份验证。
Different types of PAKE schemes are reviewed in this document. It defines requirements for new schemes and gives additional recommendations for designers of PAKE schemes. The specific recommendations are discussed throughout Sections 3-7. Section 8 summarizes the requirements.
本文件审查了不同类型的PAKE方案。它定义了新方案的要求，并为PAKE方案的设计者提供了额外的建议。具体建议将在第3-7节中讨论。第8节总结了这些要求。
The requirements mentioned in this document have been discussed with active members and represent the consensus of the Crypto Forum Research Group (CFRG).
本文件中提到的要求已与活跃成员讨论过，代表了加密论坛研究小组（CFRG）的共识。
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]中所述进行解释。
Broadly speaking, different PAKEs satisfy their goals in a number of common ways. This leads to various design choices: how public keys are transmitted (encrypted or not), whether both parties possess the same representation of the password (balanced versus augmented), and the number of parties (two party versus multiparty).
从广义上讲，不同的PAKEs以许多共同的方式实现他们的目标。这导致了各种设计选择：如何传输公钥（加密与否）、双方是否拥有相同的密码表示形式（平衡与增强），以及参与方的数量（双方与多方）。
When both sides of a PAKE store the same representation of the password, the PAKE is said to be "balanced". In a balanced PAKE, the password can be stored directly in a salted state by hashing it with a random salt or by representing the credential as an element in a finite field (by, for instance, multiplying a generator from a finite field and the password represented as a number to produce a "password element"). The benefits of such PAKEs are that they are applicable to situations where either party can initiate the exchange or both parties can initiate simultaneously, i.e., where they both believe themselves to be the "initiator". This sort of PAKE can be useful for mesh networking (see, for example, [DOT11]) or Internet of Things applications.
当PAKE的两侧存储相同的密码表示时，PAKE被称为“平衡”。在平衡PAKE中，可以通过使用随机salt散列密码，或通过将凭证表示为有限字段中的元素（例如，通过将有限字段中的生成器与表示为数字的密码相乘，生成“密码元素”）将密码直接存储在salt状态。此类PAKE的好处在于，它们适用于任何一方可以发起交易或双方可以同时发起的情况，即双方都认为自己是“发起人”。这种PAKE对于网状网络（例如，参见[DOT11]）或物联网应用程序非常有用。
When one side maintains a transform of the password and the other maintains the raw password, the PAKE is said to be "augmented". Typically, a client will maintain the raw password (or some representation of it as in the balanced case), and a server will maintain a transformed element generated with a one-way function. The benefit of an augmented PAKE is that it provides some protection for the server's password in a way that is not possible with a balanced PAKE. In particular, an adversary that has successfully obtained the server's PAKE credentials cannot directly use them to
当一方维护密码转换，另一方维护原始密码时，PAKE被称为“增强”。通常，客户机将维护原始密码（或在平衡情况下的一些表示），服务器将维护使用单向函数生成的转换元素。增强的PAKE的好处是，它以一种平衡的PAKE所不可能的方式为服务器的密码提供了一些保护。特别是，成功获得服务器PAKE凭据的对手不能直接使用这些凭据进行攻击
impersonate the users to other servers. The adversary has to learn the individual passwords first, e.g., by performing an (offline) dictionary attack. This sort of PAKE is useful for strict client-server protocols such as the one discussed in [RFC5246].
将用户模拟到其他服务器。对手必须首先学习个人密码，例如，通过执行（离线）字典攻击。这种PAKE对于严格的客户机-服务器协议非常有用，如[RFC5246]中讨论的协议。
All known PAKEs use public key cryptography. A fundamental difference in PAKEs is how the public key is communicated in the exchange.
所有已知的PAKE都使用公钥加密。PAKEs的一个根本区别是公钥在交换中的传递方式。
One class of PAKEs uses symmetric key cryptography, with a key derived from the password, to encrypt an ephemeral public key. The ability of the peer to demonstrate that it has successfully decrypted the public key proves knowledge of the shared password. Examples of this exchange include the first PAKE, called the "Encrypted Key Exchange (EKE)", which was introduced in [BM92].
一类PAKEs使用对称密钥加密技术（密钥来自密码）对临时公钥进行加密。对等方证明其已成功解密公钥的能力证明其了解共享密码。这种交换的例子包括在[BM92]中引入的第一种PAKE，称为“加密密钥交换（EKE）”。
Another class of PAKEs transmits unencrypted public keys, like the J-PAKE (Password Authenticated Key Exchange by Juggling) protocol [JPAKE]. During key agreement, ephemeral public keys and values derived using the shared password are exchanged. If the passwords match, both parties can compute a common secret by combining password, public keys, and private keys. The SPEKE (Strong Password-Only Authenticated Key Exchange) [SPEKE] scheme also exchanges public keys, namely Diffie-Hellman values. Here, the generator for the public keys is derived from the shared secret. Afterwards, only the public Diffie-Hellman values are exchanged; the generator is kept secret. In both cases, the values that are transmitted across the unsecured medium are elements in a finite field and not a random blob.
另一类PAKEs传输未加密的公钥，如J-PAKE（通过杂耍进行密码验证的密钥交换）协议[JPAKE]。在密钥协商期间，交换临时公钥和使用共享密码派生的值。如果密码匹配，双方可以通过组合密码、公钥和私钥来计算公共密钥。SPEKE（仅强密码认证密钥交换）[SPEKE]方案还交换公钥，即Diffie-Hellman值。这里，公钥的生成器是从共享密钥派生的。之后，只交换公众的Diffie-Hellman价值观；发电机是保密的。在这两种情况下，通过非安全介质传输的值都是有限域中的元素，而不是随机blob。
A combination of EKE and SPEKE is used in PACE as described in [BFK09], which is, e.g., used in international travel documents. In this method, a nonce is encrypted rather than a key. This nonce is used to generate a common base for the key agreement. Without knowing the password, the nonce cannot be determined; hence, the subsequent key agreement will fail.
EKE和SPEKE的组合用于[BFK09]中所述的PACE，例如用于国际旅行证件。在这种方法中，nonce是加密的，而不是密钥。此nonce用于生成密钥协议的公共基础。在不知道密码的情况下，无法确定当前值；因此，随后的密钥协议将失败。
The majority of PAKE protocols allow two parties to agree on a shared key based on a shared password. Nevertheless, there exist proposals that allow key agreement for more than two parties. Those protocols allow key establishment for a group of parties and are hence called "Group PAKEs" or "GPAKEs". Examples of such protocols can be found in [ABCP06], while [ACGP11] and [HYCS15] propose a generic construction that allows the transformation of any two-party PAKE
大多数PAKE协议允许双方基于共享密码就共享密钥达成一致。尽管如此，仍然存在允许两个以上缔约方达成关键协议的提案。这些协议允许为一组参与方建立密钥，因此被称为“组密钥”或“GPAKEs”。此类协议的示例可在[ABCP06]中找到，而[ACGP11]和[HYCS15]提出了一种通用结构，允许任何两方PAKE的转换
into a GPAKE protocol. Another possibility of defining a multiparty PAKE protocol is to assume the existence of a trusted server with which each party shares a password. This server enables different parties to agree on a common secret key without the need to share a password among themselves. Each party has only a shared secret with the trusted server. For example, Abdalla et al. designed such a protocol as discussed in [AFP05].
进入GPAKE协议。定义多方PAKE协议的另一种可能性是假设存在一个可信服务器，每一方共享一个密码。此服务器使不同的参与方能够就公共密钥达成一致，而无需在他们之间共享密码。每一方仅与受信任服务器共享一个秘密。例如，Abdalla等人设计了[AFP05]中讨论的协议。
PAKE schemes are modeled on the scenario of two parties, typically Alice and Bob, who share a password (or perhaps Bob shares a function of the password) and would like to use it to establish a secure session key over an untrusted link. There is a powerful adversary, typically Eve, who would like to subvert the exchange. Eve has access to a dictionary that is likely to contain Alice and Bob's password, and Eve is capable of enumerating through the dictionary in a brute-force manner to try and discover Alice and Bob's password.
PAKE方案模拟了两方的场景，通常是Alice和Bob，他们共享一个密码（或者Bob共享密码的一个功能），并希望使用该密码在不受信任的链接上建立安全会话密钥。有一个强大的对手，通常是夏娃，想要颠覆交易所。Eve可以访问可能包含Alice和Bob密码的词典，并且Eve能够以蛮力方式枚举词典，以尝试发现Alice和Bob的密码。
All PAKEs have a limitation. If Eve guesses the password, she can subvert the exchange. It is therefore necessary to model the likelihood that Eve will guess the password to access the security of a PAKE. If the probability of her discovering the password is a function of interaction with the protocol participants and not a function of computation, then the PAKE is secure (that is, Eve is unable to take information from a passive attack or from a single active attack). Thus, she cannot enumerate through her dictionary without interacting with Alice or Bob for each password guess, i.e., the only attack left is repeated guessing. Eve learns one thing from a single active attack: whether her single guess is correct or not.
所有的帕克人都有一个限制。如果Eve猜到了密码，她就可以破坏交换。因此，有必要对Eve猜测密码以访问PAKE安全性的可能性进行建模。如果她发现密码的概率是与协议参与者交互的函数，而不是计算的函数，则PAKE是安全的（即Eve无法从被动攻击或单个主动攻击中获取信息）。因此，她无法在没有与Alice或Bob交互的情况下通过字典枚举每个密码猜测，即，剩下的唯一攻击是重复猜测。伊芙从一次主动攻击中学到一件事：她的猜测是否正确。
In other words, the security of a PAKE scheme is based on the idea that Eve, who is trying to impersonate Alice, cannot efficiently verify a password guess without interacting with Bob (or Alice). If she were to interact with either, she would thereby be detected. Thus, it is important to balance restricting the number of allowed authentication attempts with the potential of a denial-of-service vulnerability. In order to judge and compare the security of PAKE schemes, security proofs in commonly accepted models SHOULD be used. Each proof and model, however, is based on assumptions. Often, security proofs show that if an adversary is able to break the scheme, the adversary is also able to solve a problem that is assumed to be hard, such as computing a discrete logarithm. By conversion, breaking the scheme is considered to be a hard problem as well.
换句话说，PAKE方案的安全性是基于这样一个想法：Eve试图模仿Alice，如果不与Bob（或Alice）交互，就无法有效地验证密码猜测。如果她与其中任何一方互动，她就会被发现。因此，在限制允许的身份验证尝试次数与潜在的拒绝服务漏洞之间取得平衡非常重要。为了判断和比较PAKE方案的安全性，应该使用普遍接受的模型中的安全性证明。然而，每个证明和模型都是基于假设的。通常，安全性证明表明，如果对手能够破坏方案，那么对手也能够解决被认为很难解决的问题，例如计算离散对数。通过转换，打破方案也被认为是一个难题。
A PAKE scheme SHOULD be accompanied with a security proof with clearly stated assumptions and models used. In particular, the proof MUST show that the probability is negligible that an active adversary
PAKE方案应附有安全证明，并附有明确说明的假设和使用的模型。特别是，证据必须表明，主动对手
would be able to pass authentication, learn additional information about the password, or learn anything about the established key. Moreover, the authors MAY specify which underlying primitives are to be used with the scheme or MAY consider specific use cases or assumptions like resistance to quantum computers. A clear and comprehensive proof is the foundation for users to trust in the security of the scheme.
将能够通过身份验证，了解有关密码的其他信息，或了解有关已建立密钥的任何信息。此外，作者可以指定哪些基本图元将被用于该方案，或者可以考虑特定的使用情况或假设，例如对量子计算机的抵抗。一个清晰全面的证明是用户信任该方案安全性的基础。
Aside from the theoretical security of a scheme, practical implementation pitfalls have to be considered as well. If not carefully implemented, even a scheme that is secure in a well-defined mathematical model can leak information via side channels. The design of the scheme might allow or prevent easy protection against information leakage. In a network scenario, an adversary can measure the time that the computation of an answer takes and derive information about secret parameters of the scheme. If a device operates in a potentially hostile environment, such as a smart card, other side channels like power consumption and electromagnetic emanations or even active implementation attacks have to be taken into account as well.
除了方案的理论安全性外，还必须考虑实际的实施陷阱。如果不小心实施，即使在定义良好的数学模型中是安全的方案也可能通过侧通道泄漏信息。该方案的设计可能允许或防止容易的信息泄漏保护。在网络场景中，对手可以测量答案计算所需的时间，并获得有关方案秘密参数的信息。如果设备在潜在的敌对环境（如智能卡）中运行，则还必须考虑其他侧通道，如功耗和电磁辐射，甚至主动实施攻击。
The developers of a scheme SHOULD keep the implementation aspects in mind and show how to implement the protocol in constant time. Furthermore, adding a discussion about how to protect implementations of the scheme in potential hostile environments is encouraged.
方案的开发人员应该牢记实现方面，并展示如何在固定时间内实现协议。此外，还鼓励讨论如何在潜在的敌对环境中保护该方案的实施。
Since Elliptic Curve Cryptography (ECC) allows for a smaller key length compared to traditional schemes based on the discrete logarithm problem in finite fields at similar security levels, using ECC for PAKE schemes is also of interest. In contrast to schemes that can use the finite field element directly, an additional challenge has to be considered for some schemes based on ECC, namely the mapping of a random string to an element that can be computed with, i.e., a point on the curve. In some cases, the opposite is also needed, i.e., the mapping of a curve point to a string that is not distinguishable from a random one. When choosing a mapping, it is crucial to consider the implementation aspects as well.
由于与基于有限域离散对数问题的传统方案相比，椭圆曲线密码体制（ECC）允许更小的密钥长度，在类似的安全级别下，将ECC用于PAKE方案也很有意义。与可以直接使用有限域单元的方案相比，对于一些基于ECC的方案，必须考虑一个额外的挑战，即将随机字符串映射到可以用曲线上的点计算的单元。在某些情况下，还需要相反的方法，即曲线点到无法与随机点区分的字符串的映射。在选择映射时，考虑执行方面也是至关重要的。
If the PAKE scheme is intended to be used with ECC, the authors SHOULD state whether there is a mapping function needed and, if so, discuss its requirements. Alternatively, the authors MAY define a mapping to be used with the scheme.
如果PAKE方案打算与ECC一起使用，作者应说明是否需要映射功能，如果需要，应讨论其要求。或者，作者可以定义与方案一起使用的映射。
In most cases, the PAKE scheme is a building block in a more complex protocol like IPsec or Transport Layer Security (TLS). This can influence the choice of a suitable PAKE scheme. For example, an augmented scheme can be beneficial for protocols that have a strict server-client relationship. If both parties can initiate a connection of a protocol, a balanced PAKE might be more appropriate.
在大多数情况下，PAKE方案是更复杂协议（如IPsec或传输层安全性（TLS））中的构建块。这会影响选择合适的PAKE方案。例如，对于具有严格的服务器-客户机关系的协议，扩展方案可能是有益的。如果双方都可以启动协议连接，那么平衡的PAKE可能更合适。
A special variation of the network password problem, called "Password-Authenticated Key Distribution", is defined in [P1363] as password-authenticated key retrieval: "The retrieval of a key from a secure key repository or escrow requiring authentication derived in part from a password."
网络密码问题的一个特殊变体，称为“密码认证密钥分发”，在[P1363]中定义为密码认证密钥检索：“从安全密钥存储库或托管中检索密钥，需要部分来自密码的认证。”
In addition to key retrieval from escrow, there is also the variant of two parties exchanging public keys using a PAKE in lieu of certificates. In this variant, public keys can be encrypted using a password. Authentication key distribution can be performed because each side knows the private key associated with its unencrypted public key and can also decrypt the peer's public key. This technique can be used to transform a short, one-time code into a long-term public key.
除了从托管中检索密钥外，还有一种变体，即双方使用PAKE代替证书交换公钥。在此变体中，可以使用密码对公钥进行加密。可以执行身份验证密钥分发，因为每一方都知道与其未加密公钥相关联的私钥，并且还可以解密对等方的公钥。此技术可用于将短期一次性代码转换为长期公钥。
Another possible variant of a PAKE scheme allows combining authentication with certificates and the use of passwords. In this variant, the private key of the certificate is used to blind the password key agreement. For verification, the message is unblinded with the public key. A correct key establishment therefore implies the possession of the private key belonging to the certificate. This method enables one-sided authentication as well as mutual authentication when the password is used.
PAKE方案的另一个可能变体允许将身份验证与证书以及密码的使用相结合。在此变体中，证书的私钥用于屏蔽密码密钥协议。为了进行验证，消息将使用公钥解除盲显。因此，正确的密钥建立意味着拥有属于证书的私钥。此方法在使用密码时启用单边身份验证和相互身份验证。
The authors of a PAKE scheme MAY discuss variations of their scheme and explain application scenarios where these variations are beneficial. In particular, techniques that allow long-term (public) key agreement are encouraged.
PAKE方案的作者可以讨论其方案的变化，并解释这些变化有益的应用场景。特别是，鼓励使用允许长期（公开）密钥协商的技术。
In order to establish a connection, each party of the PAKE protocol needs to know the identity of its communication partner to identify the right password for the agreement. In cases where a user wants to establish a secure channel with a server, the user first has to let the server know which password to use by sending some kind of identifier to the server. If this identifier is not protected, everyone who is able to eavesdrop on the connection can identify the user. In order to prevent this and protect the privacy of the user,
为了建立连接，PAKE协议的每一方都需要知道其通信伙伴的身份，以确定协议的正确密码。在用户希望与服务器建立安全通道的情况下，用户首先必须通过向服务器发送某种标识符来让服务器知道使用哪个密码。如果此标识符未受到保护，则能够窃听连接的每个人都可以识别该用户。为了防止这种情况发生并保护用户的隐私，
the scheme might provide a way to protect the transmission of the user's identity. A simple way to protect the privacy of a user that communicates with a server is to use a public key provided by the server to encrypt the user's identity.
该方案可以提供一种保护用户身份传输的方法。保护与服务器通信的用户隐私的一种简单方法是使用服务器提供的公钥加密用户的身份。
The PAKE scheme MAY discuss special ideas and solutions about how to protect the privacy of the users of the scheme.
PAKE计划可能会讨论关于如何保护计划用户隐私的特殊想法和解决方案。
The performance of a scheme can be judged along different lines depending on the optimization goals of the target application. Potential metrics include latency, code size/area, power consumption, or exchanged messages. In addition, there might be application scenarios in which a constrained client communicates with a powerful server. In such a case, the scheme has to require minimal efforts on the client side. Note that for some clients, the computations might even be carried out in a hardware implementation, which requires different optimizations compared to software.
根据目标应用程序的优化目标，可以沿不同的路线判断方案的性能。潜在指标包括延迟、代码大小/面积、功耗或交换的消息。此外，在某些应用程序场景中，受约束的客户端可能与功能强大的服务器通信。在这种情况下，该方案只需要客户端的最小努力。请注意，对于某些客户端，计算甚至可能在硬件实现中执行，这与软件相比需要不同的优化。
Furthermore, the design of the scheme can influence the cost of protecting the implementation from adversaries exploiting its physical properties (see Section 4.1).
此外，方案的设计可能会影响保护实施免受利用其物理特性的对手攻击的成本（见第4.1节）。
The authors of a PAKE scheme MAY discuss their design choices and the influence of these choices on the performance. In particular, the optimization goals could be stated.
PAKE方案的作者可以讨论他们的设计选择以及这些选择对性能的影响。特别是，可以说明优化目标。
This section summarizes the requirements for PAKE schemes to be compliant with this document based on the previously discussed properties.
本节根据前面讨论的属性总结了PAKE方案符合本文件的要求。
REQ1: A PAKE scheme MUST clearly state its features regarding balanced/augmented versions.
要求1:PAKE方案必须明确说明其关于平衡/增强版本的特性。
REQ2: A PAKE scheme SHOULD come with a security proof and clearly state its assumptions and models.
要求2：PAKE方案应具有安全性证明，并明确说明其假设和模型。
REQ3: The authors SHOULD show how to protect their PAKE scheme implementation in hostile environments, particularly, how to implement their scheme in constant time to prevent timing attacks.
REQ3：作者应该展示如何在敌对环境中保护他们的PAKE方案实现，特别是如何在固定时间内实现他们的方案以防止定时攻击。
REQ4: If the PAKE scheme is intended to be used with ECC, the authors SHOULD discuss their requirements for a potential mapping or define a mapping to be used with the scheme.
要求4：如果PAKE方案拟与ECC一起使用，则作者应讨论其对潜在映射的要求，或定义与该方案一起使用的映射。
REQ5: The authors of a PAKE scheme MAY discuss its design choice with regard to performance, i.e., its optimization goals.
要求5：PAKE方案的作者可以讨论其性能方面的设计选择，即其优化目标。
REQ6: The authors of a scheme MAY discuss variations of their scheme that allow the use in special application scenarios. In particular, techniques that facilitate long-term (public) key agreement are encouraged.
要求6：方案的作者可以讨论其方案的变化，以允许在特殊应用场景中使用。特别是，鼓励使用有利于长期（公开）密钥协商的技术。
REQ7: Authors of a scheme MAY discuss special ideas and solutions on privacy protection of its users.
问题7：方案的作者可以讨论关于用户隐私保护的特殊想法和解决方案。
REQ8: The authors MUST follow the IRTF IPR policy <https://irtf.org/ipr>.
要求8：作者必须遵守IRTF知识产权政策<https://irtf.org/ipr>.
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
This document analyzes requirements for a cryptographic scheme. Security considerations are discussed throughout the document.
本文档分析加密方案的要求。整个文档中都讨论了安全注意事项。
[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>.
[ABCP06] Abdalla, M., Bresson, E., Chevassut, O., and D. Pointcheval, "Password-Based Group Key Exchange in a Constant Number of Rounds", PKC 2006, LNCS 3958, DOI 10.1007/11745853_28, 2006.
[ABCP06]Abdalla，M.，Bresson，E.，Chevassut，O.，和D.Pointcheval，“固定轮数下基于密码的组密钥交换”，PKC 2006，LNCS 3958，DOI 10.1007/11745853_28，2006。
[ACGP11] Abdalla, M., Chevalier, C., Granboulan, L., and D. Pointcheval, "Contributory Password-Authenticated Group Key Exchange with Join Capability", CT-RSA 2011, LNCS 6558, DOI 10.1007/978-3-642-19074-2_11, 2011.
[ACGP11]Abdalla，M.，Chevalier，C.，Granboulan，L.，和D.Pointcheval，“具有加入功能的贡献密码认证组密钥交换”，CT-RSA 2011，LNCS 6558，DOI 10.1007/978-3-642-19074-2_112011。
[AFP05] Abdalla, M., Fouque, P., and D. Pointcheval, "Password-Based Authenticated Key Exchange in the Three-Party Setting", PKC 2005, LNCS 3386, DOI 10.1007/978-3-540-30580-4_6, 2005.
[AFP05]Abdalla，M.，Fouque，P.，和D.Pointcheval，“三方设置中基于密码的认证密钥交换”，PKC 2005，LNCS 3386，DOI 10.1007/978-3-540-30580-4_6，2005。
[BFK09] Bender, J., Fischlin, M., and D. Kuegler, "Security Analysis of the PACE Key-Agreement Protocol", ISC 2009, LNCS 5735, DOI 10.1007/978-3-642-04474-8_3, 2009.
[BFK09]Bender，J.，Fischlin，M.，和D.Kuegler，“PACE密钥协议的安全分析”，ISC 2009，LNCS 5735，DOI 10.1007/978-3-642-04474-8_3，2009年。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure against Dictionary Attacks", Proc. of the Symposium on Security and Privacy, Oakland, DOI 10.1109/RISP.1992.213269, 1992.
[BM92]Bellovin，S.和M.Merritt，“加密密钥交换：基于密码的协议防止字典攻击”，Proc。安全和隐私专题讨论会，奥克兰，内政部10.1109/RISP.1992.2132692992。
[DOT11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995.
[DOT11]IEEE，“IEEE信息技术标准——系统局域网和城域网之间的电信和信息交换——具体要求——第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”，IEEE 802.11，DOI 10.1109/IEEESTD.2016.7786995。
[HYCS15] Hao, F., Yi, X., Chen, L., and S. Shahandashti, "The Fairy-Ring Dance: Password Authenticated Key Exchange in a Group", IoTPTS 2015, DOI 10.1145/2732209.2732212, 2015.
[HYCS15]Hao，F.，Yi，X.，Chen，L.，和S.Shahandashti，“仙女戒指之舞：群中经密码验证的密钥交换”，IoTPTS 2015，DOI 10.1145/2732209.2732212，2015。
[JPAKE] Hao, F. and P. Ryan, "Password Authenticated Key Exchange by Juggling", SP 2008, LNCS 6615, DOI 10.1007/978-3-642-22137-8_23, 2008.
[JPAKE]Hao，F.和P.Ryan，“通过变戏法进行密码验证的密钥交换”，SP 2008，LNCS 6615，DOI 10.1007/978-3-642-22137-8_232008。
[P1363] IEEE Microprocessor Standards Committee, "Draft Standard Specifications for Password-Based Public Key Cryptographic Techniques", IEEE P1363.2, 2006.
[P1363]IEEE微处理器标准委员会，“基于密码的公钥密码技术的标准规范草案”，IEEE P1363.22006。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM SIGCOMM Computer Communications Review, Volume 26, Issue 5, DOI 10.1145/242896.242897, October 1996.
[SPEKE]Jablon，D.，“仅强密码认证密钥交换”，《ACM SIGCOMM计算机通信评论》，第26卷，第5期，DOI 10.1145/242896.242897，1996年10月。
Author's Address
作者地址
Joern-Marc Schmidt secunet Security Networks Mergenthaler Allee 77 65760 Eschborn Germany
Joern Marc Schmidt Secune安全网络合并泰勒阿莱77 65760埃斯伯恩德国
Email: joern-marc.schmidt@secunet.com
Email: joern-marc.schmidt@secunet.com