[要約] RFC 8110は「Opportunistic Wireless Encryption (OWE)」に関する文書で、公開Wi-Fiなどの無線ネットワークにおける通信の暗号化を、事前共有キーまたは認証サーバーを必要とせずに実現する方法を提案しています。この技術の目的は、特に認証が行われない環境でのユーザーのプライバシーとデータの保護を強化することにあります。利用場面としては、カフェや空港などの公共の場所で提供されるWi-Fiネットワークが挙げられます。関連するRFCとしては、RFC 7748（楕円曲線の使用に関するもの）やRFC 8110が参照されることがあります。これらの技術は、より安全な無線ネットワーク接続の普及を目指しています。
Internet Engineering Task Force (IETF) D. Harkins, Ed.
Request for Comments: 8110 HP Enterprise
Category: Informational W. Kumari, Ed.
ISSN: 2070-1721 Google
March 2017
Opportunistic Wireless Encryption
日和見ワイヤレス暗号化
Abstract
概要
This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.
このメモは、無線メディアに便宜的（認証されていない）暗号化を提供するためのIEEE Std 802.11への拡張を指定しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8110.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8110で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. 802.11 Network Access . . . . . . . . . . . . . . . . . . . . 4
4. Opportunistic Wireless Encryption . . . . . . . . . . . . . . 5
4.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 5
4.2. OWE Discovery . . . . . . . . . . . . . . . . . . . . . . 6
4.3. OWE Association . . . . . . . . . . . . . . . . . . . . . 7
4.4. OWE Post-Association . . . . . . . . . . . . . . . . . . 8
4.5. OWE PMK Caching . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Considerations . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
This memo describes Opportunistic Wireless Encryption (OWE) -- a mode of opportunistic security [RFC7435] for IEEE Std 802.11 that provides encryption of the wireless medium but no authentication.
このメモは、日和見ワイヤレス暗号化（OWE）-ワイヤレスメディアの暗号化を提供するが認証は行わないIEEE Std 802.11の日和見セキュリティ[RFC7435]のモードについて説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This memo uses the following notation:
このメモは次の表記を使用します：
y = F(X) An element-to-scalar mapping function. For an elliptic curve group, it takes a point on the curve and returns the x-coordinate; for a finite field element, it is the identity function, just returning the element itself.
y = F（X）要素からスカラーへのマッピング関数。楕円曲線グループの場合、曲線上の点を取得して、x座標を返します。有限フィールド要素の場合、これは恒等関数であり、要素自体を返すだけです。
Z = DH(x,Y) For an elliptic curve, DH(x,Y) is the multiplication of point Y by the scalar value x, creating a point on the curve Z; for finite field cryptography, DH(x,Y) is an exponentiation of element Y to the power of x (implied modulo a field defining prime, p) resulting in an element Z.
Z = DH（x、Y）楕円曲線の場合、DH（x、Y）は、点Yとスカラー値xの乗算で、曲線Zに点を作成します。有限体暗号の場合、DH（x、Y）は要素Yをxの累乗で累乗したもの（素数pを定義する体を法として暗示される）で要素Zになります。
a = len(b) Indicates the length in bits of the string b.
a = len（b）文字列bの長さをビット単位で示します。
Internet access has become an expected service at many locations -- for example, coffee shops, airports, and hotels. In many cases, this is offered over "Open" (unencrypted) wireless networks, because distributing a passphrase (or using other authentication solutions) is not convenient or realistic. Ideally, users would always use a VPN when using an untrusted network, but often they don't. This leaves their traffic vulnerable to sniffing attacks, for example, from someone in the adjacent hotel room running Wireshark, pervasive monitors, etc.
インターネットアクセスは、コーヒーショップ、空港、ホテルなど、多くの場所で期待されるサービスになっています。多くの場合、これは「オープン」（暗号化されていない）ワイヤレスネットワークで提供されます。これは、パスフレーズの配布（または他の認証ソリューションの使用）が便利または現実的でないためです。理想的には、信頼されていないネットワークを使用する場合、ユーザーは常にVPNを使用しますが、多くの場合は使用しません。これにより、たとえば、Wireshark、パーベイシブモニターなどを実行している隣接するホテルの部屋の誰かからのスニッフィング攻撃に対して脆弱になります。
In addition, many businesses (for example, coffee shops and bars) offer free Wi-Fi as an inducement to customers to enter and remain in the premises. Many customers will use the availability of free Wi-Fi as a deciding factor in which business to patronize. Since these businesses are not Internet service providers, they are often unwilling and/or unqualified to perform complex configuration on their network. In addition, customers are generally unwilling to do complicated provisioning on their devices just to obtain free Wi-Fi. This leads to a popular deployment technique -- a network protected using a shared and public Pre-Shared Key (PSK) that is printed on a sandwich board at the entrance, on a chalkboard on the wall, or on a menu. The PSK is used in a cryptographic handshake, defined in [IEEE802.11], called the "4-way handshake" to prove knowledge of the PSK and derive traffic encryption keys for bulk wireless data.
さらに、多くの企業（たとえば、コーヒーショップやバー）は、顧客が敷地内に立ち入りを続けるように誘導するために、無料のWi-Fiを提供しています。多くのお客様は、無料Wi-Fiの可用性を、ビジネスをひいきにする決定的な要因として使用します。これらの企業はインターネットサービスプロバイダーではないため、ネットワーク上で複雑な構成を実行することを望まない、または資格がないことがよくあります。さらに、お客様は通常、無料のWi-Fiを取得するためだけにデバイスで複雑なプロビジョニングを行うことを望んでいません。これにより、一般的な導入手法が導入されます。ネットワークは、入り口のサンドイッチボード、壁の黒板、またはメニューに印刷されている共有および公開の事前共有キー（PSK）を使用して保護されています。 PSKは、[IEEE802.11]で定義されている「4ウェイハンドシェイク」と呼ばれる暗号化ハンドシェイクで使用され、PSKの知識を証明し、バルクワイヤレスデータのトラフィック暗号化キーを導き出します。
The belief is that this protects the wireless medium from passive sniffing and simple attacks. That belief is erroneous. Since the PSK is known by everyone, it is possible for a passive attacker to observe the 4-way handshake and compute the traffic encryption keys used by a client and access point (AP). If the attacker is too late to observe this exchange, he can issue a forged "deauthenticate" frame that will cause the client and/or AP to reset the 802.11 state machine and cause them to go through the 4-way handshake again, thereby allowing the passive attacker to determine the traffic keys.
これにより、パッシブスニッフィングや単純な攻撃からワイヤレスメディアが保護されます。その信念は誤りです。 PSKは誰でも知っているため、パッシブな攻撃者が4ウェイハンドシェイクを観察し、クライアントとアクセスポイント（AP）で使用されるトラフィック暗号化キーを計算する可能性があります。攻撃者がこの交換を観察するには遅すぎる場合、偽造された「認証解除」フレームを発行して、クライアントやAPに802.11ステートマシンをリセットさせ、4ウェイハンドシェイクを再度行わせることで、トラフィックキーを決定するためのパッシブアタッカー。
With OWE, the client and AP perform a Diffie-Hellman key exchange during the access procedure and use the resulting pairwise secret with the 4-way handshake instead of using a shared and public PSK in the 4-way handshake.
OWEでは、クライアントとAPがアクセス手順中にDiffie-Hellman鍵交換を実行し、4ウェイハンドシェイクで共有およびパブリックPSKを使用する代わりに、4ウェイハンドシェイクでペアワイズシークレットを使用します。
OWE requires no special configuration or user interaction but provides a higher level of security than a common, shared, and public PSK. OWE not only provides more security to the end user, it is also easier to use both for the provider and the end user because there are no public keys to maintain, share, or manage.
OWEでは、特別な構成やユーザーの操作は必要ありませんが、共通、共有、パブリックPSKよりも高いレベルのセキュリティが提供されます。 OWEは、エンドユーザーにより多くのセキュリティを提供するだけでなく、維持、共有、または管理する公開キーがないため、プロバイダーとエンドユーザーの両方でより簡単に使用できます。
Wi-Fi access points (APs) advertise their presence through frames called "beacons". These frames inform clients within earshot of the SSID (Service Set Identifier) the AP is advertising, the AP's Media Access Control (MAC) address (known as its "BSSID" (Basic Service Set Identifier)), security policy governing access, the symmetric ciphers it uses for unicast and broadcast frames, QoS information, as well as support for other optional features of [IEEE802.11]. Wi-Fi clients can actively discover APs by issuing "probe requests", which are queries for APs that respond with "probe responses". A probe response carries essentially the same information as a beacon.
Wi-Fiアクセスポイント（AP）は、「ビーコン」と呼ばれるフレームを通じてその存在をアドバタイズします。これらのフレームは、APがアドバタイズしているSSID（Service Set Identifier）、APのメディアアクセスコントロール（MAC）アドレス（「BSSID」（Basic Service Set Identifier）として知られている）、アクセスを制御するセキュリティポリシー、対称性をクライアントに通知します。ユニキャストおよびブロードキャストフレーム、QoS情報、および[IEEE802.11]の他のオプション機能のサポートに使用する暗号。 Wi-Fiクライアントは、「プローブ応答」で応答するAPのクエリである「プローブ要求」を発行することにより、APをアクティブに検出できます。プローブ応答は、基本的にビーコンと同じ情報を伝達します。
After an AP is discovered by a client, actively through probing or passively through beacons, the client initiates a two-step method to gain network access. The first step is "802.11 authentication". For most methods of access, this is an empty exchange known as "Open Authentication" -- basically, the client says, "authenticate me", and the AP responds, "ok, you're authenticated". After 802.11 authentication is 802.11 association, in which the client requests network access from an AP (the SSID, a selection of the type of subsequent authentication to be made, any pairwise and group ciphers, etc.) using an 802.11 association request. The AP acknowledges the request with an 802.11 association response.
APがクライアントによって検出された後、プローブを介してアクティブに、またはビーコンを介してパッシブに、クライアントは2段階の方法でネットワークアクセスを取得します。最初のステップは「802.11認証」です。ほとんどのアクセス方法では、これは「オープン認証」と呼ばれる空の交換です。基本的に、クライアントは「私を認証します」と言い、APは「OK、あなたは認証されました」と応答します。 802.11認証の後は、802.11アソシエーションです。クライアントは、802.11アソシエーション要求を使用して、APからのネットワークアクセスを要求します（SSID、行われる後続認証の種類の選択、ペアワイズ暗号およびグループ暗号など）。 APは、802.11アソシエーション応答で要求を確認します。
If the network is Open (no authentication and no encryption), the client has network access immediately after completion of 802.11 association. If the network enforces PSK authentication, the 4-way handshake is initiated by the AP using the PSK to authenticate the client and derive traffic encryption keys.
ネットワークが開いている（認証も暗号化もない）場合、クライアントは802.11アソシエーションの完了直後にネットワークにアクセスできます。ネットワークでPSK認証が実施されている場合、APはPSKを使用して4ウェイハンドシェイクを開始し、クライアントを認証してトラフィック暗号化キーを導出します。
To add an opportunistic encryption mode of access to [IEEE802.11], it is necessary to perform a Diffie-Hellman key exchange during 802.11 authentication and use the resulting pairwise secret with the 4-way handshake.
日和見暗号化アクセスモードを[IEEE802.11]に追加するには、802.11認証中にDiffie-Hellman鍵交換を実行し、結果として得られるペアワイズシークレットを4ウェイハンドシェイクで使用する必要があります。
Performing a Diffie-Hellman key exchange requires agreement on a domain parameter set in which to perform the exchange. OWE uses a registry (see [IKE-IANA]) to map an integer into a complete domain parameter set. OWE supports both Elliptic Curve Cryptography (ECC) and Finite Field Cryptography (FFC).
Diffie-Hellman鍵交換を実行するには、交換を実行するドメインパラメータセットについて合意する必要があります。 OWEはレジストリ（[IKE-IANA]を参照）を使用して整数を完全なドメインパラメータセットにマップします。 OWEは、楕円曲線暗号（ECC）と有限体暗号（FFC）の両方をサポートしています。
OWE uses a hash algorithm for generation of a secret and a secret identifier. The particular hash algorithm depends on the group chosen for the Diffie-Hellman. For ECC, the hash algorithm depends on the size of the prime defining the curve p:
OWEは、シークレットとシークレットIDの生成にハッシュアルゴリズムを使用します。特定のハッシュアルゴリズムは、Diffie-Hellmanに選択されたグループによって異なります。 ECCの場合、ハッシュアルゴリズムは曲線pを定義する素数のサイズに依存します。
o SHA-256: when len(p) <= 256
o SHA-256：len（p）<= 256の場合
o SHA-384: when 256 < len(p) <= 384
o SHA-384：256 <len（p）<= 384の場合
o SHA-512: when 384 < len(p) For FFC, the hash algorithm depends on the prime, p, defining the finite field:
o SHA-512：384 <len（p）の場合FFCの場合、ハッシュアルゴリズムは有限体を定義する素数pに依存します。
o SHA-256: when len(p) <= 2048
o SHA-256：len（p）<= 2048の場合
o SHA-384: when 2048 < len(p) <= 3072
o SHA-384：2048 <len（p）<= 3072の場合
o SHA-512: when 3072 < len(p)
o SHA-512：3072 <len（p）の場合
An access point advertises support for OWE using an Authentication and Key Management (AKM) suite selector for OWE. This AKM is illustrated in Table 1 and is added to the Robust Security Network (RSN) element, defined in [IEEE802.11], in all beacons and probe response frames the AP issues.
アクセスポイントは、OWEの認証およびキー管理（AKM）スイートセレクターを使用してOWEのサポートをアドバタイズします。このAKMを表1に示し、APが発行するすべてのビーコンおよびプローブ応答フレームで、[IEEE802.11]で定義されている堅牢なセキュリティネットワーク（RSN）要素に追加されます。
+----------+--------+-------------------+-------------+-------------+
| OUI | Suite | Authentication | Key | Key |
| | Type | Type | Management | derivation |
| | | | Type | type |
+----------+--------+-------------------+-------------+-------------+
| 00-0F-AC | 18 | Opportunistic | This | [RFC5869] |
| | | Wireless | document | |
| | | Encryption | | |
+----------+--------+-------------------+-------------+-------------+
Table 1: OWE AKM
表1：OWE AKM
Once a client discovers an OWE-compliant AP, it performs "Open System" 802.11 authentication as defined in [IEEE802.11], and it then proceeds to 802.11 association.
クライアントがOWE準拠のAPを検出すると、[IEEE802.11]で定義されている「オープンシステム」802.11認証を実行し、802.11アソシエーションに進みます。
Information is added to 802.11 association requests and responses using TLVs that [IEEE802.11] calls "elements". Each element has an "Element ID" (including any Element ID extension), a length, and a value field that is element specific. These elements are appended to each other to construct 802.11 association requests and responses.
[IEEE802.11]が「要素」と呼ぶTLVを使用して、802.11アソシエーションの要求と応答に情報が追加されます。各要素には、「要素ID」（要素ID拡張を含む）、長さ、および要素固有の値フィールドがあります。これらの要素は、802.11アソシエーションの要求と応答を構築するために互いに追加されます。
OWE adds the Diffie-Hellman Parameter element (see Figure 1) to 802.11 association requests and responses. The client adds her public key in the 802.11 association request, and the AP adds his public key in the 802.11 association response.
OWEはDiffie-Hellmanパラメータ要素（図1を参照）を802.11アソシエーションの要求と応答に追加します。クライアントは自分の公開鍵を802.11アソシエーション要求に追加し、APは自分の公開鍵を802.11アソシエーション応答に追加します。
+------------+----------+------------+------------------------+
| Element ID | Length | Element ID | element-specific |
| | | Extension | data |
+------------+----------+------------+---------+--------------+
| 255 | variable | 32 | group | public key |
+------------+----------+------------+---------+--------------+
Figure 1: The Diffie-Hellman Parameter Element
図1：Diffie-Hellmanパラメータ要素
where:
ただし：
o group is an unsigned two-octet integer defined in [IKE-IANA], in little-endian format, that identifies a domain parameter set;
o groupは、[IKE-IANA]で定義されている符号なしの2オクテット整数であり、ドメインパラメータセットを識別するリトルエンディアン形式です。
o public key is an octet string representing the Diffie-Hellman public key; and,
o 公開鍵は、Diffie-Hellman公開鍵を表すオクテット文字列です。そして、
o Element ID, Length, and Element ID Extension are all single-octet integers.
o 要素ID、長さ、および要素ID拡張子はすべて1オクテットの整数です。
The encoding of the public key depends on its type. FFC elements SHALL be encoded per the integer-to-octet-string conversion technique of [RFC6090]. For ECC elements, the encoding depends on the definition of the curve, either that in [RFC6090] or [RFC7748]. If the public key is from a curve defined in [RFC6090], compact representation SHALL be used.
公開鍵のエンコードは、そのタイプによって異なります。 FFC要素は、[RFC6090]の整数からオクテット文字列への変換技術に従ってエンコードされる必要があります（SHALL）。 ECC要素の場合、エンコードは、[RFC6090]または[RFC7748]のいずれかの曲線の定義に依存します。公開鍵が[RFC6090]で定義された曲線からのものである場合、コンパクトな表現を使用する必要があります（SHALL）。
A client wishing to do OWE MUST indicate the OWE AKM in the RSN element portion of the 802.11 association request and MUST include a Diffie-Hellman Parameter element to its 802.11 association request. An AP agreeing to do OWE MUST include the OWE AKM in the RSN element portion of the 802.11 association response. If "PMK caching" (see Section 4.5) is not performed, it MUST also include a Diffie-Hellman Parameter element. If "PMK caching" is not being performed, a client MUST discard any 802.11 association response that indicates the OWE AKM in the RSN element but does not have not a Diffie-Hellman Parameter element.
OWEを実行したいクライアントは、802.11アソシエーション要求のRSN要素部分にOWE AKMを指定する必要があり、802.11アソシエーション要求にDiffie-Hellmanパラメータ要素を含める必要があります。 OWEを実行することに同意するAPは、802.11アソシエーション応答のRSN要素部分にOWE AKMを含める必要があります。 「PMKキャッシング」（セクション4.5を参照）が実行されない場合は、Diffie-Hellmanパラメータ要素も含める必要があります。 「PMKキャッシング」が実行されていない場合、クライアントは、RSN要素でOWE AKMを示すがDiffie-Hellmanパラメータ要素を持たない802.11アソシエーション応答を破棄する必要があります。
For interoperability purposes, a compliant implementation MUST support group nineteen (19), a 256-bit elliptic curve group. If the AP does not support the group indicated in the received 802.11 association request, it MUST respond with an 802.11 association response with a status code of seventy-seven (77) indicating an unsupported finite cyclic group. A client that receives an 802.11 association response with a status code of seventy-seven SHOULD retry OWE with a different supported group and, due to the unsecured nature of 802.11 association, MAY request association again using the group that resulted in failure. This failure SHOULD be logged, and if the client abandons association due to the failure to agree on any group, notification of this fact SHOULD be provided to the user.
相互運用性の目的で、準拠した実装は、グループ19（256ビットの楕円曲線グループ）をサポートする必要があります。 APが受信した802.11アソシエーション要求で示されたグループをサポートしていない場合、サポートされていない有限循環グループを示す77（77）のステータスコードで802.11アソシエーション応答で応答する必要があります。ステータスコードが77の802.11アソシエーション応答を受信するクライアントは、サポートされている別のグループでOWEを再試行する必要があります（SHOULD）。802.11アソシエーションの保護されていない性質により、失敗したグループを使用してアソシエーションを再度要求できます（MAY）。この失敗はログに記録する必要があり（SHOULD）、クライアントがグループの合意に失敗したために関連付けを中止する場合は、この事実の通知をユーザーに提供する必要があります（SHOULD）。
Received Diffie-Hellman Parameter elements are checked for validity upon receipt. For ECC, a validity check depends on the curve definition, either that in [RFC6090] or [RFC7748]. For FFC, elements are checked that they are between one (1) and one (1) less than the prime, p, exclusive (i.e., 1 < element < p-1). Invalid received Diffie-Hellman keys MUST result in unsuccessful association, a failure of OWE, and a reset of the 802.11 state machine. Due to the unsecured nature of 802.11 association, a client SHOULD retry OWE a number of times (this memo does not specify the number of times). This failure should be logged, and if the client abandons association due to the (repeated) receipt of invalid elements, notification of this fact should be provided to the user.
受信したDiffie-Hellmanパラメータ要素は、受信時に有効性がチェックされます。 ECCの場合、妥当性チェックは、[RFC6090]または[RFC7748]のいずれかの曲線定義に依存します。 FFCの場合、要素は、素数pを除く1から1の間であるかどうかがチェックされます（つまり、1 <要素<p-1）。無効な受信Diffie-Hellmanキーは、関連付けの失敗、OWEの失敗、および802.11ステートマシンのリセットを引き起こす必要があります。 802.11アソシエーションの保護されていない性質のため、クライアントはOWEを何度か再試行する必要があります（このメモは回数を指定していません）。この失敗はログに記録する必要があり、無効な要素を（繰り返し）受信したためにクライアントが関連付けを放棄した場合は、この事実をユーザーに通知する必要があります。
Once the client and AP have finished 802.11 association, they then complete the Diffie-Hellman key exchange and create a Pairwise Master Key (PMK) and its associated identifier, PMKID [IEEE802.11]. Given a private key x and the peer's (AP's if client, client's if AP) public key Y, the following are generated:
クライアントとAPは、802.11アソシエーションを完了すると、Diffie-Hellmanキー交換を完了し、ペアワイズマスターキー（PMK）とそれに関連付けられた識別子、PMKID [IEEE802.11]を作成します。秘密鍵xとピア（クライアントの場合はAP、クライアントの場合はAP）の公開鍵Yを指定すると、次のものが生成されます。
z = F(DH(x, Y))
prk = HKDF-extract(C | A | group, z)
prk = HKDF-extract（C | A |グループ、z）
PMK = HKDF-expand(prk, "OWE Key Generation", n)
PMK = HKDF-expand（prk、 "OWE Key Generation"、n）
where HKDF-expand() and HKDF-extract() are defined in [RFC5869]; "C | A | group" is a concatenation of the client's Diffie-Hellman public key, the AP's Diffie-Hellman public key (from the 802.11 association request and response, respectively), and the two-octet group from the Diffie-Hellman Parameter element (in little-endian format) and is passed as the salt to the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) using the hash algorithm defined in Section 4.1; and n is the bit length of the digest produced by that hash algorithm. z and prk SHOULD be irretrievably deleted once the PMK has been generated.
ここで、HKDF-expand()およびHKDF-extract()は[RFC5869]で定義されています。 「C | A | group」は、クライアントのDiffie-Hellman公開鍵、APのDiffie-Hellman公開鍵（それぞれ802.11アソシエーション要求と応答からの）、およびDiffie-Hellmanパラメータからの2オクテットグループの連結です。要素（リトルエンディアン形式）であり、セクション4.1で定義されているハッシュアルゴリズムを使用して、HMACベースの抽出および拡張キー導出関数（HKDF）にソルトとして渡されます。 nは、そのハッシュアルゴリズムによって生成されるダイジェストのビット長です。 PMKが生成されたら、zとprkを回復できないように削除する必要があります。
The PMKID is generated by hashing the two Diffie-Hellman public keys (the data, as sent and received, from the "public key" portion of the Diffie-Hellman Parameter element in the 802.11 association request and response) and returning the leftmost 128 bits:
PMKIDは、2つのDiffie-Hellman公開キー（802.11アソシエーションの要求と応答のDiffie-Hellmanパラメータ要素の「公開キー」部分から送受信されるデータ）をハッシュし、左端の128ビットを返すことによって生成されます。 ：
PMKID = Truncate-128(Hash(C | A))
where C is the client's Diffie-Hellman public key from the 802.11 association request, A is the AP's Diffie-Hellman public key from the 802.11 association response, and Hash is the hash algorithm defined in Section 4.1.
ここで、Cは802.11アソシエーション要求からのクライアントのDiffie-Hellman公開鍵、Aは802.11アソシエーション応答からのAPのDiffie-Hellman公開鍵、Hashはセクション4.1で定義されたハッシュアルゴリズムです。
+---------+--------------+----------+-------+------------+----------+
| Hash | Integrity | KCK_bits | Size | Key-wrap | KEK_bits |
| | Algorithm | | of | Algorithm | |
| | | | MIC | | |
+---------+--------------+----------+-------+------------+----------+
| SHA-256 | HMAC-SHA-256 | 128 | 16 | NIST AES | 128 |
| | | | | Key-wrap | |
| SHA-384 | HMAC-SHA-384 | 192 | 24 | NIST AES | 256 |
| | | | | Key-wrap | |
| SHA-512 | HMAC-SHA-521 | 256 | 32 | NIST AES | 256 |
| | | | | Key-wrap | |
+---------+--------------+----------+-------+------------+----------+
Table 2: Integrity and Key Wrap Algorithms
表2：整合性とキーラップアルゴリズム
Upon completion of 802.11 association, the AP initiates the 4-way handshake to the client using the PMK generated above. The 4-way handshake generates a Key-Encrypting Key (KEK), a Key-Confirmation Key (KCK), and a Message Integrity Code (MIC) to use for protection of the frames that define the 4-way handshake. The algorithms and key lengths used in the 4-way handshake depend on the hash algorithm selected in Section 4.1 and are listed in Table 2.
802.11アソシエーションが完了すると、APは上記で生成されたPMKを使用してクライアントへの4ウェイハンドシェイクを開始します。 4ウェイハンドシェイクは、4ウェイハンドシェイクを定義するフレームの保護に使用するキー暗号化キー（KEK）、キー確認キー（KCK）、およびメッセージ整合性コード（MIC）を生成します。 4ウェイハンドシェイクで使用されるアルゴリズムとキーの長さは、セクション4.1で選択したハッシュアルゴリズムに依存し、表2にリストされています。
The result of the 4-way handshake is encryption keys to protect bulk unicast data and broadcast data. If the 4-way handshake fails, this information SHOULD be presented to the user.
4ウェイハンドシェイクの結果は、バルクユニキャストデータとブロードキャストデータを保護するための暗号化キーです。 4ウェイハンドシェイクが失敗した場合、この情報をユーザーに提示する必要があります（SHOULD）。
[IEEE802.11] defines "PMK caching" where a client and access point can cache a PMK for a certain period of time and reuse it with the 4-way handshake after subsequent associations to bypass potentially expensive authentication. A client indicates its desire to do "PMK caching" by including the identifying PMKID in its 802.11 association request. If an AP has cached the PMK identified by that PMKID, it includes the PMKID in its 802.11 association response; otherwise, it ignores the PMKID and proceeds with normal 802.11 association. OWE supports the notion of "PMK caching".
[IEEE802.11]は、クライアントとアクセスポイントが一定期間PMKをキャッシュし、その後のアソシエーションの後に4ウェイハンドシェイクでそれを再利用して、潜在的に高価な認証をバイパスできる「PMKキャッシング」を定義します。クライアントは、802.11アソシエーション要求に識別PMKIDを含めることにより、「PMKキャッシング」を実行したいという希望を示します。 APがそのPMKIDで識別されるPMKをキャッシュしている場合は、802.11アソシエーション応答にPMKIDが含まれています。それ以外の場合は、PMKIDを無視して、通常の802.11アソシエーションを続行します。 OWEは「PMKキャッシング」の概念をサポートしています。
Since "PMK caching" is indicated in the same frame as the Diffie-Hellman Parameter element is passed, a client wishing to do "PMK caching" MUST include both in her 802.11 association request. If the AP has the PMK identified by the PMKID and wishes to perform "PMK caching", he will include the PMKID in his 802.11 association response but does not include a Diffie-Hellman Parameter element. If the AP does not have the PMK identified by the PMKID, it ignores the PMKID and proceeds with normal OWE 802.11 association by including a Diffie-Hellman Parameter element.
「PMKキャッシング」はDiffie-Hellmanパラメータ要素が渡されるのと同じフレームで示されるため、「PMKキャッシング」を実行したいクライアントは両方を802.11アソシエーション要求に含める必要があります。 APがPMKIDで識別されたPMKを持ち、「PMKキャッシング」を実行したい場合、APKは802.11アソシエーション応答にPMKIDを含めますが、Diffie-Hellmanパラメータ要素は含めません。 APにPMKIDで識別されたPMKがない場合、APはPMKIDを無視し、Diffie-Hellmanパラメータ要素を含めることで通常のOWE 802.11アソシエーションを続行します。
When attempting "PMK caching", a client SHALL ignore any Diffie-Hellman Parameter element in an 802.11 association response whose PMKID matches that of the client-issued 802.11 association request. If the 802.11 association response does not include a PMKID, or if the PMKID does not match that of the client-issued 802.11 association request, the client SHALL proceed with normal OWE association.
「PMKキャッシング」を試行するとき、クライアントは、PMKIDがクライアントが発行した802.11アソシエーション要求のものと一致する802.11アソシエーション応答内のDiffie-Hellmanパラメータ要素をすべて無視する必要があります（SHALL）。 802.11アソシエーション応答にPMKIDが含まれていない場合、またはPMKIDがクライアント発行の802.11アソシエーション要求のものと一致しない場合、クライアントは通常のOWEアソシエーションを続行する必要があります（SHALL）。
The client SHALL ignore a PMKID in any 802.11 association response frame for which it did not include a PMKID in the corresponding 802.11 association request frame.
クライアントは、対応する802.11アソシエーション要求フレームにPMKIDが含まれていない802.11アソシエーション応答フレームのPMKIDを無視する必要があります（SHALL）。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
OWE is a replacement for 802.11 "Open" authentication. Therefore, when OWE-compliant access points are discovered, the presentation of the available SSID to users should not include special security symbols such as a "lock icon". To a user, an OWE SSID is the same as "Open"; it simply provides more security behind the scenes.
OWEは802.11「オープン」認証の代替品です。したがって、OWE準拠のアクセスポイントが検出された場合、利用可能なSSIDのユーザーへの提示には、「ロックアイコン」などの特別なセキュリティシンボルを含めないでください。ユーザーにとって、OWE SSIDは「オープン」と同じです。それは単に舞台裏でより多くのセキュリティを提供します。
When OWE is initially deployed as a replacement for an existing network that uses "Open" authentication or a shared and public PSK, it will be necessary to create an additional Basic Service Set Identifier (BSSID) or a new Extended Service Set (ESS) with a separate Service Set Identifier (SSID) for OWE so two distinct 802.11 networks can exist on the same access point (see [IEEE802.11]). This arrangement should remain until the majority of users have switched over to OWE.
OWEが「オープン」認証または共有およびパブリックPSKを使用する既存のネットワークの代替として最初に導入される場合、追加の基本サービスセット識別子（BSSID）または新しい拡張サービスセット（ESS）を作成する必要があります。 OWE用の個別のサービスセット識別子（SSID）。2つの異なる802.11ネットワークが同じアクセスポイントに存在できる（[IEEE802.11]を参照）。このアレンジメントは、大多数のユーザーがOWEに切り替えるまで維持する必要があります。
Opportunistic encryption does not provide authentication. The client will have no authenticated identity for the access point, and vice versa. They will share pairwise traffic encryption keys and have a cryptographic assurance that a frame claimed to be from the peer is actually from the peer and was not modified in flight.
日和見暗号化は認証を提供しません。クライアントにはアクセスポイントの認証済みIDがなく、その逆も同様です。それらはペアワイズトラフィック暗号化キーを共有し、ピアからのものであると主張されたフレームが実際にはピアからのものであり、飛行中に変更されていないことを暗号で保証します。
OWE only secures data sent over the wireless medium and does not provide security for end-to-end traffic. Users should still use application-level security to achieve security end-to-end.
OWEは、ワイヤレスメディアを介して送信されるデータのみを保護し、エンドツーエンドトラフィックのセキュリティを提供しません。ユーザーは、アプリケーションレベルのセキュリティを使用して、エンドツーエンドのセキュリティを実現する必要があります。
OWE is susceptible to an active attack in which an adversary impersonates an access point and induces a client to connect to it via OWE while it makes a connection to the legitimate access point. In this particular attack, the adversary is able to inspect, modify, and forge any data between the client and legitimate access point.
OWEは、攻撃者がアクセスポイントになりすまし、クライアントが正規のアクセスポイントに接続しているときにOWEを介してそれにアクセスするように誘導するアクティブな攻撃を受けやすいです。この特定の攻撃では、攻撃者はクライアントと正当なアクセスポイント間のデータを検査、変更、および偽造することができます。
OWE is not a replacement for any authentication protocol specified in [IEEE802.11] and is not intended to be used when an alternative that provides real authentication is available.
OWEは、[IEEE802.11]で指定されている認証プロトコルの代替ではなく、実際の認証を提供する代替手段が利用可能な場合に使用することを意図していません。
[IEEE802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11, DOI 10.1109/IEEESTD.2016.7786995.
[IEEE802.11] IEEE、「IEEE Standard for Information technology-- Telecommunications and information exchange between system Local and Metropolitan Area Network--Specific requirements-Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」 、IEEE Std 802.11、DOI 10.1109 / IEEESTD.2016.7786995。
[IKE-IANA] IANA, "Transform Type 4 - Diffie-Hellman Group Transform IDs", <http://www.iana.org/assignments/ikev2-parameters/>.
[IKE-IANA] IANA、「Transform Type 4-Diffie-Hellman Group Transform IDs」、<http://www.iana.org/assignments/ikev2-parameters/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、DOI 10.17487 / RFC5869、2010年5月、<http：//www.rfc-editor .org / info / rfc5869>。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://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月、<http://www.rfc-editor.org/ info / rfc6090>。
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>.
[RFC7748]ラングレー、A。、ハンブルク、M。、およびS.ターナー、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<http://www.rfc-editor.org/info / rfc7748>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
Authors' Addresses
著者のアドレス
Dan Harkins (editor) HP Enterprise 3333 Scott Boulevard Santa Clara, California 95054 United States of America
Dan Harkins（編集者）HP Enterprise 3333 Scott Boulevard Santa Clara、California 95054アメリカ合衆国
Phone: +1 415 555 1212
Email: dharkins@arubanetworks.com
Warren Kumari (editor) Google 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America
ウォーレンクマリ（編集者）グーグル1600アンフィシアターパークウェイマウンテンビュー、カリフォルニア94043アメリカ合衆国
Phone: +1 408 555 1212
Email: warren@kumari.net