Device Pairing Using Short Authentication Strings
draft-ietf-dnssd-pairing-03

Versions: (draft-kaiser-dnssd-pairing)  00 01 02         Standards Track
          03                                                            
Network Working Group                                         C. Huitema
Internet-Draft                                      Private Octopus Inc.
Intended status: Standards Track                               D. Kaiser
Expires: March 14, 2018                           University of Konstanz
                                                      September 10, 2017


           Device Pairing Using Short Authentication Strings
                      draft-ietf-dnssd-pairing-03

Abstract

   This document proposes a device pairing mechanism that establishes a
   relation between two devices by agreeing on a secret and manually
   verifying the secret's authenticity using an SAS (short
   authentication string).  Pairing has to be performed only once per
   pair of devices, as for a re-discovery at any later point in time,
   the exchanged secret can be used for mutual authentication.

   The proposed pairing method is suited for each application area where
   human operated devices need to establish a relation that allows
   configurationless and privacy preserving re-discovery at any later
   point in time.  Since privacy preserving applications are the main
   suitors, we especially care about privacy.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 14, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Huitema & Kaiser         Expires March 14, 2018                 [Page 1]


Internet-Draft               Device Pairing               September 2017


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Document Organization . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   4
     2.1.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Agreement on a Shared Secret  . . . . . . . . . . . . . .   5
     2.3.  Authentication  . . . . . . . . . . . . . . . . . . . . .   6
   3.  Optional Use of QR Codes  . . . . . . . . . . . . . . . . . .   8
     3.1.  Discovery Using QR Codes  . . . . . . . . . . . . . . . .   8
     3.2.  Agreement with QR Codes . . . . . . . . . . . . . . . . .   9
     3.3.  Authentication with QR Codes  . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   To engage in secure and privacy preserving communication, hosts need
   to differentiate between authorized peers, which must both know about
   the host's presence and be able to decrypt messages sent by the host,
   and other peers, which must not be able to decrypt the host's
   messages and ideally should not obtain information that could be used
   to identify the host.  The necessary relation between host and peer
   can be established by a centralized service, e.g. a certificate
   authority, by a web of trust, e.g.  PGP, or -- without using global
   identities -- by device pairing.

   This document proposes a device pairing mechanism that provides human
   operated devices with pairwise authenticated secrets, allowing mutual
   automatic re-discovery at any later point in time along with mutual
   private authentication.  We especially care about privacy and user-




Huitema & Kaiser         Expires March 14, 2018                 [Page 2]


Internet-Draft               Device Pairing               September 2017


   friendliness.  This pairing system can provide the pairing secrets
   used in DNSSD Privacy Extensions [I-D.ietf-dnssd-privacy].

   The proposed pairing mechanism consists of three steps needed to
   establish a relationship between a host and a peer:

   1.  Discovering the peer device.  The host needs a means to discover
       network parameters necessary to establish a connection to the
       peer.  During this discovery process, neither the host nor the
       peer must disclose its presence.

   2.  Agreeing on pairing data.  The devices have to agree on pairing
       data, which can be used by both parties at any later point in
       time to generate identifiers for re-discovery and to prove the
       authenticity of the pairing.  The pairing data can e.g. be a
       shared secret agreed upon via a Diffie-Hellman key exchange.

   3.  Authenticating pairing data.  Since in most cases the messages
       necessary to agree upon pairing data are send over an insecure
       channel, means that guarantee the authenticity of these messages
       are necessary; otherwise the pairing data is in turn not suited
       as a means for a later proof of authenticity.  For the proposed
       pairing mechanism we use manual authentication involving an SAS
       (short authentication string) to proof the authenticity of the
       pairing data.

   The design of this protocol is based on the analysis of pairing
   protocols issues presented in [I-D.ietf-dnssd-pairing-info] and in
   [K17].

   Many pairing scenarios involve cell phones equipped with cameras
   capable of reading a QR code.  In these scenarios, scanning QR codes
   might be more user friendly than selecting names or reading short
   authentication strings from on screen menus.  An optional use of QR
   codes in pairing protocols is presented is Section 3.

1.1.  Requirements

   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 [RFC2119].

1.2.  Document Organization

   NOTE TO RFC EDITOR: remove or rewrite this section before
   publication.





Huitema & Kaiser         Expires March 14, 2018                 [Page 3]


Internet-Draft               Device Pairing               September 2017


   The original version of this document was organized in two parts.
   The first part presented the pairing need, the list of requirements
   that shall be met.  This first part was informational in nature.  The
   second part composed the actual specification of the protocol.

   In his early review, Steve Kent observed that the style of the first
   part seems inappropriate for a standards track document, and
   suggested that the two parts should be split into two documents, the
   first part becoming an informational document, and the second
   focusing on standard track specification of the protocol, making
   reference to the informational document as appropriate.

   The DNS-SD working group approved this split during its meeting in
   Prague in July 2017.  This version of the document implements the
   split, only retaining the specification part.

2.  Protocol Specification

   In the proposed pairing protocol, we will consider the device that
   initiates the pairing as the "client" and the device that responds as
   the "server".  The server will publish a "pairing service".  The
   client will discover the service instance during the discovery phase,
   as explained in Section 2.1.  The pairing service itself is specified
   in Section 2.3.

   We divide pairing in three parts: discovery, agreement, and
   authentication, detailed in the following subsections.

2.1.  Discovery

   The goal of the discovery phase is establishing a connection, which
   is later used to exchange the pairing data between the two devices
   that are about to be paired in an IP network without any prior
   knowledge and without publishing any private information.

   When the pairing service starts, the server will advertise the
   pairing service according to DNS-SD [RFC6763] over mDNS [RFC6762].
   In conformance with DNS-SD, the service is described by an SRV record
   and by and empty TXT record.  These records will be organized as
   follows:

   1.  The pairing service is identified in DNS-SD as "_pairing._tcp".

   2.  The instance name will be a text chosen by the server.  It MAY be
       a random string if the server does not want to advertise its
       identity in the local environment, or the user friendly name of
       the server in other cases.




Huitema & Kaiser         Expires March 14, 2018                 [Page 4]


Internet-Draft               Device Pairing               September 2017


   3.  The priority and weight fields of the SRV record SHOULD be set
       according to [RFC6763].

   4.  The host name MUST be set to the host name advertised by the
       server in mDNS.  The server MAY use a randomized host name as
       explained in [I-D.ietf-dnssd-privacy], provided that this name is
       properly published in mDNS.

   5.  The port number MUST be set to the number at which the server is
       listening for the pairing service.  This port number SHOULD be
       randomly picked by the server.

   The discovery proceeds as follows:

   1.  The server advertises an instance of the above described pairing
       service and displays its instance name on the server's screen.

   2.  The client discovers all the instances of the pairing service
       available on the local network.  This may result in the discovery
       of several instance names.

   3.  Among these available instance names, the client's user selects
       the name that matches the name displayed by the server.

   4.  Per DNS-SD, the client then retrieves the SRV record of the
       selected instance, retrieves the corresponding server's A (or
       AAAA) record, and establishes the connection.

2.2.  Agreement on a Shared Secret

   Once the server has been selected at the end of the discovery phase,
   the client connects to it without further user intervention.  Client
   and server use this connection for exchanging data that allows them
   to agree on a shared secret by using TLS and a key exporter.

   Devices implementing the service MUST support TLS 1.2 [RFC5246], and
   MAY negotiate TLS 1.3 when it becomes available.  When using TLS, the
   client and server MUST negotiate a ciphersuite providing forward
   secrecy (PFS), and strong encryption (256 bits symmetric key).  All
   implementations using TLS 1.2 MUST be able to negotiate the cipher
   suite TLS_DH_anon_WITH_AES_256_CBC_SHA256.

   Once the TLS connection has been established, each party extracts the
   pairing secret S_p from the connection context per [RFC5705], using
   the following parameters:

   Disambiguating label string:  "PAIRING SECRET"




Huitema & Kaiser         Expires March 14, 2018                 [Page 5]


Internet-Draft               Device Pairing               September 2017


   Context value:  empty.

   Length value:  32 bytes (256 bits).

   The secret "S_p" will be authenticated in the authentication part of
   the protocol.

2.3.  Authentication

   The pairing protocol implemented on top of TLS allows the users to
   authenticate the shared secret established in the "Agreement" phase,
   and to minimize the risk of interference by a third party like a
   "man-in-the-middle".  The pairing protocol is built using TLS.  The
   following description uses the presentation language defined in
   section 4 of [RFC5246].  The protocol uses five message types,
   defined in the following enum:

   enum {
      ClientHash(1),
      ServerRandom(2),
      ClientRandom(3),
      ServerSuccess(4),
      ClientSuccess(5)
   } PairingMessageType;

   Once S_p has been obtained, the client picks a random number R_c,
   exactly 32 bytes long.  The client then selects a hash algorithm,
   which MUST be the same algorithm as negotiated for building the PRF
   in the TLS connection.  The client then computes the hash value H_c
   as:

      H_c = HMAC_hash(S_p, R_c)

      Where "HMAC_hash" is the HMAC function constructed with the
      selected algorithm.

   The client transmits the selected hash function and the computed
   value of H_c in the Client Hash message, over the TLS connection:

   struct {
      PairingMessageType messageType;
      hashAlgorithm hash;
      uint8 hashLength;
      opaque H_c[hashLength];
   } ClientHashMessage;

   messageType:  Set to "ClientHash".




Huitema & Kaiser         Expires March 14, 2018                 [Page 6]


Internet-Draft               Device Pairing               September 2017


   hash: The code of the selected hash algorithm, per definition of
         HashAlgorithm in section 7.4.1.1.1 of [RFC5246].

   hashLength:  The length of the hash H_c, which MUST be consistent
         with the selected algorithm "hash".

   H_c:  The value of the client hash.

   Upon reception of this message, the server stores its value.  The
   server picks a random number R_s, exactly 32 bytes long, and
   transmits it to the client in the server random message, over the TLS
   connection:

   struct {
      PairingMessageType messageType;
      opaque R_s[32];
   } ServerRandomMessage;

   messageType  Set to "ServerRandom".

   R_s:  The value of the random number chosen by the server.

   Upon reception of this message, the client discloses its own random
   number by transmitting the client random message:

   struct {
      PairingMessageType messageType;
      opaque R_c[32];
   } ClientRandomMessage;

   messageType  Set to "ClientRandom".

   R_c:  The value of the random number chosen by the client.

   Upon reception of this message, the server verifies that the number
   R_c hashes to the previously received value H_c.  If the number does
   not match, the server MUST abandon the pairing attempt and abort the
   TLS connection.

   At this stage, both client and server can compute the short hash SAS
   as:

      SAS = first 20 bits of HMAC_hash(S_p, R_c || R_s)

      Where "HMAC_hash" is the HMAC function constructed with the hash
      algorithm selected by the client in the ClientHashMessage.





Huitema & Kaiser         Expires March 14, 2018                 [Page 7]


Internet-Draft               Device Pairing               September 2017


   Both client and server display the SAS as a 7 digit decimal integer,
   including leading zeroes, and ask the user to compare the values.  If
   the SASes match, each user enters an agreement, for example by
   pressing a button labeled "OK", which results in the pairing being
   remembered.  If they do not match, each user should cancel the
   pairing, for example by pressing a button labeled "CANCEL".

   If the values do match and both users agree, the protocol continues
   with the exchange of names, both server and client announcing their
   own preferred name in a Success message

   struct {
      PairingMessageType messageType;
      uint8 nameLength;
      opaque name[nameLength];
   } ClientSuccessMessage;

   messageType:  Set to "ClientSuccess" if transmitted by the client,
         "ServerSuccess" if by the server.

   nameLength:  The length of the string encoding the selected name.

   name: The selected name of the client or the server, encoded as a
         string of UTF8 characters.

   After receiving these messages, client and servers can orderly close
   the TLS connection, terminating the pairing exchange.

3.  Optional Use of QR Codes

   When QR codes are supported, the discovery process can be independent
   of DNS-SD, because QR codes allow the transmission of a sufficient
   amount of data.  The agreement process can also be streamlined by the
   scanning of a second QR code.

3.1.  Discovery Using QR Codes

   If QR code scanning is available as out-of-band channel, the
   discovery data is directly transmitted via QR codes instead of DNS-SD
   over mDNS.  Leveraging QR codes, the discovery proceeds as follows:

   1.  The server displays a QR code containing the connection data
       otherwise found in the SRV and A or AAAA records: IPv4 or IPv6
       address, port number, and optionally host name.

   2.  The client scans the QR code retrieving the necessary information
       for establishing a connection to the server.




Huitema & Kaiser         Expires March 14, 2018                 [Page 8]


Internet-Draft               Device Pairing               September 2017


   [[TODO: We should precisely specify the data layout of this QR code.
   It could either be the wire format of the corresponding resource
   records (which would be easier for us), or a more efficient
   representation.  If we chose the wire format, we could use a fixed
   name as instance name.]]

3.2.  Agreement with QR Codes

   When QR codes are available, the agreement on a shared secret
   proceeds exactly as in the general case.

3.3.  Authentication with QR Codes

   The availability of QR codes does not change the required network
   messages or the computation of the SAS, which will performed exactly
   as specified in Section 2.3, but when QR codes are supported, the SAS
   may also be represented as QR code.

   In the general case, both client and server display the SAS as a
   decimal integer, and ask the user to compare the values.  If the
   server supports QR codes, the server displays a QR code encoding the
   decimal string representation of the SAS.  If the client is capable
   of scanning QR codes, it may scan the value and compare it to the
   locally computed value.

   Once user agreement has been obtained, the protocol continues as in
   the general case presented in Section 2.3.

4.  Security Considerations

   We need to consider two types of attacks against a pairing system:
   attacks that occur during the establishment of the pairing relation,
   and attacks that occur after that establishment.

   During the establishment of the pairing system, we are concerned with
   privacy attacks and with MitM attacks.  Privacy attacks reveal the
   existence of a pairing between two devices, which can be used to
   track graphs of relations.  MitM attacks result in compromised
   pairing keys.  The discovery procedures specified in Section 2.1 and
   the authentication procedures specified in Section 2.3 are
   specifically designed to mitigate such attacks, assuming that the
   client and user are in close, physical proximity and thus a human
   user can visually acquire and verify the pairing information.

   The establishment of the pairing results in the creation of a shared
   secret.  After the establishment of the pairing relation, attackers
   who compromise one of the devices could access the shared secret.
   This will enable them to either track or spoof the devices.  To



Huitema & Kaiser         Expires March 14, 2018                 [Page 9]


Internet-Draft               Device Pairing               September 2017


   mitigate such attacks, nodes MUST store the secret safely, and MUST
   be able to quickly revoke a compromised pairing.

5.  IANA Considerations

   This draft does not require any IANA action.

6.  Acknowledgments

   We would like to thank Steve Kent and Ted Lemon for their detailed
   reviews of this document, and for their advice on how to improve it.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
              March 2010, <https://www.rfc-editor.org/info/rfc5705>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

7.2.  Informative References

   [I-D.ietf-dnssd-pairing-info]
              Kaiser, D. and C. Huitema, "Device Pairing Design Issues",
              draft-ietf-dnssd-pairing-info-00 (work in progress),
              September 2017.







Huitema & Kaiser         Expires March 14, 2018                [Page 10]


Internet-Draft               Device Pairing               September 2017


   [I-D.ietf-dnssd-privacy]
              Huitema, C. and D. Kaiser, "Privacy Extensions for DNS-
              SD", draft-ietf-dnssd-privacy-02 (work in progress), July
              2017.

   [K17]      Kaiser, D., "Efficient Privacy-Preserving
              Configurationless Service Discovery Supporting Multi-Link
              Networks", 2017,
              <http://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.

Authors' Addresses

   Christian Huitema
   Private Octopus Inc.
   Friday Harbor, WA  98250
   U.S.A.

   Email: huitema@huitema.net


   Daniel Kaiser
   University of Konstanz
   Konstanz  78457
   Germany

   Email: daniel.kaiser@uni-konstanz.de

























Huitema & Kaiser         Expires March 14, 2018                [Page 11]