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.
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 http://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 January 14, 2011.
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 (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.
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.
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.
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 with. 5. Make initial GET request to the server. 6. Generate a new UUID and passcode to identify the client. 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.
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 192.168.0.25 tv234759.local. IN AAAA fe80::223:dfff:feaa:4762
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.
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.
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.
The client shall make an HTTP GET request to the URL supplied by the server (that is, <root>/<uuid>).
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.
The client device shall indicate to the user that they should enter the passcode displayed on the server device.
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.
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.
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.
|[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.”|