Opportunistic Wireless Encryption
RFC 8110
Document | Type |
RFC - Informational
(March 2017; Errata)
Was draft-harkins-owe (individual in sec area)
|
|
---|---|---|---|
Authors | Dan Harkins , Warren Kumari | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 8110 (Informational) | |
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Stephen Farrell | ||
Send notices to | (None) | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
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. 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. 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. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Harkins & Kumari Informational [Page 1] RFC 8110 Opportunistic Wireless Encryption March 2017 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 Harkins & Kumari Informational [Page 2] RFC 8110 Opportunistic Wireless Encryption March 2017 1. Introduction 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. 1.1. Requirements Language 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]. 1.2. Notation 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. 2. Background 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, becauseShow full document text