Device Pairing Using Short Authentication Strings

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-friendliness. This pairing system can provide the pairing secrets used in DNSSD Privacy Extensions . The proposed pairing mechanism consists of three steps needed to establish a relationship between a host and a peer: 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. 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. 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 and in . 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 .

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 .

NOTE TO RFC EDITOR: remove or rewrite this section before publication. 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.

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 . The pairing service itself is specified in . We divide pairing in three parts: discovery, agreement, and authentication, detailed in the following subsections.

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 over mDNS . 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: The pairing service is identified in DNS-SD as "_pairing._tcp". 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. The priority and weight fields of the SRV record SHOULD be set according to . 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 , provided that this name is properly published in mDNS. 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: The server advertises an instance of the above described pairing service and displays its instance name on the server's screen. 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. Among these available instance names, the client's user selects the name that matches the name displayed by the server. 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.

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 , 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 , using the following parameters: "PAIRING SECRET" empty. 32 bytes (256 bits). The secret "S_p" will be authenticated in the authentication part of the protocol.

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 . 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; Set to "ClientHash". The code of the selected hash algorithm, per definition of HashAlgorithm in section 7.4.1.1.1 of . The length of the hash H_c, which MUST be consistent with the selected algorithm "hash". 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; Set to "ServerRandom". 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; Set to "ClientRandom". 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. 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; Set to "ClientSuccess" if transmitted by the client, "ServerSuccess" if by the server. The length of the string encoding the selected 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.

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.

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: 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. The client scans the QR code retrieving the necessary information for establishing a connection to the server. [[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.]]

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

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 , 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 .

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 and the authentication procedures specified in 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 mitigate such attacks, nodes MUST store the secret safely, and MUST be able to quickly revoke a compromised pairing.

This draft does not require any IANA action.

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.