| Network Working Group | C. Jennings |
| Internet-Draft | Cisco |
| Intended status: Experimental | October 13, 2012 |
| Expires: April 14, 2013 |
Transitive Trust Enrollment for Constrained Devices
draft-jennings-core-transitive-trust-enrollment-00
This is a copy of the paper sent to the "Smart Object Security" workshop March 23, 2012 in Paris. It is submitted as an IETF draft to have a record of it in the draft archive. The original publication date of this work was Feb 14, 2012. Readers are encouraged to read later versions of this draft.
This document provides a very early sketch of a enrollment protocol that allows constrained internet devices to securely enroll into a system. As the work is in its early phase, many details remain to be resolved. The solution is based on the idea that each device will be manufactured with a one time password that can be used by the customer to tell the device which controller to enroll with.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
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 April 14, 2013.
Copyright (c) 2012 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.
Secure enrollment of devices into internet-based systems has never been easy. The constrained devices that need to be enrolled into systems today face many challenges. Typically, simple devices have no user interface such as a keyboard or screen - they may have only a single button or LED. At the time they are installed, there may not be a working network or even power. However, these devices are being used for applications that are increasingly important and safety-critical, so they need to have reasonable security and privacy characteristics. This documents specifies an enrollment system for such devices.
In many systems, there is a need to configured a Device, such as a sensor or actuator, so that it is controlled by some specific controller. In the case Devices like a switch and light, it may be that all the Controller does is later configure the switch to control the light. To make this happen, both Devices need to be under the control of a common Controller that is authorized to make changes to the Devices.
The simplified high-level information flow is illustrated in the following figure. The goal is to get to the point where the Device knows that it should be talking to the Controller.
TODO ASCII FIGURE
When the Manufacturer builds the Device, it includes a One Time Password (OTP) that the Introducer can use to enroll the Device with the Controller. The Manufacturer also runs a website known as the MotherShip that knows the OTP for every device that Manufacturer builds. The Device can include the OTP as a QR code on the outside of the Device. When the Device is installed, the installer uses a software agent known as the Introducer. The Introducer would typically be something like an application running on an iPhone. When the Device is installed, the Introducer can scan the QR code on the Device to find the OTP (Message 1). The Introducer then contacts the MotherShip and uses the OTP to tell the MotherShip which Controller this Device is should use (Message 3). Later, the first time the Device boots up and gets network connectivity, it contacts the MotherShip, and the MotherShip tells the Device which Controller to talk to (Message 3). From that point on, any time the Device boots, the Device can communicate directly with the Controller (Message 4). The actual message flow is slightly more complicated and shown in Section 2, but it uses the same basic idea as this simplified flow.
The system is designed to achieve several desirable properties:
One of the key steps in making this system work is getting the OTP from the Device to Introducer. There are several ways that could happen but a few of the approaches considered here are:
The semantic level information in each message is discussed in Section 2 and the syntax of the messages is discussed in Section 3. The security properties of the system are described in Section 4.
The Manufacturer, Device, MotherShip, Introducer, and Controller are abbreviated M,D,MS,I,C respectively. The Device, MotherShip, and Controller all use CoAP to communicate with each other and thus each have an asymmetric key pair that is used to form the DTLS connections between them. The MotherShip acts as an HTTP server to communicate with the Introducer and Controller. The MotherShip needs a normal certificate to use HTTPS.
It is assumed that the Device may have a NAT between it and the Controller and that the Device is on the inside of the NAT. The MotherShip is assumed to be a generally accessible server on the internet but the Controller and Device can be on the inside of a Firewall or NAT between them and the MotherShip.
In the following message flow we use the following definitions:
The information flow is illustrated in the following figure. The goal is get to the point where the Device knows that it should be talking to the Controller, the Controller knows it should be talking the Device, and the Device and Controller can communicate using CoAP and authenticate each other using their public keys.
TODO ASCII FIGURE
When the Manufacturer builds the Device, it includes a One Time Password (OTP) on the Device and MotherShip (Message 1 and 2). When the Device is installed, the Introducer reads OTP and other information from the Device (Message 3). The Introducer then uses the OTP to tell the MotherShip which Controller this Device should use (Message 4 and 5). Later the Device contacts the MotherShip and tells the Device which Controller to talk to, information that the Device saves in non-volatile memory (Message 9 and 10). From that point on, any time the Device boots, it can directly communicate with the Controller (Message 11 and 12).
The Introducer has the option of informing Controller about any Devices that it has enrolled with this Controller (Message 6). The Controller can optionally contact the MotherShip to find out about the status of any Devices that it has not heard from (Messages 7 and 8).
participant Manufacturer participant Device participant MotherShip participant Introducer participant Controller Manufacturer-->Device: 1 MS ID,MS Fingerprint,\nDev ID, OTP Manufacturer-->MotherShip: 2 Dev URN, Dev ID, OTP note right of Introducer: User tells I:\n C Addr, Dev Desc Device-->Introducer: 3 MS ID, Dev ID, OTP Introducer->MotherShip: 4 Dev ID, OTP,\nC Addr, C Fingerprint MotherShip->Introducer: 5 Dev URN,\nDev Fingerprint Introducer->Controller: 6 Dev URN,\nDev Fingerprint, \nOTP, Dev Desc Controller->MotherShip: 7 Dev URN, OTP MotherShip->Controller: 8 Dev State Device->MotherShip: 9 Dev URN MotherShip->Device: 10 Addr,\n C Fingerprint Device->Controller: 11 Hello Controller->Device: 12 HelloAck
When the Device is built, it needs to be assigned a globally unique URN, a Dev ID, and a MotherShip. A single manufacturer MAY operate many MotherShips as each one can only support 16 million Devices. A perfectly reasonable way to generate the Dev ID is to use the least significant 32 bits of the Device URN. The Device needs to be programmed with the IP address and port of the MotherShip along with the fingerprint of the public key that the MotherShip will use in the DTLS CoAP exchange.
The creation of the MotherShip domain name is discussed in Section 3.4. The QR code for the Device MUST be an HTTPS URL that points at the appropriate MotherShip and MUST include a URL parameter called "otp" that is set to OTP represented in hexadecimal and MUST include a URL parameter called "devid" that is set to the Device ID represented in hexadecimal. It MUST use the default HTTP port and MUST have an absolute path of /.well-known/tte. As an example, if the MotherShip's domain name was ""tte-000000.net", the OTP was 0x123456789abcdef0 and the Device ID was 0xABCDEF01, a valid URL would be:
https://tte-000000.net/.well-known/tte?
otp=123456789abcdef0,DevID=abcdef01
The QR code SHOULD use an error coding level of "H". This would generate the following QR code:
QR code in ASCII art left as an exercise to the reader but there is one in the PDF version.
The Introducer reads the QR code found and the Device, then uses this URL to contact the MotherShip in messages 4 and 5. This URL is referred to as the Enrollment URL .
Messages 4 and 5 MUST be sent over TLS, and the Introducer MUST verify that the HTTPS certificate of the MotherShip matches the URL. The Introducer can perform either an HTTPS GET or POST. If the Introducer does a GET, it MUST make an HTTPS GET request to the Enrollment URL and MUST act as a web browser to process returned HTML pages. In the case of a GET, the MotherShip MUST return a web page that allows the user to enter the IP address and port of the Controller as well as the fingerprint of the Controller's public key used in CoAP. If the Controller does not wish to act as a web browser, instead of using the GET, it will use a PUT. When using a PUT, the Controller MUST make an HTTPS POST request to a URL formed by appending three parameters to the Enrollment URL. The parameters are cip, which MUST have the IP address of the Controller; cport, which MUST have the port of the Controller; and cfingerprint, which MUST have the fingerprint of the Controller's Public Key, represented in hexadecimal. If, and only if, the MotherShip successfully stores the address information, the POST MUST return an HTTP 200 response with a JSON string containing the URN and Fingerprint for that Device. The format of this object is described in Section 3.2.
Once the MotherShip has successfully stored the Controller's address for a given OTP, it MUST NOT allow that OTP to be used again to store an address for that Device. The OTP can be used after this to query the status of the enrollment as described in Section 3.2.
Message 6 is optional and MAY be omitted. As some point after the Introducer has successfully mapped the Device to the Controller, it can send an HTTP or HTTPS request to the Controller to notify it that it can expect to hear from a particular Device. The message formats for this are defined in Section 3.3. This does not need happen immediately and the information can be saved so it can be done far in the future. This might happen if Devices were being installed before the Controller was even operational. In other cases it might be done immediately. (TODO - look at in web browser case having MotherShip redirect Introducer to Controller after successful Introduction.) This is done with an HTTP POST to TBD URL with parameters to convey the Device URN and Fingerprint learned from the MotherShip, the OTP password, and a locally significant description string that can be used to help label the Device for management reasons.
In the case where the Controller has learned the URN and OTP for a given Device, it MAY query the MotherShip to find out the enrollment status. It does this with an HTTP GET request to TBD URL. The various statuses that can be returned in TBD JSON doc are: revoked, not mapped, mapped, registered. TODO - could use better names and descriptions.
When the Device has powered up and has network connectivity for the first time, it attempts to form a CoAP connection to the MotherShip. The Device makes a CoAP GET request to TBD URL, passing its URN as a parameter. Details of this message are provided in Section 3.1. The Device MUST check that the Public Key provided by the MotherShip in the DTLS connection matches the fingerprint provided by the Manufacturer. The MotherShip needs to look at the Public Key provided in the DTLS and ensure that it matches the fingerprint for this Device that was provided by the Manufacturer. If everything does match, the MotherShip MUST return (in Message 10) the IP address and port for the Controller as well as the Fingerprint for the Controller's public key. Details for the syntax of these messages are provided in Section 3.1. If this is successful, the Device MUST store the address and fingerprint for the Controller in non-volatile memory and, on future reboots, skip all the steps before this and connect directly to the Controller. (TODO - Define how retries work if the Device has not yet been enrolled.)
At this point, the Device can form a CoAP connection to the Controller. The Device can verify that it is speaking to the correct Controller by checking that the DTLS Public Key matches the fingerprint for the Controller that was retrieved from the MotherShip. If the Introducer has contacted the Controller in message 6, then the Controller will already have the fingerprint of the Device and can verify that it matches the DTLS information in the connection between the Device and the Controller.
The Controller MAY be configured such that if it does not have the information from Message 6 it can ignore the Device until it gets the information from the Introducer, or, alternatively, such that it can accept the connection based purely on the fact that the network was configured to send messages to the Controller.
This section is missing from the current draft and will be completed in future revisions once feedback on the overall design and been incorporated.
TODO - define well known COAP URL on MotherShip that the Device uses to get information about Controller.
TODO - Define a JSON object with Device URN, Device public key or fingerprint, and enrollment state.
TODO - define HTTP messages to allow Introducer to tell Controller about a new Device. Need a way for Introducer to tell Controller, the Device public key or fingerprint, the Device URN, and the locally significant label string, and the OTP.
This system requires a programmatic way to go from a MotherShip ID, which is a 32-bit integer, to an address that can be used to contact that MotherShip. The approach here is to use DNS for that mapping. For a MotherShip ID that has a high order byte of 0x00, the DNS host name of the MotherShip if formed by prepending "tte-" to the lower order 24 bits of the MotherShip ID represented in hexadecimal, and then appending ".net". So the host name for the MotherShip ID 10 would be "tte-00000A.net". MotherShip IDs that have a high order byte other than 0x00 are reserved for future specifications.
A Manufacturer gets a MotherShip ID simply be registering the corresponding DNS entry. The MotherShip ID zero is reserved for examples and MUST NOT be treated as a valid ID by operational systems. A manufacturer wishing to have more than 2^32 Devices would simply register multiple MotherShip IDs.
This section has not really been started and needs lots of work.
TODO - Discuss how one can replace a dead Controller with a new one in an operational network. The short answer is likely that one needs to back up the private keys of the old Controller and move these to the new Controller.
What happens if the OTP is stolen during Device transit? The short answer is that the Device is compromised at this point and needs to be discarded or returned to the manufacture to get a new Device ID and OTP. The Introducer needs to detect that this has happened and warn the user.
There are additional concerns about Devices that may be operational without ever being introduced to a Controller. For example, if a light switch supported this protocol, but could also be used just as a stand alone light switch, there is a risk the OTP could be stolen by an attacker, with the attacker enrolling the Device to the attacker's Controller. When the correct user installs the light switch, if they never bother to try to Introduce it to anything, they will not detect that it has been compromised. One way to mitigate this risk in situations where it exists might be to include some manual configuration on the Device to indicate that it is to be used in stand-alone mode, such as a jumper that can be cut.
Network topology consideration - Introducer can install firewall rules that allow Devices to contact MotherShip.
why works with NATs / FWs.
An alternative to QR codes is to have an LED on the Device flash out the relevant information to the Introducer. The output string is formed by concatenating a 16-bit start of message constant value of 0x0001, followed by the MotherShip ID, Device ID, OTP, and then an 8-bit two's compliment checksum value computed over the previous bytes, including the start of message constant. All values are in network byte order. The resulting string is output using Non-Return-to-Zero Inverted (NRZI) encoding on the LED at a baud rate of 15 bps. This allows a Device such as a smartphone with video capture to detect the signal and recover the information.
TODO - see if this works at 30 bps. See about encoding multiple intensity levels or colors in the LED. Initial experiments indicate this does not work very well as auto contrast in the video camera tends to saturate LED range. Would an Adler-32 checksum be better?
Imagine one wants to enroll a whole box of sensors. We should define some scheme where one can simply bar code something on the outside of a box and can bulk enroll all the sensors in the box. Perhaps have a scheme where there is a master secret and start and end Device ID on the outside of box bar code. Then the OTP for a given Device is generated using the master secret and DeviceID of that Device. Need to sort out details of a scheme like this.
The examples here assumed that COAP was being used with DTLS with asymmetric keys. It would also be possible to use DTLS in Pre Shared Key (PSK) mode in a very similar flow, where the Introducer provided the MotherShip with the PSK to be used between the Device and the Controller.
The references section is in serious need of work - let me know stuff that should be added to it.
Does QR encoding of L work out better than H?
Is there any advantage in having the HTTP URL in well-known space?
Is there some clever way (perhaps zeroconf) for the Introducer to discover the Controller's information?
TODO - create registry for the top byte of MotherShip ID
TODO register .well-known HTTP URL
Some of the fundamental ideas in this draft where inspired by Max Pritikin's work. I'd like to thank the following people for review comments: Eric Rescorla
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-core-coap] | Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-08, October 2011. |
| [I-D.arkko-core-dev-urn] | Arkko, J, Jennings, C and Z Shelby, "Uniform Resource Names for Device Identifiers", Internet-Draft draft-arkko-core-dev-urn-01, October 2011. |