| 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-01
This document provides a sketch of a rendezvous protocol that allows constrained internet devices such as sensors to securely connect into a system that uses them. 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, and the device will be manufactured to contact a given Transfer Server that is used to tell the device which system to connect to. The administrator of the device will be able to get this one time password from the device using a QR code, and then will be able to use that one time password to inform a Transfer Server which system the device should connect to. The device will contact the Transfer Agent, get this information, and then connect to the appropriate system.
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 such as keyboards and screens have no user interface; 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 configure a Device, such as a sensor or actuator, so that it is controlled by some specific Controller. With 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 - See PDF Version of draft
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 Transfer Agent that knows the OTP for every device that uses that Transfer Agent. The Device can include the OTP as a QR code on the outside of the Device. When the Device is installed, the network administrator or installer uses a software agent known as the Introducer. The Introducer would typically be simply a normal browser running on a smart phone with a camera that can read QR codes. When the Device is installed, the Introducer can scan the QR code on the Device. This QR code includes a URL to the Transfer Agent along with the OTP and a separate Device secret DevSecret. (Message 1). The Introducer then contacts the Transfer Agent and uses the OTP to tell the Transfer Agent which Controller this Device should use (Message 2). The Introducer can also tell the Controller the DevSecret (Message 3) so that the Controller and Device can authenticate each other. Later, the first time the Device boots up and gets network connectivity, it contacts the Transfer Agent, and the Transfer Agent tells the Device which Controller to talk to (Message 4). From that point on, any time the Device boots, the Device can communicate directly with the Controller (Message 5). 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 the Introducer. The approach used here is to use a QR code representing the URL. The QR code is printed on the Device and/or box it comes in.
The Device uses HTTP or COAP [I-D.ietf-core-coap] to communicate with the Controller. The Transfer Agent and Introducer use HTTPS to communicate with each other. There are three pieces of keying material used for cryptographic operations. The first is the One Time Password (OTP) that is passed via a QR code from the device to the Introducer and that the Introducer then uses to authorize itself to the Transfer Agent. There is also a DevSecret that is used to secure communications between the Device and the Controller. Finally there is a TaSecret that is used to secure communications between the Device and the TransferAgent. The Transfer Agent 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 Transfer Agent 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 Transfer Agent.
The semantic level information in each message is discussed in Section 2 and the syntax of the messages is discussed in Section 5 and Section 6. The security properties of the system are described in Section 7.
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 and authenticate each other using the DevSecret.
TODO - See PDF Version of draft
When the Manufacturer builds the Device, it includes a TaSecret on the Device, a DevSecret, and the URN for the Device (DevURN). It also creates a QR code on the Device that contains the URL to the transfer agent (TaURL), the URN for the Device (DevURL), the OTP, and the DevSecret. This QR codes is described in detail in section TODO. The Manufacturer also tells the Transfer Agent the OTP, TaSecret and DevURN for this Device.
When the Device is installed, the Introducer reads OTP, DevSecret, DeviceURN, and the URL for the Transfer Agent (TaURL) from the Device by scanning the QR code on the device (Message 1). If the Introducer is a web browser, it uses the Transfer Agent URL to fetch an HTML user interface to perform the next steps (Message 2). The user interface on the Introducer allows the user to user to enter the URL for the Controller (ContURL) and an optional label for the device (DevLabel).
Next the controller tells the Transfer Agent the Controller URL to use for this DeviceURN. This request is authenticated by the Transfer Agent using the OTP (Message 3). Open Issue: right now the OTP is transfered in the request (which is over HTTPS). A better design might be to have the Introducer prove procession of the OTP to the Transfer Agent and not send the OTP over the wire.
The Introducer also tells the controller the DevSecret for this Device and the optional DevLabel (message 4).
Later the Device contacts the Transfer Agent and the Transfer Agent tells the Device the URL of the Controller to talk to (ContURL) in message 5 and 6). The information from the Transfer Agent to Device is encrypted and signed with the TaSecret.
From that point on, any time the Device boots, it can directly communicate with the Controller (Messages 7 and 8). The Controller and Device both know the DevSecret for the Device and can use that to authenticate and encrypt communications between them. It is suggested that the first thing the Controller and Device should do is to use this DevSecret to securely replace it with some different secret that is not known to anyone that saw the QR code.
Open Issue: should we add in an additional ContSecret that is picked by the Controller, passed to Introducer, then passed to the Trust Agent, and finally passed to Device?
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When this draft says Base64, it means the URL safe Base64 encoding from TODO.
The QR code for the Device MUST be an HTTPS URL that points at the appropriate Transfer Agent. The authority MUST be formed by using the authority from the TaURL. The path is formed by concatenating ".well-known/tte1/" followed the DevURN followed by "/s". The DevURN SHOULD be one of the URNs defined in [I-D.arkko-core-dev-urn]. It MUST include the OTP as a Base64 encoded value for a parameter called otp. The secret MUST be encoded in Base64 and used as the fragment identifier of the URL. The secret is put as a fragment so that if the Introducer scans the QR code and dereferences the URL with a web browser, the fragment identifier will not be transferred in the request to the Transfer Agent.
As an example, if the Transfer Agent's domain is example.net, a valid URL for the QR code would be:
TOOD - change hex to base64
https://example.net/.well-known/tte1/urn:dev:mac:90a2da001a0c/s
?otp=88F5EC91493E473B758159C7792C#00004DCFDCDBD9F54C1B2E71FC22
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.
Note that future version of the API that needed to increment a version number would do it by changing the tte1 to tte2.
TODO - still need to define all the error responses but basic approach will be a simple JSON object with the error responses.
The HTTP REST API allows the manufacturer to tell the Transfer Device about the DevURN and OTP for a given device the Manufacturer has created.
This creates an entry for the device in the database and stores the OTP associated with this Device. The Transfer Agent SHOULD authenticate this request to authorize it. Note the "d" in the path is short for "device"; having this path segment allows for future extensibility.
POST https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c
?otp=88F5EC91493E473B758159C7792C
Example Request:
TODO
Example Response:
The Transfer Agent MUST return a web page that allows the user to provide the information needed for the bind, and then the Introducer must call the bind and add methods.
This MUST return a HTML web page that has a suitable user interface to allow the user to enter the address of the the Controller. It is suggested that the page validate that this controller entry is correct using the "alive" API in Section TODO. Once the Controller is verified, the web page MUST tell the Transfer Agent the Controller address using the "bind" API in Section TODO. The page MUST tell the controller the DevURN and DevSecret for the Device using the "add" API in Section TODO. MUST be done over HTTPS.
GET https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c/s
?otp=88F5EC91493E473B758159C7792C
Example Request:
TODO MUST be sent over TLS, and the Introducer MUST verify that the HTTPS certificate of the Transfer Agent matches the URL.
Once the Transfer Agent 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.
This request using the
TODO
PUT https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c/c
?otp=88F5EC91493E473B758159C7792C
Example Request:
This API allows a Device to get the information about the controller it should connect to. It is provided in a JSON object which is encrypted using the OTP.
The Transfer Agent looks up the OTP and ContURL for the requested DevURN. If the DevURN cannot be found, or the ContURL has not yet been set for this DevURN, then the Transfer Agent returns an HTTP 404 error. If they are found, it then the Authenticated Encryption with Associated Data (AEAD) algorithm described in Appendix A (TODO ref) to form the JSON object that is returned. The TaSecret is used as the key for the AEAD, the ContURL is the input data to be encrypted, and the DevURN is used as Associated Data for the authentication.
GET https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c/c
Example Request:
TODO
Example Response:
The Alive and Add API need to include a CORS (TODO REF) header to allow AJAX from the Transfer Agent to call these APIs. They MUST include an HTTP header in the response that sets the header field Access-Control-Allow-Origin to a value of "*". TODO security section needs to discuss implications.
This method allows the Introducer to validate that a valid Controller address has been entered. It simply returns an HTTP 200 if the controller is operational.
This method is used by the Introducer to add a new Device to the Controller. (Open issues - should it result in redirect to a controller web page to configure device? )
TODO
The body is a Encrypted JOSE object, as specified in Appendix A (TODO REF). The secret for this Device is used as the key to encrypt the data. The DevURN is used as the associated data. The decrypted data is a SENML sensor reading for this Device as described in [I-D.jennings-senml].
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 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 manufacturer to get a new 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 would be a risk that the OTP could be stolen by an attacker, with the attacker enrolling the Device to the attacker's Controller. If the correct user installed the light switch but did not Introduce it to anything, the fact it had been compromised would go undetected. One way to mitigate this risk 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 Transfer Agent.
Explain 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 8 bit length of TaURN, TaURN, 8 bit length of DevURN, the DevURN, 8 bit length of OTP, OTP, 8 bit length of DevSect, DevSecret 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? Could multiple colors of intensity improve the speed of this as this is very slow.
Imagine one wants to enroll a whole box of sensors. We should define some scheme where one could simply bar code something on the outside of a box so that all the sensors in the box could be bulk enrolled. Perhaps there could be a master secret and start and end DevURN on the outside of the box bar code. Then the OTP for a given Device would be generated using the master secret and DevURN of that Device. Work is needed to sort out details of a scheme like this.
This specification assumes that COAP is being used with DTLS in Pre Shared Key (PSK) mode. It would also be possible to use DTLS with self signed certificates with a very similar flow, where the Introducer provided the Transfer Agent with the fingerprint of the certificate or public key of the Controller.
The system described here can be implemented on a very small device. An implementations for Arduino with ethernet was done that includes all the parts described here, including SENML, JSON, the encryption and signing, HTTP, DNS, and DHCP. It also included libraries for reading a 1-wire temperature sensor. This fits in under 32k of flash, and uses less than 4k of ram on an 8 bit AVR processor. That means that the cost for an embedded processor in volume with this much flash, ram, etc. is very roughly $1.50 USD in 2012. A key part of getting this to be small is the extremely small crypto footprint from using SHA224-CFB.
Note: This section would be better in a separate draft.
TODO - Explain how to use SHA224_DRBG as defined in NIST SP800-90A. TODO REF. Store reseed counter in eeprom every 24 hours. Explain what to store in eeprom on reseed. TODO REF RFC 4086 and XKCD 221.
Todo - Discuss sources of randomness in use: 16 bytes of random data created during manufacturing. A 32 bit boot counter that increments every time the device boots. 8 byte pool of random data from sensor readings. 8 byte pool of random data from timing of receiving or sending network packets. A 32 bit counter that increments each time a random number is generated but resets to 0 on reboot.
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 ContURL?
TODO register .well-known/tte1
Some of the fundamental ideas in this draft were inspired by Max Pritikin's work on Transitive Trust Introduction. Randy Bush provided crisp and excellent advice on what the security properties of the solutions should be. I'd like to thank the following people for review comments: Eric Rescorla, Jari Arkko, Lyndsay Campbell, and Zach Shelby.
Note: This section will eventually be moved to an experimental draft submitted to JOSE WG.
This section describes how to create a JOSE object as described by [I-D.barnes-jose-jsms] that is encrypted and signed with SHA224-CFB as specified in [HashCFB].
This adds a new ENCRYPTION algorithm called sha224-cfb to [I-D.barnes-jose-jsms]. This takes one parameter named "n" which represents the nonce as defined in [HashCFB]. It is RECOMMENDED that the key be 14 bytes long and that the nonce be 24 bytes long. The authentication information from the algorithm is stored in the "mac" field.
TODO example. Todo fix to base64 instead of hex encoding. TOOD talk to Barnes about keyID and case with no key wrap. TODO - state of sha224-cfb and this is all experimental.
Input Key (Hex) = 88F5EC91493E473B758159C7792C
Input Associated Data = "urn:dev:mac:90a2da001a0c"
Input plain text = "http://example.com" - TODO
Result =
{
TODO
}
| [HashCFB] | Forler, C., McGrew, D., Lucks, S. and J. Wenzel, "Hash-CFB: Authenticated Encryptions without a Block Cipher", Directions in Authenticated Ciphers Workshop , July 2012. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5785] | Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. |
| [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. |
| [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.barnes-jose-jsms] | Barnes, R, "JavaScript Message Security Format", Internet-Draft draft-barnes-jose-jsms-00, June 2012. |
| [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. |
| [I-D.jennings-senml] | Jennings, C, Shelby, Z and J Arkko, "Media Types for Sensor Markup Language (SENML)", Internet-Draft draft-jennings-senml-07, October 2011. |