Publicly Verifiable Nominations Committee (NomCom) Random Selection
RFC 3797

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&"Pool too big.\n" );
        exit ( 1 );
        }
    selected = (unsigned short *) malloc ( (size_t)pool );
    if ( !selected )
        {
        printf ( "Out of memory.\n" );
        exit ( 1 );
        }
    selection = getinteger ( "Type number of items to be selected:\n" );
    if ( selection > pool )
        {
        printf ( "Pool too small.\n" );
        exit ( 1 );
        }
    if ( selection == pool )
        printf ( "All of the pool is selected.\n" );
    else
        {
        err = printf ( "Approximately %.1f bits of entropy needed.\n",
                        NPentropy ( selection, pool ) + 0.1 );
        if ( err <= 0 ) exit ( 1 );
        }
    for ( i = 0, keysize = 0; i < 16; ++i )
        {
        if ( keysize > 500 )
            {
            printf ( "Too much input.\n" );
            exit ( 1 );
            }
        /* get the "random" inputs. echo back to user so the user may
           be able to tell if truncation or other glitches occur.  */
        err = printf (
            "\nType #%d randomness or 'end' followed by new line.\n"
            "Up to 16 integers or the word 'float' followed by up\n"
            "to 16 x.y format reals.\n", i+1 );
        if ( err <= 0 ) exit ( 1 );
        gets ( buffer );

Eastlake 3rd                 Informational                     [Page 11]
RFC 3797              Verifiable Random Selection              June 2004

        j = sscanf ( buffer,
                "%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld",
            &array[0], &array[1], &array[2], &array[3],
            &array[4], &array[5], &array[6], &array[7],
            &array[8], &array[9], &array[10], &array[11],
            &array[12], &array[13], &array[14], &array[15] );
        if ( j == EOF )
            exit ( j );
        if ( !j )
            if ( buffer[0] == 'e' )
                break;

            else
                {   /* floating point code by Matt Crawford */
                j = sscanf ( buffer,
                    "float %ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
                    "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
                    "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
                    "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]",
                    &array[0], sarray[0], &array[1], sarray[1],
                    &array[2], sarray[2], &array[3], sarray[3],
                    &array[4], sarray[4], &array[5], sarray[5],
                    &array[6], sarray[6], &array[7], sarray[7],
                    &array[8], sarray[8], &array[9], sarray[9],
                    &array[10], sarray[10], &array[11], sarray[11],
                    &array[12], sarray[12], &array[13], sarray[13],
                    &array[14], sarray[14], &array[15], sarray[15] );
                if ( j == 0 || j & 1 )
                    printf ( "Bad format." );
                else {
                     for ( k = 0, j /= 2; k < j; k++ )
                     {
                           /* strip trailing zeros */
                     for ( k2=strlen(sarray[k]); sarray[k][--k2]=='0';)
                           sarray[k][k2] = '\0';
                     err = printf ( "%ld.%s\n", array[k], sarray[k] );
                     if ( err <= 0 ) exit ( 1 );
                     keysize += sprintf ( &key[keysize], "%ld.%s",
                                          array[k], sarray[k] );
                     }
                     keysize += sprintf ( &key[keysize], "/" );
                     }
                }
        else
            {   /* sort values, not a very efficient algorithm */
            for ( k2 = 0; k2 < j - 1; ++k2 )
                for ( k = 0; k < j - 1; ++k )
                    if ( array[k] > array[k+1] )

Eastlake 3rd                 Informational                     [Page 12]
RFC 3797              Verifiable Random Selection              June 2004

                        {
                        temp = array[k];
                        array[k] = array[k+1];
                        array[k+1] = temp;
                        }
            for ( k = 0; k < j; ++k )
                { /* print for user check */
                err = printf ( "%ld ", array[k] );
                if ( err <= 0 ) exit ( 1 );
                keysize += sprintf ( &key[keysize], "%ld.", array[k] );
                }
            keysize += sprintf ( &key[keysize], "/" );
            }
        }   /* end for i */

    /* have obtained all the input, now produce the output */
    err = printf ( "Key is:\n %s\n", key );
    if ( err <= 0 ) exit ( 1 );
    for ( i = 0; i < pool; ++i )
        selected [i] = (unsigned short)(i + 1);
    printf ( "index        hex value of MD5        div  selected\n" );
    for (   usel = 0, remaining = (unsigned short)pool;
            usel < selection;
            ++usel, --remaining )
        {
        unch1 = (unsigned char)usel;
        unch2 = (unsigned char)(usel>>8);
        /* prefix/suffix extended to 2 bytes by Donald Eastlake */
        MD5Init ( &ctx );
        MD5Update ( &ctx, &unch2, 1 );
        MD5Update ( &ctx, &unch1, 1 );
        MD5Update ( &ctx, (unsigned char *)key, keysize );
        MD5Update ( &ctx, &unch2, 1 );
        MD5Update ( &ctx, &unch1, 1 );
        MD5Final ( uc16, &ctx );
        k = longremainder ( remaining, uc16 );
    /* printf ( "Remaining = %d, remainder = %d.\n", remaining, k ); */
        for ( j = 0; j < pool; ++j )
            if ( selected[j] )
                if ( --k < 0 )
                    {
                    printf ( "%2d  "
    "%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X  "
    "%2d  -> %2d <-\n",
    usel+1, uc16[0],uc16[1],uc16[2],uc16[3],uc16[4],uc16[5],uc16[6],
    uc16[7],uc16[8],uc16[9],uc16[10],uc16[11],uc16[12],uc16[13],
    uc16[14],uc16[15], remaining, selected[j] );
                    selected[j] = 0;

Eastlake 3rd                 Informational                     [Page 13]
RFC 3797              Verifiable Random Selection              June 2004

                    break;
                    }
        }
     printf ( "\nDone, type any character to exit.\n" );
     getchar ();
     return 0;
     }

     /* prompt for a positive non-zero integer input */
     /****************************************************************/
     long int getinteger ( char *string )
     {
     long int     i;
     int          j;
     char    tin[257];

     while ( 1 )
     {
     printf ( string );
     printf ( "(or 'exit' to exit) " );
     gets ( tin );
     j = sscanf ( tin, "%ld", &i );
     if (    ( j == EOF )

         ||  ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) )
             )
         exit ( j );
     if ( ( j == 1 ) &&
          ( i > 0 ) )
         return i;
     }   /* end while */
     }

     /* get remainder of dividing a 16 byte unsigned int
        by a small positive number */
     /****************************************************************/
     int longremainder ( unsigned short divisor,
                         unsigned char dividend[16] )
     {
     int i;
     long int kruft;

     if ( !divisor )
         return -1;
     for ( i = 0, kruft = 0; i < 16; ++i )
         {
         kruft = ( kruft << 8 ) + dividend[i];
         kruft %= divisor;

Eastlake 3rd                 Informational                     [Page 14]
RFC 3797              Verifiable Random Selection              June 2004

         }
     return kruft;
     }   /* end longremainder */

    /* calculate how many bits of entropy it takes to select N from P */
    /****************************************************************/
    /*             P!
      log  ( ----------------- )
         2    N! * ( P - N )!
    */

    double NPentropy ( int N, int P )
    {
    int         i;
    double      result = 0.0;

    if (    ( N < 1 )   /* not selecting anything? */
       ||   ( N >= P )  /* selecting all of pool or more? */
       )
        return 0.0;     /* degenerate case */
    for ( i = P; i > ( P - N ); --i )
        result += log ( i );
    for ( i = N; i > 1; --i )
        result -= log ( i );
    /* divide by [ log (base e) of 2 ] to convert to bits */
    result /= 0.69315;

    return result;
    }   /* end NPentropy */

Eastlake 3rd                 Informational                     [Page 15]
RFC 3797              Verifiable Random Selection              June 2004

Appendix A: History of NomCom Member Selection

   For reference purposes, here is a list of the IETF Nominations
   Committee member selection techniques and chairs so far:

           YEAR      CHAIR               SELECTION METHOD

        1993/1994  Jeff Case             Clergy
        1994/1995  Fred Baker            Clergy
        1995/1996  Guy Almes             Clergy
        1996/1997  Geoff Huston          Spouse
        1997/1998  Mike St.Johns         Algorithm
        1998/1999  Donald Eastlake 3rd   RFC 2777
        1999/2000  Avri Doria            RFC 2777
        2000/2001  Bernard Aboba         RFC 2777
        2001/2002  Theodore Ts'o         RFC 2777
        2002/2003  Phil Roberts          RFC 2777
        2003/2004  Rich Draves           RFC 2777

   Clergy = Names were written on pieces of paper, placed in a
   receptacle, and a member of the clergy picked the NomCom members.

   Spouse = Same as Clergy except chair's spouse made the selection.

   Algorithm = Algorithmic selection based on similar concepts to those
   documented in RFC 2777 and herein.

   RFC 2777 = Algorithmic selection using the algorithm and reference
   code provided in RFC 2777 (but not the fake example sources of
   randomness).

Appendix B: Changes from RFC 2777

   This document differs from [RFC 2777], the previous version, in three
   primary ways as follows:

   (1) Section 5, on problems actually encountered with using these
       recommendations for selecting an IETF NomCom and on how to handle
       them, has been added.

   (2) The selection algorithm code has been modified to handle pools of
       up to 2**16-1 elements and the counter based prefix and suffix
       concatenated with the key string before hashing has been extended
       to two bytes.

   (3) Mention has been added that the algorithm documented herein was
       used by IANA to select the Internationalized Domain Name ACE
       prefix and some minor wording changes made.

Eastlake 3rd                 Informational                     [Page 16]
RFC 3797              Verifiable Random Selection              June 2004

   (4) References have been divided into Informative and Normative.

   (5) The list in Appendix A has been brought up to date.

Acknowledgements

   Matt Crawford and Erik Nordmark made major contributions to this
   document.  Comments by Bernard Aboba, Theodore Ts'o, Jim Galvin,
   Steve Bellovin, and others have been incorporated.

References

Normative References

   [ASCII]    "USA Standard Code for Information Interchange", X3.4,
              American National Standards Institute: New York, 1968.

   [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC 1750] Eastlake, 3rd, D., Crocker, S. and J. Schiller,
              "Randomness Recommendations for Security", RFC 1750,
              December 1994.

   [RFC 3174] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm
              1 (SHA1)", RFC 3174, September 2001.

Informative References

   [RFC 3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
              Recall Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, April 2004.

   [RFC 2777] Eastlake, 3rd, D., "Publicly Verifiable Nomcom Random
              Selection", RFC 2777, February 2000.

   [RFC 3490] Falstrom, P., Hoffman, P. and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

Eastlake 3rd                 Informational                     [Page 17]
RFC 3797              Verifiable Random Selection              June 2004

Author's Address

   Donald E. Eastlake, 3rd
   Motorola Laboratories
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-786-7554(w)
          +1-508-634-2066(h)
   EMail: Donald.Eastlake@motorola.com

Eastlake 3rd                 Informational                     [Page 18]
RFC 3797              Verifiable Random Selection              June 2004

Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Eastlake 3rd                 Informational                     [Page 19]