[要約] RFC 8492は、TLSのための安全なパスワード暗号スイートに関する規格です。その目的は、強力なパスワードベースの認証を提供し、TLSセッションのセキュリティを向上させることです。
Independent Submission D. Harkins, Ed.
Request for Comments: 8492 HP Enterprise
Category: Informational February 2019
ISSN: 2070-1721
Secure Password Ciphersuites for Transport Layer Security (TLS)
トランスポート層セキュリティ（TLS）の安全なパスワード暗号スイート
Abstract
概要
This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.
このメモは、トランスポート層セキュリティ（TLS）プロトコルのいくつかの新しい暗号スイートを定義して、シンプルで低エントロピーのパスワードのみを使用して証明書なしの安全な認証をサポートします。この交換は「TLS-PWD」と呼ばれます。暗号スイートはすべて、オフライン辞書攻撃に耐性のある「dragonfly」という名前の認証および鍵交換プロトコルに基づいています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8492.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8492で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction and Motivation .....................................3
1.1. The Case for Certificateless Authentication ................3
1.2. Resistance to Dictionary Attacks ...........................3
2. Key Words .......................................................4
3. Notation and Background .........................................4
3.1. Notation ...................................................4
3.2. Discrete Logarithm Cryptography ............................5
3.2.1. Elliptic Curve Cryptography .........................5
3.2.2. Finite Field Cryptography ...........................7
3.3. Instantiating the Random Function ..........................8
3.4. Passwords ..................................................8
3.5. Assumptions ................................................9
4. Specification of the TLS-PWD Handshake .........................10
4.1. TLS-PWD Pre-TLS 1.3 .......................................10
4.2. TLS-PWD in TLS 1.3 ........................................11
4.3. Protecting the Username ...................................11
4.3.1. Construction of a Protected Username ...............12
4.3.2. Recovery of a Protected Username ...................13
4.4. Fixing the Password Element ...............................14
4.4.1. Computing an ECC Password Element ..................16
4.4.2. Computing an FFC Password Element ..................18
4.4.3. Password Naming ....................................19
4.4.4. Generating TLS-PWD Commit ..........................20
4.5. Changes to Handshake Message Contents .....................20
4.5.1. Pre-1.3 TLS ........................................20
4.5.1.1. ClientHello Changes .......................20
4.5.1.2. ServerKeyExchange Changes .................21
4.5.1.3. ClientKeyExchange Changes .................23
4.5.2. TLS 1.3 ............................................24
4.5.2.1. TLS 1.3 KeyShare ..........................24
4.5.2.2. ClientHello Changes .......................24
4.5.2.3. ServerHello Changes .......................25
4.5.2.4. HelloRetryRequest Changes .................25
4.6. Computing the Shared Secret ...............................26
5. Ciphersuite Definition .........................................26
6. IANA Considerations ............................................27
7. Security Considerations ........................................27
8. Human Rights Considerations ....................................30
9. Implementation Considerations ..................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................33
Appendix A. Example Exchange ......................................35
Acknowledgements ..................................................40
Author's Address ..................................................40
Transport Layer Security (TLS) usually uses public key certificates for authentication [RFC5246] [RFC8446]. This is problematic in some cases:
トランスポート層セキュリティ（TLS）は通常、認証に公開鍵証明書を使用します[RFC5246] [RFC8446]。これはいくつかのケースで問題があります：
o Frequently, TLS [RFC5246] is used in devices owned, operated, and provisioned by people who lack competency to properly use certificates and merely want to establish a secure connection using a more natural credential like a simple password. The proliferation of deployments that use a self-signed server certificate in TLS [RFC5246] followed by a basic password exchange over the unauthenticated channel underscores this case.
o 多くの場合、TLS [RFC5246]は、証明書を適切に使用する能力がなく、単純なパスワードなどのより自然な資格情報を使用して安全な接続を確立したい人々によって所有、操作、プロビジョニングされるデバイスで使用されます。 TLS [RFC5246]で自己署名されたサーバー証明書を使用する展開の急増に続いて、認証されていないチャネルを介した基本的なパスワード交換がこのケースを強調しています。
o The alternatives to TLS-PWD for employing certificateless TLS authentication -- using pre-shared keys in an exchange that is susceptible to dictionary attacks or using a Secure Remote Password (SRP) exchange that requires users to, a priori, be fixed to a specific Finite Field Cryptography (FFC) group for all subsequent connections -- are not acceptable for modern applications that require both security and cryptographic agility.
o 証明書なしのTLS認証を採用するためのTLS-PWDの代替案-辞書攻撃の影響を受けやすい交換で事前共有キーを使用するか、ユーザーがアプリオリに特定の値に固定する必要があるSecure Remote Password（SRP）交換を使用する後続のすべての接続の有限フィールド暗号化（FFC）グループは、セキュリティと暗号化の俊敏性の両方を必要とする最新のアプリケーションでは受け入れられません。
o A password is a more natural credential than a certificate (from early childhood, people learn the semantics of a shared secret), so a password-based TLS ciphersuite can be used to protect an HTTP-based certificate enrollment scheme like Enrollment over Secure Transport (EST) [RFC7030] to parlay a simple password into a certificate for subsequent use with any certificate-based authentication protocol. This addresses a significant "chicken-and-egg" dilemma found with certificate-only use of [RFC5246].
o パスワードは証明書よりも自然な資格情報です（幼少期から、人々は共有秘密の意味論を学びます）。したがって、パスワードベースのTLS暗号スイートを使用して、Enrollment over Secure Transport（ EST）[RFC7030]証明書ベースの認証プロトコルで後で使用するために、単純なパスワードを証明書に配置します。これは、[RFC5246]の証明書のみの使用で見られる重大な「鶏と卵」のジレンマに対処します。
o Some PIN-code readers will transfer the entered PIN to a smart card in cleartext. Assuming a hostile environment, this is a bad practice. A password-based TLS ciphersuite can enable the establishment of an authenticated connection between reader and card based on the PIN.
o 一部のPINコードリーダーは、入力したPINをクリアテキストでスマートカードに転送します。敵対的な環境を想定すると、これは悪い習慣です。パスワードベースのTLS暗号スイートにより、PINに基づいてリーダーとカード間の認証された接続を確立できます。
It is a common misconception that a protocol that authenticates with a shared and secret credential is resistant to dictionary attacks if the credential is assumed to be an N-bit uniformly random secret, where N is sufficiently large. The concept of resistance to dictionary attacks really has nothing to do with whether that secret can be found in a standard collection of a language's defined words (i.e., a dictionary). It has to do with how an adversary gains an advantage in attacking the protocol.
クレデンシャルがNビットの一様にランダムなシークレットであると想定されている場合、共有された秘密のクレデンシャルで認証するプロトコルは、Nビットが一様にランダムなシークレットであると想定される場合、プロトコルは辞書攻撃に耐性があるというのはよくある誤解です。辞書攻撃への耐性の概念は、その秘密が言語の定義された単語の標準的なコレクション（つまり、辞書）で見つかるかどうかとはまったく関係ありません。それは、攻撃者がプロトコルを攻撃する際にどのように有利になるかと関係があります。
For a protocol to be resistant to dictionary attacks, any advantage an adversary can gain must be a function of the amount of interactions she makes with an honest protocol participant and not a function of the amount of computation she uses. This means that the adversary will not be able to obtain any information about the password except whether a single guess from a single protocol run that she took part in is correct or incorrect.
プロトコルがディクショナリ攻撃に耐性を持つためには、攻撃者が得ることができる利点は、彼女が使用する計算量の関数ではなく、正直なプロトコル参加者とのやり取りの量の関数でなければなりません。これは、攻撃者が参加した1回のプロトコル実行からの1回の推測が正しいか正しくないかを除き、パスワードに関する情報を取得できないことを意味します。
It is assumed that the attacker has access to a pool of data from which the secret was drawn -- it could be all numbers between 1 and 2^N; it could be all defined words in a dictionary. The key is that the attacker cannot do an attack and then go offline and enumerate through the pool trying potential secrets (computation) to see if one is correct. She must do an active attack for each secret she wishes to try (interaction), and the only information she can glean from that attack is whether the secret used with that particular attack is correct or not.
攻撃者がシークレットの元となったデータのプールにアクセスできると想定されています。これは、1から2 ^ Nまでのすべての数値である可能性があります。辞書で定義されたすべての単語である可能性があります。重要なのは、攻撃者が攻撃を行ってからオフラインになり、潜在的な秘密（計算）を試みてプールを列挙し、正しいかどうかを確認することです。彼女は、試みたい各シークレット（相互作用）に対してアクティブな攻撃を行う必要があり、その攻撃から収集できる唯一の情報は、その特定の攻撃で使用されたシークレットが正しいかどうかです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following notation is used in this memo:
このメモでは、次の表記が使用されています。
password a secret -- and potentially low-entropy -- word, phrase, code, or key used as a credential for authentication. The password is shared between the TLS client and TLS server.
認証のための信任状として使用される秘密、そして場合によっては低エントロピーのワード、フレーズ、コード、またはキーのパスワードを入力します。パスワードは、TLSクライアントとTLSサーバーの間で共有されます。
y = H(x) a binary string of arbitrary length, x, is given to a function H, which produces a fixed-length output, y.
y = H（x）任意の長さxのバイナリ文字列が関数Hに与えられ、固定長出力yを生成します。
a | b denotes concatenation of string "a" with string "b".
a | bは、文字列 "a"と文字列 "b"の連結を示します。
[a]b indicates a string consisting of the single bit "a" repeated "b" times.
[a] bは、単一ビット「a」が「b」回繰り返された文字列を示します。
x mod y indicates the remainder of division of x by y. The result will be between 0 and y.
x mod yは、xのyによる除算の剰余を示します。結果は0とyの間になります。
len(x) indicates the length in bits of the string "x".
len（x）は、文字列 "x"のビット単位の長さを示します。
lgr(a, b) takes "a" and a prime, b, and returns the Legendre symbol (a/b).
lgr（a、b）は "a"と素数bを取り、ルジャンドル記号（a / b）を返します。
LSB(x) returns the least-significant bit of the bitstring "x".
LSB（x）は、ビット文字列 "x"の最下位ビットを返します。
G.x indicates the x-coordinate of a point, G, on an elliptic curve.
G.xは、楕円曲線上の点Gのx座標を示します。
The ciphersuites defined in this memo use discrete logarithm cryptography (see [SP800-56A]) to produce an authenticated and shared secret value that is an Element in a group defined by a set of domain parameters. The domain parameters can be based on either FFC or Elliptic Curve Cryptography (ECC).
このメモで定義された暗号スイートは、離散対数暗号化（[SP800-56A]を参照）を使用して、一連のドメインパラメータで定義されたグループの要素である認証および共有秘密値を生成します。ドメインパラメーターは、FFCまたは楕円曲線暗号（ECC）のいずれかに基づくことができます。
Elements in a group -- either an FFC or ECC group -- are indicated using uppercase, while scalar values are indicated using lowercase.
グループ内の要素（FFCまたはECCグループ）は大文字で示され、スカラー値は小文字で示されます。
The authenticated key exchange defined in this memo uses fundamental algorithms of elliptic curves defined over GF(p) as described in [RFC6090]. Ciphersuites defined in this memo SHALL only use ECC curves based on the Weierstrass equation y^2 = x^3 + a*x + b.
このメモで定義された認証済みの鍵交換は、[RFC6090]で説明されているように、GF（p）で定義された楕円曲線の基本アルゴリズムを使用します。このメモで定義された暗号スイートは、ワイエルシュトラス方程式y ^ 2 = x ^ 3 + a * x + bに基づくECC曲線のみを使用するものとします（SHALL）。
Domain parameters for the ECC groups used by this memo are:
このメモで使用されるECCグループのドメインパラメータは次のとおりです。
o A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group, which consists of points on an elliptic curve -- Elements from GF(p) that satisfy the curve's equation -- together with the "point at infinity" that serves as the identity Element.
o 素数pは、素体GF（p）を決定します。暗号化グループは、楕円曲線上の点（曲線の方程式を満たすGF（p）の要素）と、同一性として機能する「無限遠の点」で構成される完全な楕円曲線グループのサブグループになります。素子。
o Elements a and b from GF(p) that define the curve's equation. The point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only if (y^2 - x^3 - a*x - b) mod p equals zero (0).
o 曲線の方程式を定義するGF（p）の要素aおよびb。 （y ^ 2-x ^ 3-a * x-b）mod pがゼロ（0）に等しい場合に限り、GF（p）x GF（p）の点（x、y）は楕円曲線上にあります。
o A point, G, on the elliptic curve, which serves as a generator for the ECC group. G is chosen such that its order, with respect to elliptic curve addition, is a sufficiently large prime.
o ECCグループのジェネレーターとして機能する楕円曲線上の点G。 Gは、楕円曲線の追加に関して、その次数が十分に大きな素数になるように選択されます。
o A prime, q, which is the order of G and thus is also the size of the cryptographic subgroup that is generated by G.
o Gの次数であり、Gによって生成される暗号サブグループのサイズでもある素数q
o A co-factor, f, defined by the requirement that the size of the full elliptic curve group (including the "point at infinity") be the product of f and q.
o 完全な楕円曲線グループ（「無限遠点」を含む）のサイズがfとqの積であるという要件によって定義される補因子f。
This memo uses the following ECC functions:
このメモは、次のECC機能を使用します。
o Z = elem-op(X, Y) = X + Y: two points on the curve, X and Y, are summed to produce another point on the curve, Z. This is the group operation for ECC groups.
o Z = elem-op（X、Y）= X + Y：曲線上の2つのポイントXとYを合計して、曲線上の別のポイントZを生成します。これは、ECCグループのグループ操作です。
o Z = scalar-op(x, Y) = x * Y: an integer scalar, x, acts on a point on the curve, Y, via repetitive addition (Y is added to itself x times), to produce another ECC Element, Z.
o Z = scalar-op（x、Y）= x * Y：整数スカラーxは、反復加算（Yはx自体に追加される）によって曲線上の点Yに作用し、別のECCエレメントを生成します。 Z
o Y = inverse(X): a point on the curve, X, has an inverse, Y, which is also a point on the curve, when their sum is the "point at infinity" (the identity for elliptic curve addition). In other words, R + inverse(R) = "0".
o Y =逆（X）：曲線上の点Xは、その合計が「無限遠点」（楕円曲線加算の同一性）である場合、曲線上の点でもある逆Yを持ちます。言い換えれば、R +逆（R）= "0"。
o z = F(X): the x-coordinate of a point (x, y) on the curve is returned. This is a mapping function to convert a group Element into an integer.
o z = F（X）：曲線上の点（x、y）のx座標が返されます。これは、グループElementを整数に変換するマッピング関数です。
Only ECC groups over GF(p) can be used with TLS-PWD. Characteristic-2 curves SHALL NOT be used by TLS-PWD. ECC groups over GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a co-factor greater than one (1) SHALL NOT be used by TLS-PWD.
GF（p）上のECCグループのみがTLS-PWDで使用できます。特性2の曲線はTLS-PWDで使用してはならない（SHALL NOT）。 GF（2 ^ m）上のECCグループは、TLS-PWDによって使用されるべきではありません。さらに、1より大きい補因子を持つECCグループは、TLS-PWDによって使用されるべきではない（SHALL NOT）。
A composite (x, y) pair can be validated as a point on the elliptic curve by checking that 1) both coordinates x and y are greater than zero (0) and less than the prime defining the underlying field, 2) coordinates x and y satisfy the equation of the curve, and 3) they do not represent the "point at infinity". If any of those conditions are not true, the (x, y) pair is not a valid point on the curve.
複合（x、y）のペアは、1）座標xとyの両方がゼロ（0）より大きく、基礎となるフィールドを定義する素数よりも小さいこと、2）座標xとyは曲線の方程式を満たし、3）「無限遠点」を表さない。これらの条件のいずれかが真でない場合、（x、y）のペアは曲線上の有効なポイントではありません。
A compliant implementation of TLS-PWD SHALL support group twenty-three (23) and SHOULD support group twenty-four (24) from the "TLS Supported Groups" registry; see [TLS_REG].
TLS-PWD SHALLの準拠実装は、グループ23（23）をサポートし、SHOULDは、「TLSサポートグループ」レジストリからグループ24をサポートする必要があります。 [TLS_REG]を参照してください。
Domain parameters for the FFC groups used by this memo are:
このメモで使用されるFFCグループのドメインパラメータは次のとおりです。
o A prime, p, determining a prime field GF(p) (i.e., the integers modulo p). The FFC group will be a subgroup of GF(p)* (i.e., the multiplicative group of non-zero Elements in GF(p)).
o 素数pは、素体GF（p）（すなわち、pを法とする整数）を決定します。 FFCグループは、GF（p）*のサブグループになります（つまり、GF（p）の非ゼロ要素の乗法グループ）。
o An Element, G, in GF(p)*, which serves as a generator for the FFC group. G is chosen such that its multiplicative order is a sufficiently large prime divisor of ((p - 1)/2).
o FGFグループのジェネレーターとして機能するGF（p）*の要素G。 Gは、その乗算次数が（（p-1）/ 2）の十分に大きな素数になるように選択されます。
o A prime, q, which is the multiplicative order of G and thus is also the size of the cryptographic subgroup of GF(p)* that is generated by G.
o Gの乗算次数であり、Gによって生成されるGF（p）*の暗号サブグループのサイズでもある素数q
This memo uses the following FFC functions:
このメモは以下のFFC関数を使用します：
o Z = elem-op(X, Y) = (X * Y) mod p: two FFC Elements, X and Y, are multiplied modulo the prime, p, to produce another FFC Element, Z. This is the group operation for FFC groups.
o Z = elem-op（X、Y）=（X * Y）mod p：2つのFFC要素XおよびYは、素数pを法として乗算され、別のFFC要素Zを生成します。これは、FFCのグループ演算ですグループ。
o Z = scalar-op(x, Y) = Y^x mod p: an integer scalar, x, acts on an FFC group Element, Y, via exponentiation modulo the prime, p, to produce another FFC Element, Z.
o Z = scalar-op（x、Y）= Y ^ x mod p：整数スカラーxは、素数pを法とする累乗を介してFFCグループElement Yに作用し、別のFFC Element Zを生成します。
o Y = inverse(X): a group Element, X, has an inverse, Y, when the product of the Element and its inverse modulo the prime equals one (1). In other words, (X * inverse(X)) mod p = 1.
o Y =逆数（X）：素数と要素の逆数の素数の積が1に等しい場合、グループ要素Xは逆数Yを持ちます。つまり、（X *逆（X））mod p = 1です。
o z = F(X): is the identity function, since an Element in an FFC group is already an integer. It is included here for consistency in the specification.
o z = F（X）：FFCグループの要素はすでに整数であるため、単位関数です。これは、仕様の一貫性のためにここに含まれています。
Many FFC groups used in IETF protocols are based on safe primes and do not define an order (q). For these groups, the order (q) used in this memo shall be the prime of the group minus one divided by two -- (p - 1)/2.
IETFプロトコルで使用される多くのFFCグループは安全な素数に基づいており、順序（q）を定義していません。これらのグループの場合、このメモで使用される次数（q）は、グループの素数から1を2で割ったもの-（p-1）/ 2です。
An integer can be validated as being an Element in an FFC group by checking that 1) it is between one (1) and the prime, p, exclusive and 2) modular exponentiation of the integer by the group order, q, equals one (1). If either of these conditions is not true, the integer is not an Element in the group.
整数は、1）1と素数、p、排他的である、2）グループの順序による整数の剰余、q、1と等しいことを確認することで、FFCグループの要素として検証できます。 1）。これらの条件のいずれかが真でない場合、整数はグループ内の要素ではありません。
A compliant implementation of TLS-PWD SHOULD support group two hundred fifty-six (256) and group two hundred fifty-eight (258) from the "TLS Supported Groups" registry on [TLS_REG].
TLS-PWDの準拠した実装は、[TLS_REG]の「TLSサポートグループ」レジストリからグループ256（256）とグループ256（258）をサポートする必要があります（SHOULD）。
The protocol described in this memo uses a random function, H, which is modeled as a "random oracle". At first glance, one may view this as a hash function. As noted in [RANDOR], though, hash functions are too structured to be used directly as a random oracle. But they can be used to instantiate the random oracle.
このメモで説明されているプロトコルは、「ランダムオラクル」としてモデル化されたランダム関数Hを使用します。一見すると、これをハッシュ関数と見なすことができます。ただし、[RANDOR]で述べたように、ハッシュ関数は構造化されているため、ランダムなオラクルとして直接使用することはできません。しかし、それらはランダムなオラクルをインスタンス化するために使用できます。
The random function, H, in this memo is instantiated by using the hash algorithm defined by the particular TLS-PWD ciphersuite in Hashed Message Authentication Code (HMAC) mode with a key whose length is equal to the block size of the hash algorithm and whose value is zero. For example, if the ciphersuite is TLS_ECCPWD_WITH_AES_128_GCM_SHA256, then H will be instantiated with SHA256 as:
このメモのランダム関数Hは、ハッシュメッセージ認証コード（HMAC）モードで特定のTLS-PWD暗号スイートによって定義されたハッシュアルゴリズムを使用してインスタンス化され、その長さはハッシュアルゴリズムのブロックサイズに等しく、値はゼロです。たとえば、暗号スイートがTLS_ECCPWD_WITH_AES_128_GCM_SHA256の場合、Hは次のようにSHA256でインスタンス化されます。
H(x) = HMAC-SHA256([0]32, x)
The authenticated key exchange used in TLS-PWD requires each side to have a common view of a shared credential. To protect the server's database of stored passwords, a password MAY be salted. When [RFC5246] or earlier is used, the password SHALL be salted. When [RFC8446] is used, a password MAY be stored with a salt or without. The password, username, and, optionally, the salt can create an irreversible digest called the "base", which is used in the authenticated key exchange.
TLS-PWDで使用される認証済みの鍵交換では、共有された資格情報の共通のビューを両サイドが持っている必要があります。格納されたパスワードのサーバーのデータベースを保護するために、パスワードはソルトされる場合があります。 [RFC5246]以前を使用する場合は、パスワードをソルトする必要があります。 [RFC8446]を使用する場合、パスワードはソルトの有無にかかわらず保存できます。パスワード、ユーザー名、およびオプションでソルトは、「ベース」と呼ばれる不可逆的なダイジェストを作成できます。これは、認証された鍵交換で使用されます。
The salting function is defined as:
ソルティング関数は次のように定義されます。
base = HMAC-SHA256(salt, username | password)
ベース= HMAC-SHA256（塩、ユーザー名|パスワード）
The unsalted function is defined as:
無塩機能は次のように定義されます。
base = SHA256(username | password)
base = SHA256（ユーザー名|パスワード）
The password used for generation of the base SHALL be represented as a UTF-8 encoded character string processed according to the rules of the OpaqueString profile of [RFC8265], and the salt SHALL be a 32-octet random number. The server SHALL store a tuple of the form:
ベースの生成に使用されるパスワードは、[RFC8265]のOpaqueStringプロファイルのルールに従って処理されたUTF-8エンコードされた文字列として表され、ソルトは32オクテットの乱数でなければなりません。サーバーは次の形式のタプルを格納する必要があります。
{ username, base, salt }
{ユーザー名、ベース、ソルト}
if the password is salted and:
パスワードがソルトされており、かつ：
{ username, base }
{ユーザー名、ベース}
if it is not. When password salting is being used, the client generates the base upon receiving the salt from the server; otherwise, it may store the base at the time the username and password are provisioned.
そうでない場合。パスワードソルティングが使用されている場合、クライアントはサーバーからソルトを受信するとベースを生成します。それ以外の場合は、ユーザー名とパスワードがプロビジョニングされたときにベースが保存されることがあります。
The security properties of the authenticated key exchange defined in this memo are based on a number of assumptions:
このメモで定義されている認証済みの鍵交換のセキュリティプロパティは、いくつかの仮定に基づいています。
1. The random function, H, is a "random oracle" as defined in [RANDOR].
1. ランダム関数Hは、[RANDOR]で定義されている「ランダムオラクル」です。
2. The discrete logarithm problem for the chosen group is hard. That is, given g, p, and y = g^x mod p, it is computationally infeasible to determine x. Similarly, for an ECC group given the curve definition, a generator G, and Y = x * G, it is computationally infeasible to determine x.
2. 選択したグループの離散対数問題は困難です。つまり、g、p、およびy = g ^ x mod pの場合、xを決定することは計算上不可能です。同様に、曲線の定義が与えられたECCグループ、ジェネレーターG、およびY = x * Gの場合、xを決定することは計算上実行不可能です。
3. Quality random numbers with sufficient entropy can be created. This may entail the use of specialized hardware. If such hardware is unavailable, a cryptographic mixing function (like a strong hash function) to distill entropy from multiple, uncorrelated sources of information and events may be needed. A very good discussion of this can be found in [RFC4086].
3. 十分なエントロピーを持つ高品質の乱数を作成できます。これには、専用ハードウェアの使用が必要になる場合があります。このようなハードウェアが利用できない場合は、相関のない複数の情報およびイベントのソースからエントロピーを抽出するための暗号化混合関数（強力なハッシュ関数など）が必要になる場合があります。これに関する非常に良い議論は[RFC4086]で見つけることができます。
If the server supports username protection (see Section 4.3), it is assumed that the server has chosen a domain parameter set and generated a username-protection keypair. The chosen domain parameter set and public key are assumed to be conveyed to the client at the time the client's username and password were provisioned.
サーバーがユーザー名保護をサポートしている場合（セクション4.3を参照）、サーバーがドメインパラメータセットを選択し、ユーザー名保護キーペアを生成したと見なされます。選択したドメインパラメータセットと公開キーは、クライアントのユーザー名とパスワードがプロビジョニングされたときにクライアントに伝達されると想定されています。
The key exchange underlying TLS-PWD is the "dragonfly" password-authenticated key exchange (PAKE) as defined in [RFC7664].
TLS-PWDの基礎となる鍵交換は、[RFC7664]で定義されている「トンボ」パスワード認証鍵交換（PAKE）です。
The authenticated key exchange is accomplished by each side deriving a Password Element (PE) [RFC7664] in the chosen group, making a "commitment" to a single guess of the password using the PE, and generating a shared secret. The ability of each side to produce a valid finished message using a key derived from the shared secret allows each side to authenticates itself to the other side.
認証された鍵の交換は、選択したグループのパスワード要素（PE）[RFC7664]を導出し、PEを使用してパスワードの単一の推測に「コミットメント」を行い、共有秘密を生成することによって行われます。共有シークレットから導出されたキーを使用して有効な終了メッセージを生成する各サイドの機能により、各サイドが他のサイドに対して自身を認証できます。
The authenticated key exchange is dropped into the standard TLS message handshake by defining extensions to some of the messages.
認証された鍵交換は、一部のメッセージに対する拡張を定義することにより、標準のTLSメッセージハンドシェイクにドロップされます。
Client Server
-------- --------
ClientHello (name) -------->
ServerHello
ServerKeyExchange (commit)
<-------- ServerHello Done
ClientKeyExchange (commit)
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
Application Data <-------> Application Data
Figure 1: Pre-TLS 1.3 TLS-PWD Handshake
図1：TLS 1.3より前のTLS-PWDハンドシェイク
Client Server
-------- --------
ClientHello (name)
+ key_share (commit) -------->
ServerHello
+ key_share (commit)
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: TLS 1.3 TLS-PWD Handshake
図2：TLS 1.3 TLS-PWDハンドシェイク
The client is required to identify herself to the server before the server can look up the appropriate client credential with which to perform the authenticated key exchange. This has negative privacy implications and opens up the client to tracking and increased monitoring. It is therefore useful for the client to be able to protect her username from passive monitors of the exchange and against active attack by a malicious server. TLS-PWD provides such a mechanism. Support for protected usernames is RECOMMENDED.
サーバーが認証済みの鍵交換を実行するための適切なクライアント資格情報を検索する前に、クライアントはサーバーに対して自分自身を識別する必要があります。これはプライバシーに悪影響を及ぼし、クライアントを追跡し、監視を強化します。したがって、クライアントがユーザー名を交換のパッシブモニターから保護し、悪意のあるサーバーによるアクティブな攻撃から保護できると便利です。 TLS-PWDはそのようなメカニズムを提供します。保護されたユーザー名のサポートをお勧めします。
To enable username protection, a server chooses a domain parameter set and generates an ephemeral public/private keypair. This keypair SHALL only be used for username protection. For efficiency, the domain parameter set used for username protection MUST be based on ECC. Any ECC group that is appropriate for TLS-PWD (see Section 3.2.1) is suitable for this purpose, but for interoperability, prime256v1 (aka NIST's p256 curve) MUST be supported. The domain parameter set chosen for username protection is independent of the domain parameter set chosen for the underlying key exchange -- i.e., they need not be the same.
ユーザー名保護を有効にするために、サーバーはドメインパラメータセットを選択し、一時的な公開/秘密鍵ペアを生成します。この鍵ペアは、ユーザー名の保護にのみ使用してください。効率を上げるために、ユーザー名保護に使用されるドメインパラメータセットは、ECCに基づいている必要があります。 TLS-PWD（セクション3.2.1を参照）に適したすべてのECCグループがこの目的に適していますが、相互運用性のために、prime256v1（別名NISTのp256曲線）をサポートする必要があります。ユーザー名保護用に選択されたドメインパラメータセットは、基になる鍵交換用に選択されたドメインパラメータセットとは無関係です。つまり、同じである必要はありません。
When the client's username and password are provisioned on the server, the chosen group and its public key are provisioned on the client. This is stored on the client along with the server-specific state (e.g., the hostname) it uses to initiate a TLS-PWD exchange. The server uses the same group and public key with all clients.
クライアントのユーザー名とパスワードがサーバーにプロビジョニングされると、選択されたグループとその公開鍵がクライアントにプロビジョニングされます。これは、TLS-PWD交換を開始するために使用するサーバー固有の状態（ホスト名など）とともにクライアントに保存されます。サーバーは、すべてのクライアントで同じグループと公開鍵を使用します。
To protect a username, the client and server perform a static-ephemeral Diffie-Hellman exchange. Since the y-coordinate is not necessary and eliminating it will reduce message size, compact representation (and therefore compact output; see [RFC6090]) is used in the static-ephemeral Diffie-Hellman exchange. The result of the Diffie-Hellman exchange is passed to the HMAC-based Key Derivation Function (HKDF) [RFC5869] to create a key-encrypting key suitable for AES-SIV [RFC5297] (where "AES" stands for "Advanced Encryption Standard" and "SIV" stands for "Synthetic Initialization Vector") in its deterministic authenticated encryption mode. The length of the key-encrypting key (1) and the hash function to use with the HKDF depend on the length of the prime, p, of the group used to provide username protection:
ユーザー名を保護するために、クライアントとサーバーは静的エフェメラルDiffie-Hellman交換を実行します。 y座標は不要であり、削除するとメッセージサイズが減少するため、静的な一時的なDiffie-Hellman交換ではコンパクトな表現（したがってコンパクトな出力。[RFC6090]を参照）が使用されます。 Diffie-Hellman交換の結果は、HMACベースの鍵導出関数（HKDF）[RFC5869]に渡され、AES-SIV [RFC5297]に適した鍵暗号鍵が作成されます（「AES」は「Advanced Encryption Standard」の略です） "および" SIV "は、確定的認証済み暗号化モードの" Synthetic Initialization Vector "を表します）。キー暗号化キー（1）の長さとHKDFで使用するハッシュ関数は、ユーザー名の保護に使用されるグループの素数pの長さに依存します。
o SHA-256, SIV-128, l=256 bits: when len(p) <= 256
o SHA-256、SIV-128、l = 256ビット：len（p）<= 256の場合
o SHA-384, SIV-192, l=384 bits: when 256 < len(p) <= 384
o SHA-384、SIV-192、l = 384ビット：256 <len（p）<= 384の場合
o SHA-512, SIV-256, l=512 bits: when len(p) > 384
o SHA-512、SIV-256、l = 512ビット：len（p）> 384の場合
Prior to initiating a TLS-PWD exchange, the client chooses a random secret, c, such that 1 < c < (q - 1), where q is the order of the group from which the server's public key was generated, and it uses scalar-op() with the group's generator to create a public key, C. It uses scalar-op() with the server's public key and c to create a shared secret, and it derives a key-encrypting key, k, using the "saltless" mode of the HKDF [RFC5869]:
TLS-PWD交換を開始する前に、クライアントは1 <c <（q-1）のようなランダムなシークレットcを選択します。ここで、qはサーバーの公開鍵が生成されたグループの順序であり、グループのジェネレーターを備えたscalar-op()を使用して公開鍵Cを作成します。サーバーの公開鍵を備えたscalar-op()とcを使用して共有シークレットを作成し、 HKDFの「無塩」モード[RFC5869]：
C = scalar-op(c, G)
C =スカラーアップ（c、G）
Z = scalar-op(c, S)
Z =スカラーアップ（c、S）
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
where NULL indicates the salt-free invocation and "" indicates an empty string (i.e., there is no "context" passed to the HKDF).
NULLはソルトフリーの呼び出しを示し、 ""は空の文字列を示します（つまり、HKDFに渡される "コンテキスト"はありません）。
The client's username SHALL be represented as a UTF-8 encoded character string processed according to the rules of the OpaqueString profile of [RFC8265]. The output of OpaqueString is then passed with the key, k, to SIV-encrypt with no Additional Authenticated Data (AAD) and no nonce, to produce an encrypted username, u:
クライアントのユーザー名は、[RFC8265]のOpaqueStringプロファイルのルールに従って処理されたUTF-8エンコードされた文字列として表現される必要があります。次に、OpaqueStringの出力がキーkとともにSIV-encryptに渡され、追加の認証データ（AAD）もナンスもない状態で、暗号化されたユーザー名uが生成されます。
u = SIV-encrypt(k, username)
u = SIV-encrypt（k、ユーザー名）
Note: The format of the ciphertext output includes the authenticating SIV.
注：暗号文出力の形式には、認証SIVが含まれます。
The protected username SHALL be the concatenation of the x-coordinate of the client's public key, C, and the encrypted username, u. The length of the x-coordinate of C MUST be equal to the length of the group's prime, p, prepended with zeros, if necessary. The protected username is inserted into the extension_data field of the pwd_protect extension (see Section 4.4.3).
保護されたユーザー名は、クライアントの公開鍵Cのx座標と暗号化されたユーザー名uを連結したものでなければなりません（SHALL）。 Cのx座標の長さは、必要に応じてゼロが前に付加されたグループの素数pの長さと等しくなければなりません。保護されたユーザー名は、pwd_protect拡張機能のextension_dataフィールドに挿入されます（セクション4.4.3を参照）。
To ensure that the username remains confidential, the random secret, c, MUST be generated from a source of random entropy; see Section 3.5.
ユーザー名の機密性を確保するために、ランダムシークレットcは、ランダムエントロピーのソースから生成する必要があります。セクション3.5を参照してください。
The length of the ciphertext output from SIV, minus the synthetic initialization vector, will be equal to the length of the input plaintext -- in this case, the username. To further foil traffic analysis, it is RECOMMENDED that clients append a series of NULL bytes to their usernames prior to passing them to SIV-encrypt() such that the resulting padded length of the username is at least 128 octets.
SIVから出力される暗号文の長さから合成初期化ベクトルを差し引いた長さは、入力平文の長さ（この場合はユーザー名）と等しくなります。トラフィック分析をさらに阻止するために、クライアントがSIV-encrypt()に渡す前にユーザー名に一連のNULLバイトを追加して、ユーザー名の埋め込み長さが少なくとも128オクテットになるようにすることをお勧めします。
A server that receives a protected username needs to recover the client's username prior to performing the key exchange. To do so, the server computes the client's public key; completes the static-ephemeral Diffie-Hellman exchange; derives the key-encrypting key, k; and decrypts the username.
保護されたユーザー名を受信するサーバーは、キー交換を実行する前にクライアントのユーザー名を回復する必要があります。そのために、サーバーはクライアントの公開鍵を計算します。静的エフェメラルDiffie-Hellman交換を完了します。鍵暗号鍵kを導出します。ユーザー名を復号化します。
The length of the x-coordinate of the client's public key is known (it is the length of the prime from the domain parameter set used to protect usernames) and can easily be separated from the ciphertext in the pwd_name extension in the ClientHello -- the first len(p) bits are the x-coordinate of the client's public key, and the remaining bits are the ciphertext.
クライアントの公開鍵のx座標の長さはわかっており（ユーザー名を保護するために使用されるドメインパラメータセットからの素数の長さです）、ClientHelloのpwd_name拡張の暗号文から簡単に分離できます。最初のlen（p）ビットはクライアントの公開鍵のx座標で、残りのビットは暗号文です。
Since compressed representation is used by the client, the server MUST compute the y-coordinate of the client's public key by using the equation of the curve:
圧縮表現はクライアントによって使用されるため、サーバーは曲線の方程式を使用してクライアントの公開鍵のy座標を計算する必要があります。
y^2 = x^3 + ax + b
and solving for y. There are two solutions for y, but since compressed output is also being used, the selection is irrelevant. The server reconstructs the client's public value, C, from (x, y). If there is no solution for y or if (x, y) is not a valid point on the elliptic curve (see Section 3.2.1), the server MUST treat the ClientHello as if it did not have a password for a given username (see Section 4.5.1.1).
yを解く。 yには2つの解決策がありますが、圧縮出力も使用されているため、選択は重要ではありません。サーバーは、（x、y）からクライアントのパブリック値Cを再構築します。 yの解がない場合、または（x、y）が楕円曲線上の有効な点でない場合（セクション3.2.1を参照）、サーバーは、指定されたユーザー名のパスワードがないかのようにClientHelloを処理する必要があります（セクション4.5.1.1を参照してください）。
The server then uses scalar-op() with the reconstructed point C and the private key it uses for protected passwords, s, to generate a shared secret, and it derives a key-encrypting key, k, in the same manner as that described in Section 4.3.1.
次にサーバーは、再構築されたポイントCと保護されたパスワードsに使用する秘密鍵を含むscalar-op()を使用して共有シークレットを生成し、前述と同じ方法で鍵暗号化鍵kを導出します。セクション4.3.1。
Z = scalar-op(s, C)
Z =スカラーアップ（s、C）
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
The key, k, and the ciphertext portion of the pwd_name extension, u, are passed to SIV-decrypt with no AAD and no nonce, to produce the username:
鍵kと、pwd_name拡張の暗号文部分uは、AADもナンスもないSIV-decryptに渡され、ユーザー名が生成されます。
username = SIV-decrypt(k, u)
ユーザー名= SIV-decrypt（k、u）
If SIV-decrypt returns the symbol FAIL indicating unsuccessful decryption and verification, the server MUST treat the ClientHello as if it did not have a password for a given username (see Section 4.5.1.1). If successful, the server has obtained the client's username and can process it as needed. Any NULL octets added by the client prior to encryption can be easily stripped off of the string that represents the username.
SIV-decryptがシンボルFAILを返し、復号化と検証が失敗したことを示す場合、サーバーはClientHelloを特定のユーザー名のパスワードを持っていないものとして扱わなければなりません（セクション4.5.1.1を参照）。成功した場合、サーバーはクライアントのユーザー名を取得しており、必要に応じてそれを処理できます。暗号化の前にクライアントによって追加されたNULLオクテットは、ユーザー名を表す文字列から簡単に取り除くことができます。
Prior to making a "commitment", both sides must generate a secret Element (PE) in the chosen group, using the common password-derived base. The server generates the PE after it receives the ClientHello and chooses the particular group to use, and the client generates the PE prior to sending the ClientHello in TLS 1.3 and upon receipt of the ServerKeyExchange in TLS pre-1.3.
「コミットメント」を行う前に、両方の側が、共通のパスワード派生ベースを使用して、選択されたグループで秘密の要素（PE）を生成する必要があります。サーバーは、ClientHelloを受信して使用する特定のグループを選択した後でPEを生成し、クライアントは、TLS 1.3でClientHelloを送信する前に、TLS pre-1.3でServerKeyExchangeを受信すると、PEを生成します。
Fixing the PE involves an iterative "hunting-and-pecking" technique using the prime from the negotiated group's domain parameter set and an ECC-specific or FFC-specific operation, depending on the negotiated group.
PEの修正には、ネゴシエートされたグループのドメインパラメータセットからの素数と、ネゴシエートされたグループに応じたECC固有またはFFC固有の操作を使用した反復的な「ハンティングアンドペッキング」技術が含まれます。
To thwart side-channel attacks that attempt to determine the number of iterations of the hunting-and-pecking loop that are used to find the PE for a given password, a security parameter, m, is used to ensure that at least m iterations are always performed.
特定のパスワードのPEを見つけるために使用されるハンティングアンドペッキングループの反復回数を決定しようとするサイドチャネル攻撃を阻止するには、セキュリティパラメータmを使用して、少なくともm回の反復が確実に行われるようにします。常に実行されます。
First, an 8-bit counter is set to the value one (1). Then, H is used to generate a password seed from the counter, the prime of the selected group, and the base (which is derived from the username, password, and, optionally, the salt; see Section 3.4):
まず、8ビットカウンターが値1に設定されます。次に、Hを使用して、カウンター、選択したグループの素数、およびベース（ユーザー名、パスワード、およびオプションでソルトから派生します。セクション3.4を参照）からパスワードシードを生成します。
pwd-seed = H(base | counter | p) Next, a context is generated consisting of random information. For versions of TLS less than 1.3, the context is a concatenation of the ClientHello random and the ServerHello random. For TLS 1.3, the context is the ClientHello random:
pwd-seed = H（base | counter | p）次に、ランダムな情報で構成されるコンテキストが生成されます。 TLSのバージョンが1.3未満の場合、コンテキストはClientHelloランダムとServerHelloランダムの連結です。 TLS 1.3の場合、コンテキストはClientHelloランダムです。
if (version < 1.3) {
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
Then, using the technique from Appendix B.5.1 of [FIPS186-4], the pwd-seed is expanded, using the Pseudorandom Function (PRF), to the length of the prime from the negotiated group's domain parameter set plus a constant, sixty-four (64), to produce an intermediate pwd-tmp, which is modularly reduced to create the pwd-value:
次に、[FIPS186-4]の付録B.5.1の手法を使用して、pseudorandom関数（PRF）を使用して、pwd-seedを、交渉されたグループのドメインパラメーターセットからの素数の長さに加えて、定数60 -four（64）：中間のpwd-tmpを生成します。これは、モジュール的に削減されてpwd-valueを作成します。
n = len(p) + 64
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
context) [0..n];
pwd-value = (pwd-tmp mod (p - 1)) + 1
The pwd-value is then passed to the group-specific operation, which either returns the selected PE or fails. If the group-specific operation fails, the counter is incremented, a new pwd-seed is generated, and the hunting-and-pecking process continues; this procedure continues until the group-specific operation returns the PE. After the PE has been chosen, the base is changed to a random number, the counter is incremented, and the hunting-and-pecking process continues until the counter is greater than the security parameter, m.
次に、pwd-valueがグループ固有の操作に渡され、選択したPEが返されるか、失敗します。グループ固有の操作が失敗した場合、カウンタが増加し、新しいpwd-seedが生成され、ハンティングアンドペッキングプロセスが続行されます。この手順は、グループ固有の操作がPEを返すまで続きます。 PEが選択された後、ベースが乱数に変更され、カウンターが増分され、カウンターがセキュリティパラメーターmを超えるまでハンティングアンドペッキングプロセスが続行されます。
The probability that one requires more than n iterations of the hunting-and-pecking loop to find an ECC PE is roughly (q/2p)^n and to find an FFC PE is roughly (q/p)^n, both of which rapidly approach zero (0) as n increases. The security parameter, m, SHOULD be set sufficiently large such that the probability that finding the PE would take more than m iterations is sufficiently small (see Section 7).
ECC PEを見つけるためにハンティングアンドペッキングループをn回以上繰り返す必要がある確率はおよそ（q / 2p）^ nであり、FFC PEを見つける確率はおよそ（q / p）^ nです。 nが増加するにつれて、急速にゼロ（0）に近づきます。セキュリティパラメータmは、PEを見つけるのにm回以上の反復が必要になる確率が十分に小さくなるように十分に大きく設定する必要があります（セクション7を参照）。
When the PE has been discovered, pwd-seed, pwd-tmp, and pwd-value SHALL be irretrievably destroyed.
PEが検出されると、pwd-seed、pwd-tmp、およびpwd-valueが回復不能に破棄される必要があります（SHALL）。
The group-specific operation for ECC groups uses pwd-value, pwd-seed, and the equation for the curve to produce the PE. First, pwd-value is used directly as the x-coordinate, x, with the equation for the elliptic curve, with parameters a and b from the domain parameter set of the curve, to solve for a y-coordinate, y. If there is no solution to the quadratic equation, this operation fails and the hunting-and-pecking process continues. If a solution is found, then an ambiguity exists, as there are technically two solutions to the equation, and pwd-seed is used to unambiguously select one of them. If the low-order bit of pwd-seed is equal to the low-order bit of y, then a candidate PE is defined as the point (x, y); if the low-order bit of pwd-seed differs from the low-order bit of y, then a candidate PE is defined as the point (x, p - y), where p is the prime over which the curve is defined. The candidate PE becomes the PE, a random number is used instead of the base, and the hunting-and-pecking process continues until it has looped through m iterations, where m is a suitably large number to prevent side-channel attacks (see [RFC7664]).
ECCグループのグループ固有の操作では、pwd-value、pwd-seed、および曲線の方程式を使用してPEを生成します。まず、pwd-valueは、x座標xとして直接使用され、楕円曲線の方程式で、曲線のドメインパラメーターセットのパラメーターaおよびbを使用して、y座標yを解決します。二次方程式の解がない場合、この操作は失敗し、ハンティングアンドペッキングプロセスが続行されます。解が見つかると、方程式には技術的に2つの解があり、pwd-seedを使用してそれらの1つを明確に選択するため、あいまいさが存在します。 pwd-seedの下位ビットがyの下位ビットと等しい場合、候補PEは点（x、y）として定義されます。 pwd-seedの下位ビットがyの下位ビットと異なる場合、候補PEは点（x、p-y）として定義されます。ここで、pは曲線が定義される素数です。候補PEがPEになり、ベースの代わりに乱数が使用されます。ハンティングアンドペッキングプロセスは、m回の繰り返しをループするまで続行されます。ここで、mはサイドチャネル攻撃を防ぐために適切に大きな数です（[ RFC7664]）。
Algorithmically, the process looks like this:
アルゴリズム的には、プロセスは次のようになります。
found = 0
counter = 0
n = len(p) + 64
if (version < 1.3)
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
do {
counter = counter + 1
seed = H(base | counter | p)
tmp = PRF(seed, "TLS-PWD Hunting And Pecking", context) [0..n]
val = (tmp mod (p - 1)) + 1
if ( (val^3 + a*val + b) mod p is a quadratic residue)
then
if (found == 0)
then
x = val
save = seed
found = 1
base = random()
fi
fi
} while ((found == 0) || (counter <= m))
y = sqrt(x^3 + a*x + b) mod p
if ( lsb(y) == lsb(save))
then
PE = (x, y)
else
PE = (x, p - y)
fi
Figure 3: Fixing PE for ECC Groups
図3：ECCグループのPEの修正
Checking whether a value is a quadratic residue modulo a prime can leak information about that value in a side-channel attack. Therefore, it is RECOMMENDED that the technique used to determine if the value is a quadratic residue modulo p first blind the value with a random number so that the blinded value can take on all numbers between 1 and (p - 1) with equal probability. Determining the quadratic residue in a fashion that resists leakage of information is handled by flipping a coin and multiplying the blinded value by either a random quadratic residue or a random quadratic nonresidue and checking whether the multiplied value is a quadratic residue or a quadratic nonresidue modulo p, respectively. The random residue and nonresidue can be calculated prior to hunting and pecking by calculating the Legendre symbol on random values until they are found:
値が素数を法とする二次剰余であるかどうかをチェックすると、サイドチャネル攻撃でその値に関する情報が漏洩する可能性があります。したがって、値がpを法とする二次剰余であるかどうかを決定するために使用される手法は、最初に乱数で値をブラインドするので、ブラインドされた値は1から（p-1）までのすべての数値を等しい確率でとることができます。情報の漏洩に抵抗する方法で2次残差を決定するには、コインを裏返し、ブラインド値にランダム2次残差またはランダム2次非残差のいずれかを乗算し、乗算された値が2次残差または2次非残差モジュロpかどうかを確認します、それぞれ。ランダムな残基と非残基は、それらが見つかるまでランダムな値でルジャンドル記号を計算することにより、ハンティングとペッキングの前に計算できます。
do {
qr = random()
} while ( lgr(qr, p) != 1)
do {
qnr = random()
} while ( lgr(qnr, p) != -1)
Algorithmically, the masking technique to find out whether a value is a quadratic residue modulo a prime or not looks like this:
アルゴリズム的に、値が素数を法とする二次剰余であるかどうかを調べるマスキング手法は、次のようになります。
is_quadratic_residue (val, p) {
r = (random() mod (p - 1)) + 1
num = (val * r * r) mod p
if ( lsb(r) == 1 )
num = (num * qr) mod p
if ( lgr(num, p) == 1)
then
return TRUE
fi
else
num = (num * qnr) mod p
if ( lgr(num, p) == -1)
then
return TRUE
fi
fi
return FALSE
}
The random quadratic residue and quadratic nonresidue (qr and qnr above) can be used for all the hunting-and-pecking loops, but the blinding value, r, MUST be chosen randomly for each loop.
ランダムな二次残差と二次非残差（上記のqrとqnr）はすべてのハンティングとペッキングループに使用できますが、ブラインド値rは各ループでランダムに選択する必要があります。
The group-specific operation for FFC groups takes the prime (p) and the order (q) from the group's domain parameter set and the variable pwd-value to directly produce a candidate PE, by exponentiating the pwd-value to the value ((p - 1)/q) modulo p. See Section 3.2.2 when the order is not part of the defined domain parameter set. If the result is greater than one (1), the candidate PE becomes the PE, and the hunting-and-pecking process continues until it has looped through m iterations, where m is a suitably large number to prevent side-channel attacks (see [RFC7664]).
FFCグループのグループ固有の操作は、グループのドメインパラメーターセットと変数pwd-valueから素数（p）と次数（q）を取り、pwd-valueを値（（ p-1）/ q）pを法とする順序が定義されたドメインパラメータセットの一部でない場合は、セクション3.2.2を参照してください。結果が1より大きい場合、候補のPEはPEになり、ハンティングアンドペッキングプロセスはm回の繰り返しをループするまで続行されます。ここで、mはサイドチャネル攻撃を防ぐために適切に大きな数です（を参照）。 [RFC7664]）。
Algorithmically, the process looks like this:
アルゴリズム的には、プロセスは次のようになります。
found = 0
counter = 0
n = len(p) + 64
if (version < 1.3)
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
do {
counter = counter + 1
pwd-seed = H(base | counter | p)
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
context) [0..n]
pwd-value = (pwd-tmp mod (p - 1)) + 1
PE = pwd-value^((p - 1)/q) mod p
if (PE > 1)
then
found = 1
base = random()
fi
} while ((found == 0) || (counter <= m))
Figure 4: Fixing PE for FFC Groups
図4：FFCグループのPEの修正
The client is required to identify herself to the server by adding either a pwd_protect or pwd_clear extension to her ClientHello message, depending on whether the client wishes to protect her username (see Section 4.3) or not, respectively. The pwd_protect and pwd_clear extensions use the standard mechanism defined in [RFC5246]. The "extension data" field of the extension SHALL contain a pwd_name, which is used to identify the password shared between the client and server. If username protection is performed and the ExtensionType is pwd_protect, the contents of the pwd_name SHALL be constructed according to Section 4.3.1.
クライアントは、クライアントがユーザー名を保護したいかどうか（セクション4.3を参照）に応じて、ClientHelloメッセージにpwd_protectまたはpwd_clear拡張を追加することにより、サーバーに対して自分自身を識別する必要があります。 pwd_protectおよびpwd_clear拡張は、[RFC5246]で定義された標準メカニズムを使用します。拡張の「拡張データ」フィールドには、クライアントとサーバー間で共有されるパスワードを識別するために使用されるpwd_nameが含まれている必要があります（SHALL）。ユーザー名保護が実行され、ExtensionTypeがpwd_protectの場合、pwd_nameの内容はセクション4.3.1に従って作成する必要があります（SHALL）。
enum { pwd_protect(29), pwd_clear(30) } ExtensionType;
opaque pwd_name<1..2^8-1>;
An unprotected pwd_name SHALL be a UTF-8 encoded character string processed according to the rules of the OpaqueString profile of [RFC8265], and a protected pwd_name SHALL be a string of bits.
保護されていないpwd_nameは、[RFC8265]のOpaqueStringプロファイルのルールに従って処理されたUTF-8でエンコードされた文字列である必要があり（SHALL）、保護されたpwd_nameはビットの文字列である必要があります（SHALL）。
The scalar and Element that comprise each peer's "commitment" are generated as follows.
各ピアの「コミットメント」を構成するスカラーと要素は、次のように生成されます。
First, two random numbers, called "private" and "mask", between zero and the order of the group (exclusive) are generated. If their sum modulo the order of the group, q, equals zero (0) or one (1), the numbers must be thrown away and new random numbers generated. If their sum modulo the order of the group, q, is greater than one, the sum becomes the scalar.
最初に、「プライベート」と「マスク」と呼ばれる、ゼロとグループの順序（排他的）の間の2つの乱数が生成されます。グループの次数を法とするそれらの和qがゼロ（0）または1（1）に等しい場合、数値は破棄され、新しい乱数が生成されます。グループの次数を法とする和qが1より大きい場合、和はスカラーになります。
scalar = (private + mask) mod q
The Element is then calculated as the inverse of the group's scalar operation (see the group-specific operations discussed in Section 3.2) with the mask and PE.
次に、要素は、マスクとPEを使用して、グループのスカラー演算（3.2で説明したグループ固有の演算を参照）の逆数として計算されます。
Element = inverse(scalar-op(mask, PE))
After calculation of the scalar and Element, the mask SHALL be irretrievably destroyed.
スカラーと要素の計算後、マスクは回復不能に破壊される必要があります。
A client offering a PWD ciphersuite MUST include one of the pwd_name extensions from Section 4.4.3 in her ClientHello.
PWD暗号スイートを提供するクライアントは、ClientHelloにセクション4.4.3のpwd_name拡張機能の1つを含める必要があります。
If a server does not have a password for a client identified by the username either extracted from the pwd_name (if unprotected) or recovered using the technique provided in Section 4.3.2 (if protected), or if recovery of a protected username fails, the server SHOULD hide that fact by simulating the protocol -- putting random data in the PWD-specific components of the ServerKeyExchange -- and then rejecting the client's finished message with a "bad_record_mac" alert [RFC8446]. To properly effect a simulated TLS-PWD exchange, an appropriate delay SHOULD be inserted between receipt of the ClientHello and response of the ServerHello. Alternately, a server MAY choose to terminate the exchange if a password is not found. The security implication of terminating the exchange is to expose to an attacker whether a username is valid or not.
サーバーに、pwd_nameから抽出されたユーザー名（保護されていない場合）またはセクション4.3.2で提供されている手法を使用して復元されたユーザー名（保護されている場合）で識別されるクライアントのパスワードがない場合、または保護されたユーザー名の復元に失敗した場合、サーバーは、プロトコルをシミュレートすることによってその事実を隠す必要があります-ServerKeyExchangeのPWD固有のコンポーネントにランダムなデータを入れて-その後、「bad_record_mac」アラート[RFC8446]でクライアントの完了メッセージを拒否します。シミュレートされたTLS-PWD交換を適切に実行するには、ClientHelloの受信とServerHelloの応答の間に適切な遅延を挿入する必要があります（SHOULD）。あるいは、パスワードが見つからない場合、サーバーは交換を終了することを選択できます。交換を終了することのセキュリティ上の意味は、ユーザー名が有効かどうかにかかわらず、攻撃者に公開することです。
The server decides on a group to use with the named user (see Section 9) and generates the PE according to Section 4.4.2.
サーバーは、指定されたユーザー（セクション9を参照）で使用するグループを決定し、セクション4.4.2に従ってPEを生成します。
The domain parameter set for the selected group MUST be explicitly specified by name in the ServerKeyExchange. ECC groups are specified using the NamedCurve enumeration of [RFC8422], and FFC groups are specified using the NamedGroup extensions added by [RFC7919] to the "TLS Supported Groups" registry in [TLS_REG]. In addition to the group specification, the ServerKeyExchange also contains the server's "commitment" in the form of a scalar and Element, and the salt that was used to store the user's password.
選択したグループのドメインパラメータセットは、ServerKeyExchangeで名前によって明示的に指定する必要があります。 ECCグループは[RFC8422]のNamedCurve列挙を使用して指定され、FFCグループは[RFC7919]によって[TLS_REG]の「TLSサポートグループ」レジストリに追加されたNamedGroup拡張を使用して指定されます。グループ指定に加えて、ServerKeyExchangeには、スカラーと要素の形式でのサーバーの「コミットメント」、およびユーザーのパスワードを格納するために使用されたソルトも含まれています。
Two new values have been added to the enumerated KeyExchangeAlgorithm to indicate TLS-PWD using FFC and TLS-PWD using ECC: ff_pwd and ec_pwd, respectively.
FFCを使用するTLS-PWDおよびECCを使用するTLS-PWDを示すために、列挙型のKeyExchangeAlgorithmに2つの新しい値が追加されました：ff_pwdおよびec_pwd。
enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
struct {
opaque salt<1..2^8-1>;
NamedGroup ff_group;
opaque ff_selement<1..2^16-1>;
opaque ff_sscalar<1..2^16-1>;
} ServerFFPWDParams;
struct {
opaque salt<1..2^8-1>;
ECParameters curve_params;
ECPoint ec_selement;
opaque ec_sscalar<1..2^8-1>;
} ServerECPWDParams;
struct {
select (KeyExchangeAlgorithm) {
case ec_pwd:
ServerECPWDParams params;
case ff_pwd:
ServerFFPWDParams params;
};
} ServerKeyExchange;
The scalar and Element referenced in this section are derived according to Section 4.4.4.
このセクションで参照されるスカラーと要素は、セクション4.4.4に従って導出されます。
ECC domain parameters are specified in the ECParameters component of the ECC-specific ServerKeyExchange as defined in [RFC8422]. The scalar SHALL become the ec_sscalar component, and the Element SHALL become the ec_selement of the ServerKeyExchange. If the client requested a specific point format (compressed or uncompressed) with the Supported Point Formats Extension (see [RFC8422]) in its ClientHello, the Element MUST be formatted in the ec_selement to conform to that request. If the client offered (an) elliptic curve(s) in its ClientHello using the Supported Elliptic Curves Extension, the server MUST include (one of the) named curve(s) in the ECParameters field in the ServerKeyExchange and the key exchange operations specified in Section 4.5.1.2.1 MUST use that group.
[RFC8422]で定義されているように、ECCドメインパラメータは、ECC固有のServerKeyExchangeのECParametersコンポーネントで指定されます。スカラーはec_sscalarコンポーネントになり、要素はサーバーキー交換のec_s要素になります。クライアントがそのClientHelloでサポートされているポイント形式拡張（[RFC8422]を参照）を使用して特定のポイント形式（圧縮または非圧縮）を要求した場合、その要求に準拠するように要素をec_selementでフォーマットする必要があります。クライアントが、サポートされている楕円曲線拡張を使用してClientHelloで楕円曲線を提供した場合、サーバーは、ServerKeyExchangeのECParametersフィールドに名前付き曲線（の1つ）と、セクション4.5.1.2.1はそのグループを使用する必要があります。
As mentioned in Section 3.2.1, characteristic-2 curves and curves with a co-factor greater than one (1) SHALL NOT be used by TLS-PWD.
セクション3.2.1で述べたように、特性2曲線および1より大きい補因子を持つ曲線は、TLS-PWDによって使用されるべきではない（SHALL NOT）。
FFC domain parameters use the NamedGroup extension specified in [RFC7919]. The scalar SHALL become the ff_sscalar component, and the Element SHALL become the ff_selement in the FFC-specific ServerKeyExchange.
FFCドメインパラメータは、[RFC7919]で指定されているNamedGroup拡張を使用します。スカラはFF_sscalarコンポーネントになり、要素はFFC固有のServerKeyExchangeのff_s要素になります。
As mentioned in Section 3.2.2, if the prime is a safe prime and no order is included in the domain parameter set, the order added to the ServerKeyExchange SHALL be the prime minus one divided by two -- (p - 1)/2.
セクション3.2.2で述べたように、素数が安全な素数であり、ドメインパラメーターセットに順序が含まれていない場合、ServerKeyExchangeに追加される順序は、素数から1を2で割ったもの（SH）でなければなりません-（p-1）/ 2 。
Upon receipt of the ServerKeyExchange, the client decides whether to support the indicated group or not. If the client decides to support the indicated group, the server's "commitment" MUST be validated by ensuring that 1) the server's scalar value is greater than one (1) and less than the order of the group, q and 2) the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2 for how to determine whether an Element is valid for the particular group. Note that if the Element is a compressed point on an elliptic curve, it MUST be uncompressed before checking its validity).
ServerKeyExchangeを受信すると、クライアントは指定されたグループをサポートするかどうかを決定します。クライアントが指定されたグループをサポートすることを決定した場合、サーバーの「コミットメント」は、1）サーバーのスカラー値が1よりも大きく、グループの順序よりも小さいこと、および2）要素が選択されたグループに対して有効です（要素が特定のグループに対して有効かどうかを判断する方法については、セクション3.2.1および3.2.2を参照してください。要素が楕円曲線上の圧縮点である場合、チェックする前に圧縮解除する必要があります。有効）。
If the group is acceptable and the server's "commitment" has been successfully validated, the client extracts the salt from the ServerKeyExchange and generates the PE according to Sections 3.4 and 4.4.2. If the group is not acceptable or the server's "commitment" failed validation, the exchange MUST be aborted.
グループが受け入れ可能であり、サーバーの「コミットメント」が正常に検証されている場合、クライアントはServerKeyExchangeからソルトを抽出し、セクション3.4および4.4.2に従ってPEを生成します。グループが受け入れられない場合、またはサーバーの「コミットメント」が検証に失敗した場合、交換を中止する必要があります。
When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, the ClientKeyExchange is used to convey the client's "commitment" to the server. It therefore contains a scalar and an Element.
KeyExchangeAlgorithmの値がff_pwdまたはec_pwdの場合、ClientKeyExchangeはクライアントの「コミットメント」をサーバーに伝えるために使用されます。したがって、スカラーと要素が含まれます。
struct {
opaque ff_celement<1..2^16-1>;
opaque ff_cscalar<1..2^16-1>;
} ClientFFPWDParams;
struct {
ECPoint ec_celement;
opaque ec_cscalar<1..2^8-1>;
} ClientECPWDParams;
struct {
select (KeyExchangeAlgorithm) {
case ff_pwd: ClientFFPWDParams;
case ec_pwd: ClientECPWDParams;
} exchange_keys;
} ClientKeyExchange;
The client's scalar and Element are generated in the manner described in Section 4.5.1.2.1.
クライアントのスカラーと要素は、4.5.1.2.1項で説明した方法で生成されます。
For an FFC group, the scalar SHALL become the ff_cscalar component and the Element SHALL become the ff_celement in the FFC-specific ClientKeyExchange.
FFCグループの場合、FFC固有のClientKeyExchangeでスカラーがff_cscalarコンポーネントになり、要素がFF_c要素になります。
For an ECC group, the scalar SHALL become the ec_cscalar component and the Element SHALL become the ec_celement in the ECC-specific ClientKeyExchange. If the client requested a specific point format (compressed or uncompressed) with the Supported Point Formats Extension in its ClientHello, then the Element MUST be formatted in the ec_celement to conform to its initial request.
ECCグループの場合、スカラーはec_cscalarコンポーネントになり、要素は、ECC固有のClientKeyExchangeのec_celementになります。クライアントがそのClientHelloでサポートされているポイントフォーマット拡張を使用して特定のポイントフォーマット（圧縮または非圧縮）を要求した場合、そのエレメントは最初のリクエストに適合するようにec_celementでフォーマットする必要があります。
Upon receipt of the ClientKeyExchange, the server must validate the client's "commitment" by ensuring that 1) the client's scalar and Element differ from the server's scalar and Element, 2) the client's scalar value is greater than one (1) and less than the order of the group, q, and 3) the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2 for how to determine whether an Element is valid for a particular group. Note that if the Element is a compressed point on an elliptic curve, it MUST be uncompressed before checking its validity). If any of these three conditions are not met, the server MUST abort the exchange.
ClientKeyExchangeを受信すると、サーバーは、1）クライアントのスカラーおよび要素がサーバーのスカラーおよび要素と異なること、2）クライアントのスカラー値が1より大きく、1より小さいことを確認することにより、クライアントの「コミットメント」を検証する必要があります。グループの順序、q、および3）エレメントは、選択したグループに対して有効です（エレメントが特定のグループに対して有効かどうかを判断する方法については、セクション3.2.1および3.2.2を参照してください。エレメントが圧縮されている場合、楕円曲線上の点、その有効性を確認する前に解凍する必要があります）。これら3つの条件のいずれかが満たされない場合、サーバーは交換を中止する必要があります。
TLS 1.3 clients and servers convey their commit values in a "key_share" extension. The structure of this extension SHALL be:
TLS 1.3クライアントとサーバーは、それらのコミット値を「key_share」拡張で伝達します。この拡張の構造は次のようにする必要があります。
enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
case ec_pwd:
opaque elemX[coordinate_length];
opaque elemY[coordinate_length];
case ff_pwd:
opaque elem[coordinate_length];
};
opaque scalar<1..2^8-1>
} PWDKeyShareEntry;
struct {
NamedGroup group;
PWDKeyShareEntry pwd_key_exchange<1..2^16-1>;
} KeyShareEntry;
The ClientHello message MUST include a pwd_name extension from Section 4.4.3 and it MUST include a key_share extension from Section 4.5.2.1.
ClientHelloメッセージには、セクション4.4.3のpwd_name拡張を含める必要があり、セクション4.5.2.1のkey_share拡張を含める必要があります。
Upon receipt of a ClientHello, the server MUST validate the key_share extension_data [RFC8446] to ensure that the scalar value is greater than one (1) and less than the order of the group q, and that the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2).
ClientHelloを受信すると、サーバーはkey_share extension_data [RFC8446]を検証して、スカラー値が1より大きく、グループqの順序よりも小さいこと、およびElementが選択したグループに対して有効であることを確認する必要があります（セクション3.2.1および3.2.2を参照してください。
If a server does not have a password for a client identified by the username either extracted from the pwd_name (if unprotected) or recovered using the technique in Section 4.3.2 (if protected), or if recovery of a protected username fails, the server SHOULD hide that fact by simulating the protocol -- putting random data in the PWD-specific components of its KeyShareEntry -- and then rejecting the client's finished message with a "bad_record_mac" alert. To properly effect a simulated TLS-PWD exchange, an appropriate delay SHOULD be inserted between receipt of the ClientHello and response of the ServerHello. Alternately, a server MAY choose to terminate the exchange if a password is not found. The security implication of terminating the exchange is to expose to an attacker whether a username is valid or not.
サーバーに、pwd_nameから抽出された（保護されていない場合）、またはセクション4.3.2の手法を使用して保護された（保護されている場合）ユーザー名で識別されるクライアントのパスワードがない場合、または保護されたユーザー名の回復に失敗した場合、サーバープロトコルをシミュレートしてランダムなデータをKeyShareEntryのPWD固有のコンポーネントに配置し、「bad_record_mac」アラートでクライアントの完成したメッセージを拒否することで、その事実を隠す必要があります（SHOULD）。シミュレートされたTLS-PWD交換を適切に実行するには、ClientHelloの受信とServerHelloの応答の間に適切な遅延を挿入する必要があります（SHOULD）。あるいは、パスワードが見つからない場合、サーバーは交換を終了することを選択できます。交換を終了することのセキュリティ上の意味は、ユーザー名が有効かどうかにかかわらず、攻撃者に公開することです。
If the server supports TLS-PWD, agrees with the group chosen by the client, and finds an unsalted password indicated by the pwd_name extension of the received ClientHello, its ServerHello MUST contain a key_share extension from Section 4.5.2.1 in the same group as that chosen by the client.
サーバーがTLS-PWDをサポートし、クライアントが選択したグループに同意し、受信したClientHelloのpwd_name拡張で示される無塩パスワードを見つけた場合、そのServerHelloは、同じグループのセクション4.5.2.1からのkey_share拡張を含んでいる必要がありますクライアントが選択。
Upon receipt of a ServerHello, the client MUST validate the key_share extension_data to ensure that the scalar value is greater than one (1) and less than the order of the group q, and that the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2).
ServerHelloを受信すると、クライアントはkey_share extension_dataを検証して、スカラー値が1より大きく、グループqの順序よりも小さいこと、およびElementが選択したグループに対して有効であることを確認する必要があります（セクション3.2を参照）。 .1および3.2.2）。
The server sends this message in response to a ClientHello if it desires a different group or if the password identified by the client's password identified by pwd_name is salted.
サーバーは、別のグループが必要な場合、またはpwd_nameで識別されるクライアントのパスワードで識別されるパスワードがソルト化されている場合、ClientHelloに応答してこのメッセージを送信します。
A different group is indicated by adding the KeyShareHelloRetryRequest extension to the HelloRetryRequest. The indication of a salted password, and the salt used, is done by adding the following structure:
KeyShareHelloRetryRequest拡張機能をHelloRetryRequestに追加すると、別のグループが示されます。ソルトされたパスワードと使用されたソルトの表示は、次の構造を追加することによって行われます。
enum { password_salt(31) } ExtensionType;
struct {
opaque pwd_salt<2^16-1>;
} password_salt;
A client that receives a HelloRetryRequest indicating the password salt SHALL delete its computed PE and derive another version using the salt prior to sending another ClientHello.
パスワードのソルトを示すHelloRetryRequestを受信したクライアントは、別のClientHelloを送信する前に、計算されたPEを削除し、ソルトを使用して別のバージョンを導出する必要があります。
The client and server use their private value as calculated in Section 4.4.4 with the other party's Element and scalar for the ServerHello or ClientHello, respectively (here denoted "Peer_Element" and "peer_scalar") to generate the shared secret z.
クライアントとサーバーは、セクション4.4.4で計算されたプライベート値を使用して、ServerHelloまたはClientHelloのそれぞれの要素とスカラー（ここでは「Peer_Element」と「peer_scalar」と表記）を使用して、共有シークレットzを生成します。
z = F(scalar-op(private,
elem-op(Peer_Element,
scalar-op(peer_scalar, PE))))
For TLS versions prior to 1.3, the intermediate value, z, is then used as the premaster secret after any leading bytes of z that contain all zero bits have been stripped off. For TLS version 1.3, leading zero bytes are retained, and the intermediate value z is used as the (EC)DHE input in the key schedule.
1.3より前のTLSバージョンの場合、中間値zは、すべてゼロのビットを含むzの先行バイトが取り除かれた後、プリマスターシークレットとして使用されます。 TLSバージョン1.3の場合、先行ゼロバイトが保持され、中間値zが鍵スケジュールの（EC）DHE入力として使用されます。
This memo adds the following ciphersuites:
このメモは以下の暗号スイートを追加します：
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
Implementations conforming to this specification MUST support the TLS_ECCPWD_WITH_AES_128_GCM_SHA256 ciphersuite; they SHOULD support the remaining ciphersuites.
この仕様に準拠する実装は、TLS_ECCPWD_WITH_AES_128_GCM_SHA256暗号スイートをサポートする必要があります。それらは残りの暗号スイートをサポートするべきです（SHOULD）。
When negotiated with a version of TLS prior to 1.2, the PRF from that earlier version is used; when the negotiated version of TLS is TLS 1.2, the PRF is the TLS 1.2 PRF [RFC5246], using the hash function indicated by the ciphersuite; when the negotiated version of TLS is TLS 1.3, the PRF is the Derive-Secret function from Section 7.1 of [RFC8446]. Regardless of the TLS version, the TLS-PWD random function, H, is always instantiated with the hash algorithm indicated by the ciphersuite.
1.2より前のバージョンのTLSとネゴシエートする場合、その以前のバージョンのPRFが使用されます。 TLSのネゴシエートされたバージョンがTLS 1.2の場合、PRFはTLS 1.2 PRF [RFC5246]であり、暗号スイートによって示されるハッシュ関数を使用します。ネゴシエートされたTLSのバージョンがTLS 1.3である場合、PRFは[RFC8446]のセクション7.1の派生秘密機能です。 TLSバージョンに関係なく、TLS-PWDランダム関数Hは常に、暗号スイートによって示されるハッシュアルゴリズムでインスタンス化されます。
For those ciphersuites that use Cipher Block Chaining (CBC) [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function indicated by the ciphersuite.
Cipher Block Chaining（CBC）[SP800-38A]モードを使用する暗号スイートの場合、MACはHMAC [RFC2104]であり、暗号スイートによって示されるハッシュ関数を備えています。
IANA has assigned three values for new TLS extension types from the "TLS ExtensionType Values" registry defined in [RFC8446] and [RFC8447]. They are pwd_protect (29), pwd_clear (30), and password_salt (31). See Sections 4.5.1.1 and 4.5.2.2 for more information.
IANAは、[RFC8446]および[RFC8447]で定義されている "TLS ExtensionType Values"レジストリから、新しいTLS拡張タイプに3つの値を割り当てました。それらは、pwd_protect（29）、pwd_clear（30）、およびpassword_salt（31）です。詳細については、セクション4.5.1.1および4.5.2.2を参照してください。
In summary, the following rows have been added to the "TLS ExtensionType Values" registry:
要約すると、次の行が「TLS ExtensionType値」レジストリに追加されました。
+-------+----------------+-------------+-----------+
| Value | Extension Name | TLS 1.3 | Reference |
+-------+----------------+-------------+-----------+
| 29 | pwd_protect | CH | RFC 8492 |
| 30 | pwd_clear | CH | RFC 8492 |
| 31 | password_salt | CH, SH, HRR | RFC 8492 |
+-------+----------------+-------------+-----------+
IANA has assigned the following ciphersuites from the "TLS Cipher Suites" registry defined in [RFC8446] and [RFC8447]:
IANAは、[RFC8446]と[RFC8447]で定義されている「TLS Cipher Suites」レジストリから次の暗号スイートを割り当てました。
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
The "DTLS-OK" column in the registry has been set to "Y", and the "Recommended" column has been set to "N" for all ciphersuites defined in this memo.
レジストリの「DTLS-OK」列は「Y」に設定され、「推奨」列はこのメモで定義されたすべての暗号スイートに対して「N」に設定されています。
A security proof of this key exchange in the random oracle model is found in [lanskro].
ランダムオラクルモデルでのこの鍵交換のセキュリティ証明は、[lanskro]にあります。
A passive attacker against this protocol will see the ServerKeyExchange and the ClientKeyExchange (in TLS pre-1.3), or the KeyShare (from TLS 1.3), containing the scalar and Element of the server and the client, respectively. The client and server effectively hide their secret private value by masking it modulo the order of the selected group. If the order is "q", then there are approximately "q" distinct pairs of numbers that will sum to the scalar values observed. It is possible for an attacker to iterate through all such values, but for a large value of "q", this exhaustive search technique is computationally infeasible. The attacker would have a better chance in solving the discrete logarithm problem, which we have already assumed (see Section 3.5) to be an intractable problem.
このプロトコルに対するパッシブな攻撃者は、ServerKeyExchangeとClientKeyExchange（TLS pre-1.3の場合）、またはKeyShare（TLS 1.3の場合）を参照し、それぞれサーバーとクライアントのスカラーとElementを含みます。クライアントとサーバーは、選択されたグループの順序を法としてそれをマスクすることにより、秘密のプライベート値を効果的に隠します。順序が「q」の場合、合計して観測されるスカラー値になる約「q」個の異なる数値のペアがあります。攻撃者がそのようなすべての値を反復処理することは可能ですが、「q」の値が大きい場合、この徹底的な検索手法は計算上実行不可能です。攻撃者は、離散対数問題を解決する可能性が高くなります。離散対数問題は、すでに扱いにくい問題であると既に想定しています（セクション3.5を参照）。
A passive attacker can take the Element from the ServerKeyExchange or the ClientKeyExchange (in TLS pre-1.3), or from the KeyShare (from TLS 1.3), and try to determine the random "mask" value used in its construction and then recover the other party's "private" value from the scalar in the same message. But this requires the attacker to solve the discrete logarithm problem, which we assumed was intractable.
パッシブな攻撃者は、ServerKeyExchangeまたはClientKeyExchange（TLS pre-1.3の場合）、またはKeyShare（TLS 1.3の場合）からElementを取得し、その構成で使用されているランダムな「マスク」値を特定して、もう一方を回復しようとします。同じメッセージ内のスカラーからのパーティーの「プライベート」値。しかし、これには攻撃者が離散対数問題を解く必要があります。
Both the client and the server obtain a shared secret based on a secret group Element and the private information they contributed to the exchange. The secret group Element is based on the password. If they do not share the same password, they will be unable to derive the same secret group Element, and if they don't generate the same secret group Element, they will be unable to generate the same shared secret. Seeing a finished message will not provide any additional advantage of attack, since it is generated with the unknowable secret.
クライアントとサーバーの両方が、シークレットグループの要素と、それらが交換に貢献した個人情報に基づいて共有シークレットを取得します。秘密グループElementはパスワードに基づいています。同じパスワードを共有しない場合、同じシークレットグループエレメントを導出できず、同じシークレットグループエレメントを生成しない場合、同じ共有シークレットを生成できません。完成したメッセージは、未知のシークレットを使用して生成されるため、攻撃の利点はありません。
In TLS pre-1.3, an active attacker impersonating the client can induce a server to send a ServerKeyExchange containing the server's scalar and Element. The attacker can attempt to generate a ClientKeyExchange and send it to the server, but she is required to send a finished message first; therefore, the only information she can obtain in this attack is less than the information she can obtain from a passive attack, so this particular active attack is not very fruitful.
TLS 1.3より前のバージョンでは、クライアントになりすましているアクティブな攻撃者が、サーバーにサーバーのスカラーと要素を含むServerKeyExchangeを送信させる可能性があります。攻撃者はClientKeyExchangeを生成してサーバーに送信することを試みることができますが、完成したメッセージを最初に送信する必要があります。したがって、この攻撃で取得できる情報はパッシブ攻撃で取得できる情報よりも少ないため、この特定のアクティブ攻撃はあまり実りがありません。
In TLS pre-1.3, an active attacker can impersonate the server and send a forged ServerKeyExchange after receiving the ClientHello. The attacker then waits until it receives the ClientKeyExchange and finished message from the client. Now the attacker can attempt to run through all possible values of the password, computing the PE (see Section 4.4), computing candidate premaster secrets (see Section 4.6), and attempting to recreate the client's finished message.
TLS pre-1.3では、アクティブな攻撃者がサーバーを偽装し、ClientHelloを受信した後で偽造されたServerKeyExchangeを送信できます。その後、攻撃者は、ClientKeyExchangeと終了したメッセージをクライアントから受信するまで待機します。これで攻撃者は、可能なすべてのパスワード値の実行、PEの計算（セクション4.4を参照）、候補プレマスターシークレットの計算（セクション4.6を参照）、およびクライアントの完成したメッセージの再作成を試みることができます。
But the attacker committed to a single guess of the password with her forged ServerKeyExchange. That value was used by the client in her computation of the premaster secret, which was used to produce the finished message. Any guess of the password that differs from the password used in the forged ServerKeyExchange would result in each side using a different PE in the computation of the premaster secret; therefore, the finished message cannot be verified as correct, even if a subsequent guess, while running through all possible values, was correct. The attacker gets one guess, and one guess only, per active attack.
しかし、攻撃者は偽造されたServerKeyExchangeを使用して、パスワードを1回推測することを約束しました。その値は、完成したメッセージを生成するために使用されたプリマスターシークレットの計算でクライアントによって使用されました。偽造されたServerKeyExchangeで使用されているパスワードと異なるパスワードを推測すると、プリマスターシークレットの計算で両側が異なるPEを使用することになります。したがって、可能なすべての値を実行しながら後続の推測が正しかったとしても、完成したメッセージは正しいと検証できません。攻撃者は、アクティブな攻撃ごとに1つの推測と1つの推測のみを取得します。
Instead of attempting to guess at the password, an attacker can attempt to determine the PE and then launch an attack. But the PE is determined by the output of the random function, H, which is indistinguishable from a random source, since H is assumed to be a "random oracle" (Section 3.5). Therefore, each Element of the finite cyclic group will have an equal probability of being the PE. The probability of guessing the PE will be 1/q, where q is the order of the group. For a large value of "q", this will be computationally infeasible.
攻撃者はパスワードを推測する代わりに、PEを特定して攻撃を仕掛けることができます。しかし、PEはランダム関数Hの出力によって決定されます。Hは「ランダムオラクル」（セクション3.5）であると想定されているため、ランダムソースと区別できません。したがって、有限循環グループの各要素は、PEになる確率が等しくなります。 PEを推測する確率は1 / qです。ここで、qはグループの次数です。 「q」の値が大きい場合、これは計算上実行不可能です。
The implications of resistance to dictionary attacks are significant. An implementation can provision a password in a practical and realistic manner -- i.e., it MAY be a character string, and it MAY be relatively short -- and still maintain security. The nature of the pool of potential passwords determines the size of the pool, D, and countermeasures can prevent an attacker from determining the password in the only possible way: repeated, active, guessing attacks. For example, a simple four-character string using lowercase English characters, and assuming random selection of those characters, will result in D of over four hundred thousand. An attacker would need to mount over one hundred thousand active, guessing attacks (which will easily be detected) before gaining any significant advantage in determining the pre-shared key.
辞書攻撃に対する耐性の影響は重要です。実装は、実用的かつ現実的な方法でパスワードをプロビジョニングできます。つまり、パスワードは文字列であり、比較的短い可能性がありますが、セキュリティを維持できます。潜在的なパスワードのプールの性質により、プールのサイズDが決まり、対策によって、攻撃者が唯一の可能な方法であるパスワードの決定を防ぐことができます。たとえば、小文字の英語の文字を使用し、それらの文字をランダムに選択すると仮定した単純な4文字の文字列は、40万を超えるDになります。攻撃者は、事前共有キーを決定する上で重要な利点を得る前に、10万を超えるアクティブな推測攻撃（簡単に検出される）をマウントする必要があります。
Countermeasures to deal with successive active, guessing attacks are only possible by noticing that a certain username is failing repeatedly over a certain period of time. Attacks that attempt to find a password for a random user are more difficult to detect. For instance, if a device uses a serial number as a username and the pool of potential passwords is sufficiently small, a more effective attack would be to select a password and try all potential "users" to disperse the attack and confound countermeasures. It is therefore RECOMMENDED that implementations of TLS-PWD keep track of the total number of failed authentications, regardless of username, in an effort to detect and thwart this type of attack.
連続したアクティブな推測攻撃に対処するための対策は、特定のユーザー名が特定の期間にわたって繰り返し失敗することに気づくことによってのみ可能です。ランダムなユーザーのパスワードを見つけようとする攻撃は、検出がより困難です。たとえば、デバイスがユーザー名としてシリアル番号を使用し、潜在的なパスワードのプールが十分に小さい場合、より効果的な攻撃は、パスワードを選択し、すべての潜在的な「ユーザー」に攻撃と分散対策を分散させることです。したがって、TLS-PWDの実装は、このタイプの攻撃を検出して阻止するために、ユーザー名に関係なく、失敗した認証の総数を追跡することをお勧めします。
The benefits of resistance to dictionary attacks can be lessened by a client using the same passwords with multiple servers. An attacker could redirect a session from one server to the other if the attacker knew that the intended server stored the same password for the client as another server.
辞書攻撃への耐性の利点は、クライアントが複数のサーバーで同じパスワードを使用することで軽減できます。攻撃者は、目的のサーバーが別のサーバーと同じクライアントのパスワードを保存していることを知っている場合、セッションを1つのサーバーから別のサーバーにリダイレクトする可能性があります。
An adversary that has access to, and a considerable amount of control over, a client or server could attempt to mount a side-channel attack to determine the number of times it took for a certain password (plus client random and server random) to select a PE. Each such attack could result in a successive "paring down" of the size of the pool of potential passwords, resulting in a manageably small set from which to launch a series of active attacks to determine the password. A security parameter, m, is used to normalize the amount of work necessary to determine the PE (see Section 4.4). The probability that a password will require more than m iterations is roughly (q/2p)^m for ECC groups and (q/p)^m for FFC groups, so it is possible to mitigate side-channel attacks at the expense of a constant cost per connection attempt. But if a particular password requires more than k iterations, it will leak k bits of information to the side-channel attacker; for some dictionaries, this will uniquely identify the password. Therefore, the security parameter, m, needs to be set with great care. It is RECOMMENDED that an implementation set the security parameter, m, to a value of at least forty (40), which will put the probability that more than forty iterations are needed in the order of one in one trillion (1:1,000,000,000,000).
クライアントまたはサーバーにアクセスし、かなりの量の制御権を持つ攻撃者は、サイドチャネル攻撃を仕掛けて、特定のパスワード（およびクライアントのランダムとサーバーのランダム）が選択するのにかかった回数を判断する可能性があります。 PE。このような攻撃のたびに、潜在的なパスワードのプールのサイズが連続的に「削減」され、一連のアクティブな攻撃を開始してパスワードを決定するための、管理可能なほど小さなセットができます。セキュリティパラメータmは、PEを決定するために必要な作業量を正規化するために使用されます（セクション4.4を参照）。パスワードがm回を超える反復を必要とする確率は、ECCグループの場合はおおよそ（q / 2p）^ mであり、FFCグループの場合は（q / p）^ mであるため、コストを犠牲にしてサイドチャネル攻撃を緩和することが可能です。接続試行あたりの一定のコスト。ただし、特定のパスワードでk回を超える反復が必要な場合、kビットの情報がサイドチャネル攻撃者に漏洩します。一部の辞書では、これによりパスワードが一意に識別されます。したがって、セキュリティパラメータmは細心の注意を払って設定する必要があります。実装でセキュリティパラメータmを少なくとも40の値に設定することをお勧めします。これにより、40を超える反復が1兆分の1（1：1,000,000,000,000）のオーダーで必要になる確率が高くなります。
A database of salted passwords prevents an adversary who gains access to the database from learning the client's password; it does not prevent such an adversary from impersonating the client back to the server. Each side uses the salted password, called the base, as the authentication credential, so the database of salted passwords MUST be afforded the security of a database of plaintext passwords.
ソルトされたパスワードのデータベースは、データベースにアクセスする敵がクライアントのパスワードを知ることを防ぎます。そのような攻撃者がクライアントを偽装してサーバーに戻すことを妨げるものではありません。どちらの側も、ベースと呼ばれるソルトパスワードを認証資格情報として使用するため、ソルトパスワードのデータベースには、平文パスワードのデータベースのセキュリティを提供する必要があります。
Authentication is performed by proving knowledge of the password. Any third party that knows the password shared by the client and server can impersonate one to the other.
認証は、パスワードの知識を証明することによって実行されます。クライアントとサーバーが共有するパスワードを知っているサードパーティは、一方を他方に偽装できます。
The static-ephemeral Diffie-Hellman exchange used to protect usernames requires the server to reuse its Diffie-Hellman public key. To prevent an "invalid curve" attack, an entity that reuses its Diffie-Hellman public key needs to check whether the received ephemeral public key is actually a point on the curve. This is done explicitly as part of the server's reconstruction of the client's public key out of only its x-coordinate ("compact representation").
ユーザー名を保護するために使用される静的エフェメラルDiffie-Hellman交換では、サーバーがDiffie-Hellman公開鍵を再利用する必要があります。 「無効な曲線」攻撃を防ぐために、Diffie-Hellman公開鍵を再利用するエンティティは、受信した一時的な公開鍵が実際に曲線上の点であるかどうかを確認する必要があります。これは、サーバーのx座標のみからのクライアントの公開鍵の再構築（「コンパクト表現」）の一部として明示的に行われます。
At the time of publication of this document, there was a growing interest in considering the impacts that IETF (and IRTF) work can have on human rights; some related research is discussed in [RFC8280]. As such, the human rights considerations of TLS-PWD are presented here.
このドキュメントの発行時点で、IETF（およびIRTF）の作業が人権に与える影響を検討することに関心が高まりました。いくつかの関連する研究は[RFC8280]で議論されています。そのため、TLS-PWDの人権に関する考慮事項をここに示します。
The key exchange underlying TLS-PWD uses public key cryptography to perform authentication and authenticated key exchange. The keys it produces can be used to establish secure connections between two people to protect their communication. Implementations of TLS-PWD, like implementations of other TLS ciphersuites that perform authentication and authenticated key establishment, are considered "armaments" or "munitions" by many governments around the world.
TLS-PWDの基礎となるキー交換では、公開キー暗号化を使用して、認証と認証済みキー交換を実行します。それが生成するキーを使用して、2人のユーザー間の通信を保護するための安全な接続を確立できます。 TLS-PWDの実装は、認証および認証されたキーの確立を実行する他のTLS暗号スイートの実装と同様に、世界中の多くの政府によって「兵器」または「軍需品」と見なされています。
The most fundamental of human rights is the right to protect oneself. The right to keep and bear arms is an example of this right. Implementations of TLS-PWD can be used as arms, kept and borne, to defend oneself against all manner of attackers -- criminals, governments, lawyers, etc. TLS-PWD is a powerful tool in the promotion and defense of universal human rights.
人権の最も基本的なものは、自分を守る権利です。武器を保持し耐える権利は、この権利の一例です。 TLS-PWDの実装は、あらゆる種類の攻撃者（犯罪者、政府、弁護士など）から身を守るための武器として使用できます。TLS-PWDは、普遍的な人権の促進と防御において強力なツールです。
The selection of the ciphersuite and selection of the particular finite cyclic group to use with the ciphersuite are divorced in this memo, but they remain intimately close.
暗号スイートの選択と、暗号スイートで使用する特定の有限循環グループの選択は、このメモでは分離されていますが、それらは密接な関係にあります。
It is RECOMMENDED that implementations take note of the strength estimates of particular groups and select a ciphersuite providing commensurate security with its hash and encryption algorithms. A ciphersuite whose encryption algorithm has a keylength less than the strength estimate or whose hash algorithm has a block size that is less than twice the strength estimate SHOULD NOT be used.
実装では、特定のグループの強度推定値に注意し、ハッシュと暗号化アルゴリズムで相応のセキュリティを提供する暗号スイートを選択することをお勧めします。暗号化アルゴリズムのキー長が強度推定値より短い暗号スイート、またはハッシュアルゴリズムのブロックサイズが強度推定値の2倍より小さい暗号スイートは使用しないでください。
For example, the elliptic curve named "brainpoolP256r1" (whose IANA-assigned number is 26) [RFC7027] provides an estimated 128 bits of strength and would be compatible with 1) an encryption algorithm supporting a key of that length and 2) a hash algorithm that has at least a 256-bit block size. Therefore, a suitable ciphersuite to use with brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see Appendix A for an example of such an exchange).
たとえば、「brainpoolP256r1」という名前の楕円曲線（IANAが割り当てた番号は26）[RFC7027]は、推定128ビットの強度を提供し、1）その長さのキーをサポートする暗号化アルゴリズムと2）ハッシュと互換性があります。 256ビット以上のブロックサイズを持つアルゴリズム。したがって、brainpoolP256r1で使用するのに適した暗号スイートは、TLS_ECCPWD_WITH_AES_128_GCM_SHA256です（このような交換の例については、付録Aを参照してください）。
Resistance to dictionary attacks means that the attacker must launch an active attack to make a single guess at the password. If the size of the pool from which the password was extracted was D and each password in the pool has an equal probability of being chosen, then the probability of success after a single guess is 1/D. After X guesses and the removal of failed guesses from the pool of possible passwords, the probability becomes 1/(D-X). As X grows, so does the probability of success. Therefore, it is possible for an attacker to determine the password through repeated brute-force, active, guessing attacks. Implementations SHOULD take note of this fact and choose an appropriate pool of potential passwords -- i.e., make D big. Implementations SHOULD also take countermeasures -- for instance, refusing authentication attempts by a particular username for a certain amount of time, after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo.
辞書攻撃への耐性とは、攻撃者がパスワードを1回推測するためにアクティブな攻撃を開始する必要があることを意味します。パスワードの抽出元のプールのサイズがDであり、プール内の各パスワードが選択される確率が等しい場合、1回の推測で成功する確率は1 / Dです。 Xが推測し、失敗した推測を可能なパスワードのプールから削除すると、確率は1 /（D-X）になります。 Xが大きくなると、成功の確率も大きくなります。そのため、攻撃者は、ブルートフォース攻撃、推測攻撃を繰り返し行うことでパスワードを特定することができます。実装は、この事実に注意し、潜在的なパスワードの適切なプールを選択する必要があります。つまり、Dを大きくします。実装では、対策も講じる必要があります。たとえば、失敗した認証の試行回数が特定のしきい値に達した後、特定のユーザー名による認証の試行を一定時間拒否します。このメモでは、そのようなしきい値や時間量は推奨されていません。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://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月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 2008, <https://www.rfc-editor.org/info/rfc5297>.
[RFC5297] Harkins、D。、「Advanced Encryption Standard（AES）を使用したSynthetic Initialization Vector（SIV）Authenticated Encryption」、RFC 5297、DOI 10.17487 / RFC5297、2008年10月、<https://www.rfc-editor.org / info / rfc5297>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、DOI 10.17487 / RFC5869、2010年5月、<https：//www.rfc-editor .org / info / rfc5869>。
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>.
[RFC7919] Gillmor、D。、「トランスポート層セキュリティ（TLS）の交渉済み有限フィールドDiffie-Hellman一時パラメータ」、RFC 7919、DOI 10.17487 / RFC7919、2016年8月、<https://www.rfc-editor.org/ info / rfc7919>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>.
[RFC8265] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 8265、DOI 10.17487 / RFC8265、2017年10月、<https：//www.rfc- editor.org/info/rfc8265>。
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8422] Nir、Y.、Josefsson、S。、およびM. Pegourie-Gonnard、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）Versions 1.2 andlier」、RFC 8422、DOI 10.17487 / RFC8422、 2018年8月、<https://www.rfc-editor.org/info/rfc8422>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.
[RFC8447] Salowey、J。およびS.ターナー、「TLSおよびDTLSのIANAレジストリ更新」、RFC 8447、DOI 10.17487 / RFC8447、2018年8月、<https://www.rfc-editor.org/info/rfc8447> 。
[TLS_REG] IANA, "Transport Layer Security (TLS) Parameters", <https://www.iana.org/assignments/tls-parameters/>.
[TLS_REG] IANA、「Transport Layer Security（TLS）Parameters」、<https://www.iana.org/assignments/tls-parameters/>。
[FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186-4]米国国立標準技術研究所、「デジタル署名標準（DSS）」、連邦情報処理標準出版物186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<https：// nvlpubs .nist.gov / nistpubs / FIPS / NIST.FIPS.186-4.pdf>。
[lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of the Dragonfly Protocol", ISC 2015 Proceedings of the 18th International Conference on Information Security - Volume 9290, pp. 244-261, DOI 10.1007/978-3-319-23318-5_14, September 2015.
[lanskro] Lancrenon、J。およびM. Skrobot、「トンボプロトコルの証明可能なセキュリティについて」、ISC 2015 Proceedings of the 18th International Conference on Information Security-Volume 9290、pp。244-261、DOI 10.1007 / 978-3 -319-23318-5_14、2015年9月。
[RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 62-73, ACM Press, DOI 10.1145/168588.168596, November 1993.
[RANDOR] Bellare、M。、およびP. Rogaway、「ランダムなオラクルは実用的：効率的なプロトコルを設計するためのパラダイム」、第1回コンピュータと通信のセキュリティに関するACM会議の議事録、pp。62-73、ACM Press、DOI 10.1145 / 168588.168596、1993年11月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、DOI 10.17487 / RFC6090、2011年2月、<https://www.rfc-editor.org/ info / rfc6090>。
[RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)", RFC 7027, DOI 10.17487/RFC7027, October 2013, <https://www.rfc-editor.org/info/rfc7027>.
[RFC7027] Merkle、J。およびM. Lochter、「トランスポート層セキュリティ（TLS）のための楕円曲線暗号（ECC）ブレインプール曲線」、RFC 7027、DOI 10.17487 / RFC7027、2013年10月、<https：//www.rfc- editor.org/info/rfc7027>。
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030] Pritikin、M。、編、Yee、P。、編、およびD. Harkins、編、「Enrollment over Secure Transport」、RFC 7030、DOI 10.17487 / RFC7030、2013年10月、<https：// www.rfc-editor.org/info/rfc7030>。
[RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 10.17487/RFC7664, November 2015, <https://www.rfc-editor.org/info/rfc7664>.
[RFC7664] Harkins、D。、編、「Dragonfly Key Exchange」、RFC 7664、DOI 10.17487 / RFC7664、2015年11月、<https://www.rfc-editor.org/info/rfc7664>。
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, October 2017, <https://www.rfc-editor.org/info/rfc8280>.
[RFC8280] ten Oever、N。およびC. Cath、「Research into Human Rights Protocol Considerations」、RFC 8280、DOI 10.17487 / RFC8280、2017年10月、<https://www.rfc-editor.org/info/rfc8280> 。
[SP800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation - Methods and Techniques", NIST Special Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December 2001, <https://nvlpubs.nist.gov/nistpubs/ Legacy/SP/nistspecialpublication800-38a.pdf>.
[SP800-38A] Dworkin、M。、「ブロック暗号動作モードの推奨-メソッドとテクニック」、NIST Special Publication 800-38A、DOI 10.6028 / NIST.SP.800-38A、2001年12月、<https：// nvlpubs.nist.gov/nistpubs/ Legacy / SP / nistspecialpublication800-38a.pdf>。
[SP800-56A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, Revision 3, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>.
[SP800-56A] Barker、E.、Chen、L.、Roginsky、A.、Vassilev、A。、およびR. Davis、「離散対数暗号化を使用したペアワイズキー確立スキームの推奨」、NIST Special Publication 800 -56A、リビジョン3、DOI 10.6028 / NIST.SP.800-56Ar3、2018年4月、<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>。
username: fred password: barney
ユーザー名：fredパスワード：barney
---- prior to running TLS-PWD ----
server generates salt:
サーバーはソルトを生成します：
96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
and a base:
そしてベース：
6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75
6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75
---- state derived during the TLS-PWD exchange ----
client and server agree to use brainpoolP256r1
クライアントとサーバーは、brainpoolP256r1の使用に同意します
client and server generate the PE:
クライアントとサーバーがPEを生成します。
PE.x: 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6
B x：29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6
server private and mask:
サーバープライベートとマスク：
private: 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c mask: 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5
プライベート：21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3cマスク：0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5
client private and mask:
クライアントプライベートおよびマスク：
private: 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b mask: 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd both parties generate premaster secret and master secret
プライベート：17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8bマスク：4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd両方がプリマスターシークレットとマスターシークレットを生成する
premaster secret: 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4 master secret: 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad
プリマスターシークレット：01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4マスターシークレット：65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad
---- ssldump output of exchange ----
New TCP connection #1: Charlene Client <-> Sammy Server 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake ClientHello Version 3.3 random[32]= 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d ciphersuites TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV Unknown value 0xff compression methods NULL extensions TLS-PWD unprotected name[5]= 04 66 72 65 64 elliptic curve point format[4]= 03 00 01 02 elliptic curve list[58]= 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 Packet data[178]= 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 01 01
新しいTCP接続＃1：Charlene Client <-> Sammy Server 1 1 0.0018（0.0018）C> SV3.3（173）Handshake ClientHello Version 3.3 random [32] = 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d ciphersuites TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV不明な値0xff圧縮メソッドNULL拡張TLS-P5 64曲線64 [lippoint 64 [eltic] 64 [保護されたポイント] 64 TLS-P5保護されていない64 TLS-P5 64保護されていない保護されている03 00 01 02楕円曲線リスト[58] = 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11パケットデータ[178] = 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 17 0 0 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 01 01
1 2 0.0043 (0.0024) S>CV3.3(94) Handshake ServerHello Version 3.3 random[32]= 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa session_id[32]= ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV compressionMethod NULL extensions renegotiate[1]= 00 elliptic curve point format[4]= 03 00 01 02 heartbeat[1]= 01 Packet data[99]= 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f 00 01 01
1 2 0.0043（0.0024）S> CV3.3（94）Handshake ServerHello Version 3.3 random [32] = 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa session_id [32] = ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIVgeti圧縮メソッドNULL ] = 00楕円曲線ポイント形式[4] = 03 00 01 02ハートビート[1] = 01パケットデータ[99] = 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f 00 01 01
1 3 0.0043 (0.0000) S>CV3.3(141) Handshake ServerKeyExchange params salt[32]= 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 EC parameters = 3 curve id = 26 element[65]= 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 scalar[32]= 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21 Packet data[146]= 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21
1 3 0.0043（0.0000）S> CV3.3（141）Handshake ServerKeyExchange params salt [32] = 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 ECパラメータ= 3曲線ID = 26要素[65] = 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1スカラー[32] = 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21パケットデータ[146] = 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21
1 4 0.0043 (0.0000) S>CV3.3(4) Handshake ServerHelloDone Packet data[9]= 16 03 03 00 04 0e 00 00 00
1 4 0.0043（0.0000）S> CV3.3（4）Handshake ServerHelloDone Packet data [9] = 16 03 03 00 04 0e 00 00 00
1 5 0.0086 (0.0043) C>SV3.3(104) Handshake ClientKeyExchange element[65]= 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0 scalar[32]= 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 Packet data[109]= 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48
1 5 0.0086（0.0043）C> SV3.3（104）Handshake ClientKeyExchange element [65] = 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0 scalar [32] = 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48パケットデータ[109] = 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48
1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec Packet data[6]= 14 03 03 00 01 01
1 6 0.0086（0.0000）C> SV3.3（1）ChangeCipherSpecパケットデータ[6] = 14 03 03 00 01 01
1 7 0.0086 (0.0000) C>SV3.3(40) Handshake Packet data[45]= 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20
1 7 0.0086（0.0000）C> SV3.3（40）ハンドシェイクパケットデータ[45] = 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20
1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec Packet data[6]= 14 03 03 00 01 01
1 8 0.0105（0.0018）S> CV3.3（1）ChangeCipherSpecパケットデータ[6] = 14 03 03 00 01 01
1 9 0.0105 (0.0000) S>CV3.3(40) Handshake Packet data[45]= 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 a2 21 94 90 12 72 23 18 24 21 c3 60 a4
1 9 0.0105（0.0000）S> CV3.3（40）ハンドシェイクパケットデータ[45] = 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 a2 21 94 90 12 72 23 18 24 21 c3 60 a4
1 10 0.0107 (0.0002) C>SV3.3(100) application_data
Packet data....
Acknowledgements
謝辞
The authenticated key exchange defined here has also been defined for use in 802.11 networks, as an Extensible Authentication Protocol (EAP) method, and as an authentication method for the Internet Key Exchange Protocol (IKE). Each of these specifications has elicited very helpful comments from a wide collection of people that have allowed the definition of the authenticated key exchange to be refined and improved.
ここで定義されている認証済みのキー交換は、802.11ネットワークでの使用のために、拡張認証プロトコル（EAP）メソッドとして、およびインターネットキー交換プロトコル（IKE）の認証メソッドとしても定義されています。これらの各仕様は、認証された鍵交換の定義を改良および改善することを可能にした幅広い人々から非常に役立つコメントを引き出しています。
The author would like to thank Scott Fluhrer for discovering the "password as exponent" attack that was possible in an early version of this key exchange and for his very helpful suggestions on the techniques for fixing the PE to prevent it. The author would also like to thank Hideyuki Suzuki for his insight in discovering an attack against a previous version of the underlying key exchange protocol. Special thanks to Lily Chen for helpful discussions on hashing into an elliptic curve. Rich Davis suggested the defensive checks that are part of the processing of the ServerKeyExchange and ClientKeyExchange messages, and his various comments have greatly improved the quality of this memo and the underlying key exchange on which it is based.
著者は、この鍵交換の初期バージョンで可能だった「パスワードとしての指数」攻撃を発見し、PEを修正してそれを防止する手法に関する非常に役立つ提案をしてくれたScott Fluhrerに感謝します。作者は、基になる鍵交換プロトコルの以前のバージョンに対する攻撃を発見した洞察を提供してくれた鈴木秀之にも感謝します。楕円曲線へのハッシュに関する有益な議論をしてくれたLily Chenに特に感謝します。 Rich Davisは、ServerKeyExchangeおよびClientKeyExchangeメッセージの処理の一部である防御的なチェックを提案し、彼のさまざまなコメントによって、このメモの品質と、それに基づく基になるキー交換が大幅に改善されました。
Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik discussed on the TLS mailing list the possibility of a side-channel attack against the hunting-and-pecking loop. That discussion prompted the addition of the security parameter, m, to the hunting-and-pecking loop. Scott Fluhrer suggested the blinding technique to test whether a value is a quadratic residue modulo a prime in a manner that does not leak information about the value being tested.
Martin Rex、Peter Gutmann、Marsh Ray、およびRene Struikは、TLSメーリングリストで、狩猟と狩猟のループに対するサイドチャネル攻撃の可能性について議論しました。この議論により、セキュリティパラメータmがハンティングアンドペッキングループに追加されました。 Scott Fluhrerは、テストされている値に関する情報を漏らさない方法で、値が素数を法とする二次剰余であるかどうかをテストするブラインド手法を提案しました。
Author's Address
著者のアドレス
Dan Harkins (editor) HP Enterprise 3333 Scott Blvd. Santa Clara, CA 95054 United States of America
Dan Harkins（編集者）HP Enterprise 3333 Scott Blvd.サンタクララ、カリフォルニア州95054アメリカ合衆国
Email: dharkins@lounge.org