doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc8110.txt b/doc/rfc/rfc8110.txt
new file mode 100644
index 0000000..43e9806
--- /dev/null
+++ b/doc/rfc/rfc8110.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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, 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
+
+
+
+Harkins & Kumari              Informational                     [Page 3]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+   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.
+
+   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.
+
+3.  802.11 Network Access
+
+   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.
+
+
+
+
+
+
+
+Harkins & Kumari              Informational                     [Page 4]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+   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 [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.
+
+4.  Opportunistic Wireless Encryption
+
+4.1.  Cryptography
+
+   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).
+
+   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)
+
+
+
+
+
+
+
+
+Harkins & Kumari              Informational                     [Page 5]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+   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)
+
+4.2.  OWE Discovery
+
+   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.
+
+   +----------+--------+-------------------+-------------+-------------+
+   |   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
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins & Kumari              Informational                     [Page 6]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+4.3.  OWE Association
+
+   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.
+
+   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 [IKE-IANA], 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 [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.
+
+   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
+
+
+
+Harkins & Kumari              Informational                     [Page 7]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+   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 [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.
+
+4.4.  OWE Post-Association
+
+   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:
+
+      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 [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
+
+
+
+Harkins & Kumari              Informational                     [Page 8]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+   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.
+
+   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 Section 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
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Harkins & Kumari              Informational                     [Page 9]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+4.5.  OWE PMK Caching
+
+   [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".
+
+   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.
+
+5.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+6.  Implementation Considerations
+
+   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
+
+
+
+Harkins & Kumari              Informational                    [Page 10]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+   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.
+
+7.  Security Considerations
+
+   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
+   [IEEE802.11] and is not intended to be used when an alternative that
+   provides real authentication is available.
+
+8.  References
+
+8.1.  Normative References
+
+   [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.
+
+   [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>.
+
+
+
+
+Harkins & Kumari              Informational                    [Page 11]
+
+RFC 8110            Opportunistic Wireless Encryption         March 2017
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+8.2.  Informative References
+
+   [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>.
+
+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]
+