[要約] RFC 8125は、パスワード認証鍵合意（PAKE）スキームに関する要件を定義しています。この文書の目的は、安全な通信セッションを確立する際に、事前共有パスワードを使用して認証を行うための基準を提供することです。PAKEスキームは、オンラインアカウントへのログインやセキュアなメッセージングシステムなど、パスワードに基づく認証が必要な場面で利用されます。RFC 8125は、PAKEの実装と評価における安全性と互換性を確保するためのガイドラインを提供し、関連するRFCとしてはRFC 2945（SRPプロトコル）やRFC 6124（Dragonfly Key Exchange）などがあります。
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スキームについて説明します。さらに、要件を提示し、新しいスキームの設計者に推奨事項を提供します。これは、Crypto Forum Research Group（CFRG）の製品です。
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 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.
このドキュメントは、Internet Research Task Force（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.
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.
この文書は、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
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）は、安全なチャネルを介して送信されるパスワードまたはパスワード派生データをもたらさない暗号キー交換を構築することにより、この問題に対処しようとします。交換の2つの当事者は、共有パスワードを公開せずに所持していることを証明します。したがって、このような交換は、オフラインのブルートフォース辞書攻撃に対して耐性があります。このアイデアは当初、[BM92]のBellovinとMerrittによって記述され、それ以来、かなりの暗号化の注目を集めています。 PAKEは、公開鍵インフラストラクチャ（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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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).
大まかに言えば、さまざまなPAKEが多くの一般的な方法で目標を満たします。これにより、さまざまな設計上の選択につながります：公開鍵の送信方法（暗号化されているかどうか）、両方の当事者が同じパスワード表現を持っているかどうか（バランスと拡張）、および当事者の数（2当事者と複数当事者）。
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では、パスワードをランダムなソルトでハッシュするか、資格情報を有限フィールドの要素として表すことにより（たとえば、有限フィールドのジェネレータとパスワードを乗算することにより）、パスワードをソルト状態で直接保存できます。 「パスワード要素」を生成する数値として表されます）。このような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 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は「拡張」されていると言われます。通常、クライアントは未加工のパスワード（またはバランスのとれた場合のようにそれを表すもの）を保持し、サーバーは一方向関数で生成された変換済み要素を保持します。拡張PAKEの利点は、バランスの取れたPAKEでは不可能な方法でサーバーのパスワードをある程度保護することです。特に、サーバーのPAKE資格情報を正常に取得した攻撃者は、それらを直接使用してユーザーを他のサーバーに偽装することはできません。攻撃者は、たとえば（オフライン）辞書攻撃を実行するなどして、最初に個々のパスワードを知る必要があります。この種の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は公開鍵暗号化を使用します。 PAKEの基本的な違いは、公開鍵が交換でどのように伝達されるかです。
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].
PAKEの1つのクラスは、対称鍵暗号化とパスワードから派生した鍵を使用して、一時的な公開鍵を暗号化します。公開鍵の復号化に成功したことをピアが証明できることは、共有パスワードの知識を証明します。この交換の例には、[BM92]で導入された「暗号化鍵交換（EKE）」と呼ばれる最初のPAKEが含まれます。
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.
PAKEの別のクラスは、J-PAKE（ジャグリングによるパスワード認証鍵交換）プロトコル[JPAKE]のように、暗号化されていない公開鍵を送信します。鍵の合意時に、一時的な公開鍵と、共有パスワードを使用して導出された値が交換されます。パスワードが一致する場合、両者は、パスワード、公開鍵、および秘密鍵を組み合わせることにより、共通の秘密を計算できます。 SPEKE（Strong Password-Only Authenticated Key Exchange）[SPEKE]スキームは、公開キー、つまりDiffie-Hellman値も交換します。ここでは、公開鍵のジェネレーターは共有秘密から導出されます。その後、公開されているDiffie-Hellman値のみが交換されます。ジェネレータは秘密にされています。どちらの場合も、セキュリティで保護されていない媒体を介して送信される値は、ランダムなブロブではなく有限体の要素です。
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が暗号化されます。このノンスは、鍵合意の共通基盤を生成するために使用されます。パスワードを知らなければ、ナンスを決定することはできません。したがって、その後の鍵合意は失敗します。
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 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].
ほとんどのPAKEプロトコルでは、2つのパーティが共有パスワードに基づいて共有キーに同意することができます。それにもかかわらず、3つ以上の当事者の鍵となる合意を可能にする提案が存在します。これらのプロトコルは、パーティのグループのキー確立を可能にするため、「グループPAKE」または「GPAKE」と呼ばれます。このようなプロトコルの例は[ABCP06]にありますが、[ACGP11]と[HYCS15]は、任意の2パーティPAKEをGPAKEプロトコルに変換できるようにする一般的な構成を提案しています。マルチパーティPAKEプロトコルを定義するもう1つの可能性は、各パーティがパスワードを共有する信頼できるサーバーの存在を想定することです。このサーバーを使用すると、さまざまな関係者がパスワードを共有することなく、共通の秘密鍵について合意できます。各パーティには、信頼されたサーバーとの共有シークレットしかありません。たとえば、Abdalla et al。 [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スキームは、パスワードを共有する（またはおそらくボブがパスワードの機能を共有する）2人の当事者（通常はアリスとボブ）のシナリオに基づいてモデル化され、信頼できないリンク上で安全なセッションキーを確立するために使用します。交換を妨害したい強力な敵、通常はイブがいます。イブは、アリスとボブのパスワードが含まれている可能性が高い辞書にアクセスできます。イブは、力ずくで辞書を列挙して、アリスとボブのパスワードを見つけ出そうとします。
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.
すべてのPAKEには制限があります。イブがパスワードを推測した場合、彼女は交換を覆すことができます。したがって、イブがPAKEのセキュリティにアクセスするためのパスワードを推測する可能性をモデル化する必要があります。彼女がパスワードを発見する確率がプロトコルの参加者との相互作用の関数であり、計算の関数ではない場合、PAKEは安全です（つまり、Eveはパッシブ攻撃または単一のアクティブ攻撃から情報を取得できません） 。したがって、彼女は、パスワードの推測ごとにアリスまたはボブと対話せずに辞書を列挙することはできません。つまり、残っている唯一の攻撃は推測の繰り返しです。 Eveは1つのアクティブな攻撃から1つのことを学びます。彼女の1つの推測が正しいかどうかです。
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スキームのセキュリティは、アリスになりすまそうとしているイブは、ボブ（またはアリス）と対話せずにパスワードの推測を効率的に検証できないという考えに基づいています。もし彼女がどちらかと相互作用したとしたら、それによって彼女は検出されるでしょう。したがって、許可される認証の試行回数の制限と、サービス拒否の脆弱性の可能性とのバランスをとることが重要です。 PAKEスキームのセキュリティを判断および比較するために、一般に受け入れられているモデルのセキュリティ証明を使用する必要があります（SHOULD）。ただし、各証明とモデルは仮定に基づいています。多くの場合、セキュリティの証明は、攻撃者がスキームを破ることができる場合、離散対数の計算など、困難であると想定される問題を解決することもできることを示しています。変換によって、スキームを破ることも同様に難しい問題であると考えられます。
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 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.
PAKEスキームは、使用されるモデルと仮定が明確に記述されたセキュリティ証明を伴う必要があります。特に、アクティブな攻撃者が認証に合格したり、パスワードに関する追加情報を取得したり、確立されたキーについて何かを学習したりする可能性がごくわずかであることを証明は証明する必要があります。さらに、作者は、スキームで使用される基本となるプリミティブを指定してもよいし、特定のユースケースや量子コンピューターへの耐性のような仮定を考慮してもよい（MAY）。明確で包括的な証明は、ユーザーがスキームのセキュリティを信頼するための基盤です。
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.
スキームの開発者は、実装の側面を念頭に置き、プロトコルを一定の時間で実装する方法を示す必要があります（SHOULD）。さらに、潜在的な敵対的な環境でのスキームの実装を保護する方法についての議論を追加することが推奨されます。
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.
Elliptic Curve Cryptography（ECC）では、同様のセキュリティレベルで有限体の離散対数問題に基づく従来の方式と比較して、鍵の長さを短くできるため、PAKE方式にECCを使用することも重要です。有限体要素を直接使用できるスキームとは対照的に、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で使用することを意図している場合、著者は、マッピング機能が必要かどうかを示し、必要な場合はその要件について説明する必要があります。あるいは、作者はスキームで使用されるマッピングを定義してもよい（MAY）。
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を使用して公開キーを交換する2つのパーティのバリアントもあります。このバリアントでは、公開鍵はパスワードを使用して暗号化できます。暗号化されていない公開鍵に関連付けられている秘密鍵を両側が知っているため、またピアの公開鍵を復号化できるため、認証鍵の配布を実行できます。この手法を使用すると、短い1回限りのコードを長期的な公開鍵に変換できます。
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, 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.
接続を確立するために、PAKEプロトコルの各当事者は、通信パートナーのIDを知って、契約に適切なパスワードを識別する必要があります。ユーザーがサーバーとのセキュリティで保護されたチャネルを確立したい場合、ユーザーはまず、ある種の識別子をサーバーに送信して、使用するパスワードをサーバーに通知する必要があります。この識別子が保護されていない場合、接続を盗聴できるすべてのユーザーがユーザーを識別できます。これを防ぎ、ユーザーのプライバシーを保護するために、このスキームはユーザーのIDの送信を保護する方法を提供する場合があります。サーバーと通信するユーザーのプライバシーを保護する簡単な方法は、サーバーが提供する公開キーを使用してユーザーのIDを暗号化することです。
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.
REQ1：PAKEスキームは、バランス/拡張バージョンに関する機能を明確に記述する必要があります。
REQ2: A PAKE scheme SHOULD come with a security proof and clearly state its assumptions and models.
REQ2：PAKEスキームには、セキュリティの証明が必要であり、その前提とモデルを明示する必要があります（SHOULD）。
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スキームの実装を保護する方法、特にタイミング攻撃を防ぐために一定の時間にスキームを実装する方法を示す必要があります（SHOULD）。
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.
REQ4：PAKEスキームをECCで使用することを意図している場合、著者は、潜在的なマッピングの要件を検討するか、スキームで使用するマッピングを定義する必要があります。
REQ5: The authors of a PAKE scheme MAY discuss its design choice with regard to performance, i.e., its optimization goals.
REQ5：PAKEスキームの作成者は、パフォーマンス、つまり最適化の目標に関する設計の選択について議論してもよい（MAY）。
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.
REQ6：スキームの作成者は、特別なアプリケーションシナリオでの使用を可能にするスキームのバリエーションについて議論してもよい（MAY）。特に、長期的な（公開）鍵合意を促進する手法が推奨されます。
REQ7: Authors of a scheme MAY discuss special ideas and solutions on privacy protection of its users.
REQ7：スキームの作成者は、ユーザーのプライバシー保護に関する特別なアイデアと解決策について議論してもよい（MAY）。
REQ8: The authors MUST follow the IRTF IPR policy <https://irtf.org/ipr>.
REQ8：著者はIRTF IPRポリシー<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_11、2011。
[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、「3者設定でのパスワードベースの認証済み鍵交換」、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 Key-Agreement Protocolのセキュリティ分析」、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。セキュリティとプライバシーに関するシンポジウム、オークランド、DOI 10.1109 / RISP.1992.213269、1992。
[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 Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network--Specific requirements-Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、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、「The Fairy-Ring Dance：Password Authenticated Key Exchange in a Group」、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_23、2008。
[P1363] IEEE Microprocessor Standards Committee, "Draft Standard Specifications for Password-Based Public Key Cryptographic Techniques", IEEE P1363.2, 2006.
[P1363] IEEEマイクロプロセッサ標準委員会、「パスワードベースの公開キー暗号化技術の標準仕様案」、IEEE P1363.2、2006年。
[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、「The Transport Layer Security（TLS）Protocol Version 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。、「Strong Password-Only Authenticated Key Exchange」、ACM SIGCOMM Computer Communications Review、Volume 26、Issue 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 secunet Security Networks Mergenthaler Allee 77 65760エシュボルンドイツ
Email: joern-marc.schmidt@secunet.com