Network Working GroupM. McRoberts
Internet-DraftProject Baird
Intended status: InformationalJuly 13, 2010
Expires: January 14, 2011 

Protocol for pairing networked devices to one another


This document describes a protocol which allows two devices to establish a "pairing" relationship with one another, establishing a set of credentials which can be used to satisfy further authentication requirements.

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

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 January 14, 2011.

Copyright Notice

Copyright (c) 2010 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 ( 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.

1.  Introduction

As increasing numbers of devices are developed with network connectivity, it becomes desirable for there to be a standard mechanism for establishing trust relationships between individual devices: that is, "pairing" them.

For example, consider a hand-held device, such as a mobile phone, connecting to a media device, such as a television. Because it is generally undesirable to grant unrestricted access to an unknown device (even across an ostensibly "private" network), some kind of authentication must be employed. Traditional username and password authentication tends not to be practical in this circumstance: rather, a process whereby a user can "pair" the devices with one another and (thus generate persistent authentication tokens) is more desirable.

This specification sets out a process by which this might be implemented. It requires that the "client" device (that is, the "remote" device) a display and some kind of input mechanism, while the "server" device features at a bare minimum a display.

The protocol defined in this document is based upon HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), and all requests and responses are well-formed and valid HTTP requests and responses. The protocol is designed such that it may co-exist with other HTTP-based services operating on the same TCP/IP port, including those which are intended to be directly user-facing.

2.  Conventions and terminology used in this document

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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)

The term "server" is used to refer to the device providing the pairing protocol server, such as a television or a media centre. The term "client" is used to refer to the device which the user wishes to pair with the server, for example a mobile phone, or dedicated remote device.

3.  Pairing mechanism

The mechanism described here works on the basis of a shared secret which is transferred between devices by the user: specifically, it is a randomly-generated code number (between four and eight digits in length) which is generated and presented to the user by way of some display device attached to the server, and must be entered on the client in order to complete the pairing process.

In subsequent authentication requests, the supplied code number is used as a password, while a per-client server-supplied UUID [RFC4122] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.) is used as a username.

Before this can occur, the client must discover that the server is available for pairing: requiring users to enter hostnames or IP addresses is not generally practical, and so it would be preferable for client devices to perform automatic discovery of devices operating on the local network which offer a pairing capability. For this purpose, this document specifies the use of Multicast DNS [I‑D.cheshire‑dnsext‑multicastdns] (Cheshire, S. and M. Krochmal, “Multicast DNS,” March 2010.) in combination with DNS-based Service Discovery [I‑D.cheshire‑dnsext‑dns‑sd] (Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery,” March 2010.).

The diagram below illustrates the process, which is described in detail in the following sections.

         Client                                   Server

 1.                                        "Add remote device"
                                           Service is enabled and
                                           advertised on network.

 2.  "Connect to server"
     Begin discovery.

 3.  Present list of discovered
     servers to the user.

 4.  User picks a server to pair

 5.  Make initial GET request
     to the server.

 6.                                        Generate a new UUID and
                                           passcode to identify the

 7.                                        Send a 301 redirect to
                                           client, based on UUID.

 8.  Follow the redirect, making
     a new GET request.

 9.                                        Respond with 401 status,
                                           display passcode to user.

10.  Prompt user to enter passcode
     displayed on server.

11.  Re-request previous URL,
     specifying UUID as username
     and passcode as password.

12.                                        Send a 2xx response, mark
                                           client as paired.

13.  When 2xx response is received,
     mark server as paired.

3.1.  Advertisement

Server devices should advertise the availability of the pairing service using a DNS-SD service type [DNSSD‑SRV] (, “DNS SRV (RFC 2782) Service Types,” .) of "remote-pairing". That is, registrations occur using the name "_remote-pairing._tcp" and SHOULD by default be restricted to the link-local scope. Devices SHOULD make the service available via both IPv4 and IPv6 and advertise the accordingly.

Servers SHOULD NOT make the service available (and by extension, advertise) by default: they SHOULD instead require some kind of user action, such as enabling an option within a menu or pressing a physical "pairing" button. Servers MAY provide an option to users which allows continual availability of the pairing service.

Servers SHOULD advertise a host name which is intended to be human-readable, for example "John's TV". Servers SHOULD allow the user to customise the host name, and SHOULD advertise the name consistently between services.

Service advertisements MUST include a TXT record whose data is in the following format, given as Augmented Backus-Naur Form (ABNF) as specified by [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.):

txt-record  =  "txtvers=1 uuid=" UUID " path=" path-absolute

The UUID included in the advertisement MUST be unique to the server and MUST NOT change during the course of normal operations of the device.

The value of the "path" parameter is the "root" path which will be used as the prefix for for all requests made to the service. Servers SHOULD NOT include a trailing forward-slash character in the path. Clients MAY strip any trailing forward-slash characters which are present.

A sample advertisement is shown below

_remote-pairing._tcp.local                IN PTR   John's\032TV._remote-pairing._tcp.local.

John's\032TV._remote-pairing._tcp.local.  IN SRV   0 0 80 tv234759.local.
John's\032TV._remote-pairing._tcp.local.  IN TXT   "txtvers=1 uuid=30146e8b-0d1a-47b9-825d-bebd7c23acaf path=/pairing"

tv234759.local.                           IN A
tv234759.local.                           IN AAAA  fe80::223:dfff:feaa:4762

3.2.  Discovery

When requested to pair with a server, a client device should begin discovery for devices on the local network advertising the "remote-pairing" service. The client should present a list of matching devices to the user. Clients SHOULD NOT present IP addresses or the SRV record "target" host name to users unless specifically configured to. Clients SHOULD indicate devices for which a pairing already exists, but SHOULD NOT omit them from the list of discovered devices.

Once a user has chosen a device to pair with, the client shall begin the pairing process as described below.

3.3.  Client initiates the pairing process

The client connects to the server and performs an HTTP "GET" request on <root>/pair?device-name=<name>, where <name> is replaced with the client device’s "display name" (e.g., "Dan’s iPhone"), URL-encoded as required by HTTP.

3.4.  Server returns a redirect response

The server responds with 302 Moved temporarily and supplies a "Location" response header of <root>/<uuid>, where <uuid> is a newly-generated UUID which shall be used to identify the client device to the server.

The server shall store the UUID and client device name. It shall generate a numeric passcode of not less than four and not more than eight digits, and store it in some way associated with the UUID. There shall be a flag of some kind associated with the UUID indicating whether the client device has successfully paired or not, and it shall not be set. The server shall also store the display name of the device associated with the UUID, as was supplied in the HTTP request.

3.5.  Client follows redirect

The client shall make an HTTP GET request to the URL supplied by the server (that is, <root>/<uuid>).

3.6.  Server prompts for authentication

When the server receives the HTTP request, it shall return a "401 Unauthorized" response and include details about supported authentication schemes as per [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.). Both clients and servers MUST support Digest authentication, but may support other schemes. Basic authentication SHOULD NOT be used.

The realm included in the "WWW-Authenticate" response header must be the server device’s own UUID. The client device may verify that this UUID matches that which it expected to receive given the Bonjour advertisement as a sanity-check.

If it has not already, it shall display a message on its display indicating that a pairing request has been received from the client device. It shall display the passcode which has been stored and indicate to the user that they must enter it on the client device.

3.7.  Client prompts user for passcode

The client device shall indicate to the user that they should enter the passcode displayed on the server device.

3.8.  Client makes request to the server

The client shall retry the GET request to the URL supplied by the server, supplying authentication details as per RFC2617. The user name shall be the UUID supplied by the server; the password is the passcode entered by the user. The client stores the UUID and passcode for future authentication requests.

3.9.  Server responds to pairing request

If the passcode supplied by the client device is correct, the server must respond with a 2xx response code and marks the device in its database as having been authenticated.

If the passcode supplied by the client device is incorrect, continue at Step 4.

If the UUID specified in the URL is not present in the database, the server responds with a 404 Not Found status. The client should immediately abort the pairing process.

3.10.  Indicate to the user that pairing was successful

Both devices should add the other to a user-manageable list of paired devices and indicate that pairing was successful. The server will update its database entry for the client to indicate that pairing has completed successfully. Subsequent requests to protocols requiring authentication which properly supply the client UUID and passcode should then succeed until the user opts to un-pair the devices.

4. Normative References

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4122] Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” RFC 4122, July 2005 (TXT, HTML, XML).
[RFC4234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 4234, October 2005 (TXT, HTML, XML).
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, June 1999 (TXT, HTML, XML).
[I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, “Multicast DNS,” draft-cheshire-dnsext-multicastdns-11 (work in progress), March 2010 (TXT).
[I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery,” draft-cheshire-dnsext-dns-sd-06 (work in progress), March 2010 (TXT).
[DNSSD-SRV] DNS SRV (RFC 2782) Service Types.”

Author's Address

  Mo McRoberts
  Project Baird