[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                        C. Jennings
Internet-Draft                                                     Cisco
Intended status:  Experimental                          October 13, 2012
Expires:  April 16, 2013


          Transitive Trust Enrollment for Constrained Devices
           draft-jennings-core-transitive-trust-enrollment-00

Abstract

   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.

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

Copyright Notice

   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



Jennings                 Expires April 16, 2013                 [Page 1]


Internet-Draft         Transitive Trust Enrollment          October 2012


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


1.  Introduction

   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



Jennings                 Expires April 16, 2013                 [Page 2]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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:
   o  Can work for Devices with very limited memory and processing power
   o  Does not require network or power to be up when the Device is
      installed
   o  Is fairly secure (see more in the security section)
   o  Minimal addition to manufacturing costs
   o  The installer can detect if the OTP has already been used
   o  Provides a work flow in which a Device does not need to be taken
      out of the box to be enrolled.  This can be very important to
      enable consumers themselves to enroll devices they buy from a
      service provider.
   o  Works with common Firewall and NAT network topologies

   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:

   o  Using a QR code or other bar code printed on the Device and/or box
      it comes in
   o  Having a single LED on the Device that blinks out the OTP
      information and using a video capture application on the
      Introducer to read this
   o  The manufacture providing the OTP in some other machine readable
      form
   o  Including the OTP in an RFID tag on the Device that can be read by
      the Introducer
   o  Having an electrical interface (such as one wire memory) on the
      Device that can be read by the Introducer

   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.


2.  Enrollment Information Flow

   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



Jennings                 Expires April 16, 2013                 [Page 3]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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:
   Fingerprint  This refers to a hash of the DTLS public key used by the
      associated network element.  "MS Fingerprint" means a fingerprint
      of the public key that the MotherShip will use when forming CoAP
      connections over DTLS.
   MS ID  A 32-bit integer that uniquely identifies the MotherShip.
      Section 3.4 explains how to use the MS ID to create a URL that can
      be used to contact the MotherShip.
   Dev ID  A 32-bit integer that identifies the Device and when combined
      with the MotherShip is unique.  Two Devices that use the same
      MotherShip cannot have the same Dev ID.
   Dev URN  A globally unique URN assigned by the Manufacturer to
      uniquely identify this Device.  This SHOULD be one of the URNs
      from [I-D.arkko-core-dev-urn].
   OTP  The One Time Password created by the Manufacturer for enrolling
      the Device.  This is a cryptographically random 64-bit integer.
   C Addr  Address of the Controller.  This is an IPv4 or IPv6 address
      and port which the Device can use to form a CoAP connection to the
      Controller.
   Dev Descp  A locally significant string that the Introducer can
      assign to a Device.  For example, the convention for a thermostat
      in building 30, floor2, office 361 might be assign the string
      "BLD30/2/361 - Thermostat".  This string is provided purely as a
      way to let the Introducer and Controller exchange information that
      may be useful for the Installer.
   Dev Status  The Controller can query the MotherShip for the
      enrollment status of a Device that is enrolled with that
      Controller.  The various states returned are defined in
      Section 3.2.

   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



Jennings                 Expires April 16, 2013                 [Page 4]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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



Jennings                 Expires April 16, 2013                 [Page 5]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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



Jennings                 Expires April 16, 2013                 [Page 6]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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



Jennings                 Expires April 16, 2013                 [Page 7]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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.


3.  Message Formats

   This section is missing from the current draft and will be completed
   in future revisions once feedback on the overall design and been
   incorporated.

3.1.  Device Enrollment Query

   TODO - define well known COAP URL on MotherShip that the Device uses
   to get information about Controller.

3.2.  JSON Enrollment States

   TODO - Define a JSON object with Device URN, Device public key or
   fingerprint, and enrollment state.

3.3.  Controller Enrollment Messages

   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.

3.4.  MotherShip ID and URLs

   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.






Jennings                 Expires April 16, 2013                 [Page 8]


Internet-Draft         Transitive Trust Enrollment          October 2012


4.  Security Considerations

   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.


5.  Variations

5.1.  LED Based Enrollment

   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.




Jennings                 Expires April 16, 2013                 [Page 9]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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?

5.2.  Bulk Enrollment

   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.

5.3.  No Public Key Crypto

   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.


6.  Open Issues

   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?


7.  IANA Considerations

   TODO - create registry for the top byte of MotherShip ID

   TODO register .well-known HTTP URL


8.  Acknowledgments

   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



Jennings                 Expires April 16, 2013                [Page 10]


Internet-Draft         Transitive Trust Enrollment          October 2012


   comments:  Eric Rescorla


9.  References

9.1.  Normative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-08 (work in progress), October 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [I-D.arkko-core-dev-urn]
              Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
              Names for Device Identifiers", draft-arkko-core-dev-urn-01
              (work in progress), October 2011.


Author's Address

   Cullen Jennings
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone:  +1 408 421-9990
   Email:  fluffy@cisco.com


















Jennings                 Expires April 16, 2013                [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/