1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>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
<span class="h1">Opportunistic Wireless Encryption</span>
Abstract
This memo specifies an extension to IEEE Std 802.11 to provide for
opportunistic (unauthenticated) encryption to the wireless media.
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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc8110">http://www.rfc-editor.org/info/rfc8110</a>.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Harkins & Kumari Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Notation . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Background . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. 802.11 Network Access . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Opportunistic Wireless Encryption . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Cryptography . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. OWE Discovery . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. OWE Association . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.4">4.4</a>. OWE Post-Association . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.5">4.5</a>. OWE PMK Caching . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5">5</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Implementation Considerations . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="grey">Harkins & Kumari Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This memo describes Opportunistic Wireless Encryption (OWE) -- a mode
of opportunistic security [<a href="./rfc7435" title=""Opportunistic Security: Some Protection Most of the Time"">RFC7435</a>] for IEEE Std 802.11 that provides
encryption of the wireless medium but no authentication.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Notation</span>
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.
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.
a = len(b)
Indicates the length in bits of the string b.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background</span>
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.
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
<span class="grey">Harkins & Kumari Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
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
[<a href="#ref-IEEE802.11">IEEE802.11</a>], called the "4-way handshake" to prove knowledge of the
PSK and derive traffic encryption keys for bulk wireless data.
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.
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 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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. 802.11 Network Access</span>
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 [<a href="#ref-IEEE802.11">IEEE802.11</a>]. 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.
<span class="grey">Harkins & Kumari Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
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.
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.
To add an opportunistic encryption mode of access to [<a href="#ref-IEEE802.11">IEEE802.11</a>], 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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Opportunistic Wireless Encryption</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Cryptography</span>
Performing a Diffie-Hellman key exchange requires agreement on a
domain parameter set in which to perform the exchange. OWE uses a
registry (see [<a href="#ref-IKE-IANA" title=""Transform Type 4 - Diffie-Hellman Group Transform IDs"">IKE-IANA</a>]) to map an integer into a complete domain
parameter set. OWE supports both Elliptic Curve Cryptography (ECC)
and Finite Field Cryptography (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:
o SHA-256: when len(p) <= 256
o SHA-384: when 256 < len(p) <= 384
o SHA-512: when 384 < len(p)
<span class="grey">Harkins & Kumari Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
For FFC, the hash algorithm depends on the prime, p, defining the
finite field:
o SHA-256: when len(p) <= 2048
o SHA-384: when 2048 < len(p) <= 3072
o SHA-512: when 3072 < len(p)
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. OWE Discovery</span>
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 [<a href="#ref-IEEE802.11">IEEE802.11</a>], in all beacons and probe
response frames the AP issues.
+----------+--------+-------------------+-------------+-------------+
| OUI | Suite | Authentication | Key | Key |
| | Type | Type | Management | derivation |
| | | | Type | type |
+----------+--------+-------------------+-------------+-------------+
| 00-0F-AC | 18 | Opportunistic | This | [<a href="./rfc5869" title=""HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"">RFC5869</a>] |
| | | Wireless | document | |
| | | Encryption | | |
+----------+--------+-------------------+-------------+-------------+
Table 1: OWE AKM
Once a client discovers an OWE-compliant AP, it performs "Open
System" 802.11 authentication as defined in [<a href="#ref-IEEE802.11">IEEE802.11</a>], and it then
proceeds to 802.11 association.
<span class="grey">Harkins & Kumari Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. OWE Association</span>
Information is added to 802.11 association requests and responses
using TLVs that [<a href="#ref-IEEE802.11">IEEE802.11</a>] 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.
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.
+------------+----------+------------+------------------------+
| Element ID | Length | Element ID | element-specific |
| | | Extension | data |
+------------+----------+------------+---------+--------------+
| 255 | variable | 32 | group | public key |
+------------+----------+------------+---------+--------------+
Figure 1: The Diffie-Hellman Parameter Element
where:
o group is an unsigned two-octet integer defined in [<a href="#ref-IKE-IANA" title=""Transform Type 4 - Diffie-Hellman Group Transform IDs"">IKE-IANA</a>], in
little-endian format, that identifies a domain parameter set;
o public key is an octet string representing the Diffie-Hellman
public key; and,
o Element ID, Length, and Element ID Extension are all single-octet
integers.
The encoding of the public key depends on its type. FFC elements
SHALL be encoded per the integer-to-octet-string conversion technique
of [<a href="./rfc6090" title=""Fundamental Elliptic Curve Cryptography Algorithms"">RFC6090</a>]. For ECC elements, the encoding depends on the
definition of the curve, either that in [<a href="./rfc6090" title=""Fundamental Elliptic Curve Cryptography Algorithms"">RFC6090</a>] or [<a href="./rfc7748" title=""Elliptic Curves for Security"">RFC7748</a>]. If
the public key is from a curve defined in [<a href="./rfc6090" title=""Fundamental Elliptic Curve Cryptography Algorithms"">RFC6090</a>], compact
representation SHALL be used.
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
<a href="#section-4.5">Section 4.5</a>) 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
<span class="grey">Harkins & Kumari Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
AKM in the RSN element but does not have not a Diffie-Hellman
Parameter element.
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.
Received Diffie-Hellman Parameter elements are checked for validity
upon receipt. For ECC, a validity check depends on the curve
definition, either that in [<a href="./rfc6090" title=""Fundamental Elliptic Curve Cryptography Algorithms"">RFC6090</a>] or [<a href="./rfc7748" title=""Elliptic Curves for Security"">RFC7748</a>]. 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.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. OWE Post-Association</span>
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 [<a href="#ref-IEEE802.11">IEEE802.11</a>]. Given a
private key x and the peer's (AP's if client, client's if AP) public
key Y, the following are generated:
z = F(DH(x, Y))
prk = HKDF-extract(C | A | group, z)
PMK = HKDF-expand(prk, "OWE Key Generation", n)
where HKDF-expand() and HKDF-extract() are defined in [<a href="./rfc5869" title=""HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"">RFC5869</a>]; "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
<span class="grey">Harkins & Kumari Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
passed as the salt to the HMAC-based Extract-and-Expand Key
Derivation Function (HKDF) using the hash algorithm defined in
<a href="#section-4.1">Section 4.1</a>; 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.
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 = 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 <a href="#section-4.1">Section 4.1</a>.
+---------+--------------+----------+-------+------------+----------+
| 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
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 <a href="#section-4.1">Section 4.1</a> and are listed in Table 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.
<span class="grey">Harkins & Kumari Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. OWE PMK Caching</span>
[<a id="ref-IEEE802.11">IEEE802.11</a>] 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".
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.
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.
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This document does not require any IANA actions.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Implementation Considerations</span>
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.
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
<span class="grey">Harkins & Kumari Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
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 [<a href="#ref-IEEE802.11">IEEE802.11</a>]). This
arrangement should remain until the majority of users have switched
over to OWE.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
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 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 is not a replacement for any authentication protocol specified in
[<a href="#ref-IEEE802.11">IEEE802.11</a>] and is not intended to be used when an alternative that
provides real authentication is available.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-IEEE802.11">IEEE802.11</a>]
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.
[<a id="ref-IKE-IANA">IKE-IANA</a>] IANA, "Transform Type 4 - Diffie-Hellman Group Transform
IDs", <<a href="http://www.iana.org/assignments/ikev2-parameters/">http://www.iana.org/assignments/ikev2-parameters/</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
<span class="grey">Harkins & Kumari Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8110">RFC 8110</a> Opportunistic Wireless Encryption March 2017</span>
[<a id="ref-RFC5869">RFC5869</a>] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", <a href="./rfc5869">RFC 5869</a>,
DOI 10.17487/RFC5869, May 2010,
<<a href="http://www.rfc-editor.org/info/rfc5869">http://www.rfc-editor.org/info/rfc5869</a>>.
[<a id="ref-RFC6090">RFC6090</a>] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", <a href="./rfc6090">RFC 6090</a>,
DOI 10.17487/RFC6090, February 2011,
<<a href="http://www.rfc-editor.org/info/rfc6090">http://www.rfc-editor.org/info/rfc6090</a>>.
[<a id="ref-RFC7748">RFC7748</a>] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", <a href="./rfc7748">RFC 7748</a>, DOI 10.17487/RFC7748, January
2016, <<a href="http://www.rfc-editor.org/info/rfc7748">http://www.rfc-editor.org/info/rfc7748</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC7435">RFC7435</a>] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", <a href="./rfc7435">RFC 7435</a>, DOI 10.17487/RFC7435,
December 2014, <<a href="http://www.rfc-editor.org/info/rfc7435">http://www.rfc-editor.org/info/rfc7435</a>>.
Authors' Addresses
Dan Harkins (editor)
HP Enterprise
3333 Scott Boulevard
Santa Clara, California 95054
United States of America
Phone: +1 415 555 1212
Email: dharkins@arubanetworks.com
Warren Kumari (editor)
Google
1600 Amphitheatre Parkway
Mountain View, California 94043
United States of America
Phone: +1 408 555 1212
Email: warren@kumari.net
Harkins & Kumari Informational [Page 12]
</pre>
|
