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
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 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
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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
此外，许多企业（例如咖啡店和酒吧）提供免费Wi-Fi，以诱使客户进入并留在酒店内。许多客户将免费Wi-Fi的可用性作为光顾企业的决定因素。自从这些
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而在其设备上进行复杂的资源调配。这导致了一种流行的部署技术——一种使用共享和公共预共享密钥（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路握手中使用生成的成对密钥，而不是在4路握手中使用共享和公共PSK。
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（服务集标识符）、AP的媒体访问控制（MAC）地址（称为其“BSSID”（基本服务集标识符））、控制访问的安全策略、用于单播和广播帧的对称密码、QoS信息、，以及对[IEEE802.11]其他可选功能的支持。Wi-Fi客户端可以通过发出“探测请求”（probe requests）来主动发现AP，该请求是对以“probe responses”响应的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后，客户端启动两步方法以获得网络访问。第一步是“802.11身份验证”。对于大多数访问方法，这是一个称为“开放身份验证”的空交换——基本上，客户机说“验证我”，AP回答“好的，您已验证”。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使用哈希算法生成秘密和秘密标识符。特定的哈希算法取决于为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)
o SHA-512:384<len时（p）
For FFC, the hash algorithm depends on the prime, p, defining the finite field:
对于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所示，并添加到[IEEE802.11]中定义的健壮安全网络（RSN）元素中，在AP问题的所有信标和探测响应帧中。
+----------+--------+-------------------+-------------+-------------+
| OUI | Suite | Authentication | Key | Key |
| | Type | Type | Management | derivation |
| | | | Type | type |
+----------+--------+-------------------+-------------+-------------+
| 00-0F-AC | 18 | Opportunistic | This | [RFC5869] |
| | | Wireless | document | |
| | | Encryption | | |
+----------+--------+-------------------+-------------+-------------+
+----------+--------+-------------------+-------------+-------------+
| 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: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 |
+------------+----------+------------+---------+--------------+
+------------+----------+------------+------------------------+
| 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]中定义的无符号双八位整数，采用小端格式，用于标识域参数集；
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扩展都是单八位整数。
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]的整数到八位字节字符串转换技术进行编码。对于ECC元素，编码取决于[RFC6090]或[RFC7748]中的曲线定义。如果公钥来自[RFC6090]中定义的曲线，则应使用紧凑表示法。
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
希望进行OWE的客户机必须在802.11关联请求的RSN元素部分指示OWE AKM，并且必须在其802.11关联请求中包含Diffie-Hellman参数元素。同意进行OWE的AP必须在802.11关联响应的RSN元素部分包含OWE AKM。如果未执行“PMK缓存”（见第4.5节），则还必须包含Diffie-Hellman参数元素。如果未执行“PMK缓存”，则客户端必须放弃任何指示该请求的802.11关联响应
AKM in the RSN element but does not have not a Diffie-Hellman Parameter element.
RSN元素中的AKM，但没有Diffie-Hellman参数元素。
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（19），即256位椭圆曲线组。如果AP不支持接收到的802.11关联请求中指示的组，则它必须使用状态代码为七十七（77）的802.11关联响应进行响应，该状态代码表示不支持的有限循环组。接收到状态代码为77的802.11关联响应的客户端应与其他受支持的组重试，并且由于802.11关联的不安全性质，可能会使用导致失败的组再次请求关联。应记录此失败，如果客户由于未能就任何组达成一致而放弃关联，则应向用户提供此事实的通知。
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，exclusive（即1<元素<p-1）小一（1）到一（1）之间。接收到的Diffie-Hellman密钥无效，必须导致关联失败、欠费失败和802.11状态机重置。由于802.11关联的不安全性质，客户端应重试多次（此备忘录未指定次数）。应记录此故障，如果客户端由于（重复）接收无效元素而放弃关联，则应向用户提供此事实的通知。
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的if-client，client的if-AP）公钥Y，将生成以下内容：
z = F(DH(x, Y))
z = F(DH(x, Y))
prk = HKDF-extract(C | A | group, z)
prk=HKDF提取物（C | A |组，z）
PMK = HKDF-expand(prk, "OWE Key Generation", n)
PMK=HKDF扩展（prk，“欠密钥生成”，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
其中[RFC5869]中定义了HKDF-expand（）和HKDF-extract（）；“C | A |组”是客户机的Diffie-Hellman公钥、AP的Diffie-Hellman公钥（分别来自802.11关联请求和响应）以及Diffie-Hellman参数元素的两个八位组（以小端格式）的串联，并且是
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.
使用第4.1节中定义的哈希算法，作为salt传递给基于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是通过哈希两个Diffie-Hellman公钥（从802.11关联请求和响应中Diffie-Hellman参数元素的“公钥”部分发送和接收的数据）并返回最左边的128位生成的：
PMKID = Truncate-128(Hash(C | A))
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公钥，哈希是第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 | |
+---------+--------------+----------+-------+------------+----------+
+---------+--------------+----------+-------+------------+----------+
| 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路握手生成密钥加密密钥（KEK）、密钥确认密钥（KCK）和消息完整性代码（MIC），用于保护定义4路握手的帧。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向握手失败，则应向用户提供此信息。
[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缓存”，其中客户端和接入点可以将PMK缓存一段时间，并在后续关联后通过4路握手重新使用，以绕过潜在的昂贵身份验证。客户端通过在其802.11关联请求中包含标识PMKID来表示其希望进行“PMK缓存”。如果AP缓存了由该PMKID标识的PMK，则它将该PMKID包括在其802.11关联响应中；否则，它将忽略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.
由于传递Diffie-Hellman参数元素时在同一帧中指示“PMK缓存”，因此希望执行“PMK缓存”的客户端必须在其802.11关联请求中同时包含这两个元素。如果AP具有由PMKID标识的PMK并希望执行“PMK缓存”，则AP将在其802.11关联响应中包括PMKID，但不包括Diffie-Hellman参数元素。如果AP没有PMKID标识的PMK，它将忽略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缓存”时，客户端应忽略802.11关联响应中的任何Diffie-Hellman参数元素，该响应的PMKID与客户端发出的802.11关联请求的PMKID匹配。如果802.11关联响应不包括PMKID，或者如果PMKID与客户端发出的802.11关联请求不匹配，则客户端应继续正常关联。
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。
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“开放”身份验证的替代品。因此，当发现符合条件的接入点时，向用户显示可用SSID时不应包括特殊的安全符号，如“锁定图标”。对于用户而言，欠下的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
当OWE最初部署为使用“开放”身份验证或共享和公共PSK的现有网络的替代品时，将需要创建额外的基本服务集
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.
标识符（BSSID）或具有单独服务集标识符（SSID）的新扩展服务集（ESS），以便在同一接入点上可以存在两个不同的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.
机会加密不提供身份验证。客户端将没有访问点的身份验证，反之亦然。它们将共享成对流量加密密钥，并有一个加密保证，即声称来自对等方的帧实际上来自对等方，并且在传输过程中未被修改。
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信息技术标准——系统局域网和城域网之间的电信和信息交换——具体要求——第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准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，“转换类型4-Diffie-Hellman组转换ID”<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，“基本椭圆曲线密码算法”，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（编辑）美国加利福尼亚州圣克拉拉斯科特大道3333号惠普企业95054
Phone: +1 415 555 1212
Email: dharkins@arubanetworks.com
Phone: +1 415 555 1212
Email: dharkins@arubanetworks.com
Warren Kumari (editor) Google 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America
Warren Kumari（编辑）谷歌1600圆形剧场公园路山景，加利福尼亚94043美利坚合众国
Phone: +1 408 555 1212
Email: warren@kumari.net
Phone: +1 408 555 1212
Email: warren@kumari.net