[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [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-01

Abstract

   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.

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



Jennings                 Expires April 16, 2013                 [Page 1]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Enrollment Information Flow  . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  QR Code  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Transfer Agent API . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Create . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Setup  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Bind . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Fetch  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Controller API . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Test Alive . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.2.  Add  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.3.  Sensor Update  . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Variations . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  LED Based Enrollment . . . . . . . . . . . . . . . . . . . 11
     8.2.  Bulk Enrollment  . . . . . . . . . . . . . . . . . . . . . 12
     8.3.  Public Key Crypto  . . . . . . . . . . . . . . . . . . . . 12
   9.  Implementation Notes . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Random Numbers . . . . . . . . . . . . . . . . . . . . . . 12
   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   13. Appendix A: JOSE SHA224-CFB  . . . . . . . . . . . . . . . . . 13
     13.1. Example  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     14.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15










Jennings                 Expires April 16, 2013                 [Page 2]


Internet-Draft         Transitive Trust Enrollment          October 2012


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



Jennings                 Expires April 16, 2013                 [Page 3]


Internet-Draft         Transitive Trust Enrollment          October 2012


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







Jennings                 Expires April 16, 2013                 [Page 4]


Internet-Draft         Transitive Trust Enrollment          October 2012


2.  Enrollment Information Flow

   In the following message flow we use the following definitions:
   TaURL  An http URL that can be used to reach the root resource on the
      Transfer Agent.
   DevURN  A globally unique URN assigned by the Manufacturer to
      uniquely identify this Device.
   OTP  The One Time Password created by the Manufacturer for enrolling
      the Device.
   TaSecret  The secret created by the Manufacturer for the Device to
      communicate with the Transfer Agent.
   DevSecret  The secret created by the Manufacturer for the device to
      communicate with the Controller.
   ContURL  This is a URL that provides the address to reach the
      controller.  It can have a scheme of http, https, coap, or coaps.
   DevLabel  A locally significant string that the Introducer can assign
      to a Device.  For example, the convention for a thermostat in
      building 30, floor 2, 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 user installing the system.

   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



Jennings                 Expires April 16, 2013                 [Page 5]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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?


3.  Terminology

   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.


4.  QR Code

   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



Jennings                 Expires April 16, 2013                 [Page 6]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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.


5.  Transfer Agent API

   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.

5.1.  Create

   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.

   Path:  .well-known/tte1/d/{DevURN}
   Methods:  POST
   Parameters:
      otp:  Base64 encoded version of the OTP
   Return Values:  TODO

   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.

   Example Request:

   POST https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c
             ?otp=88F5EC91493E473B758159C7792C




Jennings                 Expires April 16, 2013                 [Page 7]


Internet-Draft         Transitive Trust Enrollment          October 2012


   Example Response:

   TODO

5.2.  Setup

   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.

   Path:  .well-known/tte1/d/{DevURN}/s
   Methods:  GET
   Parameters:
      otp:  Base64 encoded version of the OTP
   Return Values:  HTML5 web page

   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.

   Example Request:

   GET https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c/s
             ?otp=88F5EC91493E473B758159C7792C

5.3.  Bind

   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.

   Path:  .well-known/tte1/d/{DevURN}/c
   Methods:  PUT
   Parameters:
      otp:  Base64 encoded version of the OTP
      conturl:  URL to controller escaped as necessary for placement in
         a URL






Jennings                 Expires April 16, 2013                 [Page 8]


Internet-Draft         Transitive Trust Enrollment          October 2012


   Return Values:  TODO

   This request using the

   Example Request:

   TODO
   PUT https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c/c
             ?otp=88F5EC91493E473B758159C7792C

5.4.  Fetch

   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.

   Path:  .well-known/tte1/{DevURN}/c
   Methods:  GET
   Parameters:  None
   Success Return Values:  JSON object as defined in TODO that contains
      the encrypted URL to the Controller.
   Error Return Values:  Returns HTTP 404 if the DevID can not be found
      or if the controller URL has not yet been set for this DevURN.

   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.

   Example Request:

   GET https://example.net/.well-known/tte1/d/urn:dev:mac:90a2da001a0c/c

   Example Response:

   TODO


6.  Controller API

   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



Jennings                 Expires April 16, 2013                 [Page 9]


Internet-Draft         Transitive Trust Enrollment          October 2012


   needs to discuss implications.

6.1.  Test Alive

   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.

   Path:  .well-known/tte1/alive
   Methods:  GET
   Parameters:  None
   Return Values:  TODO

6.2.  Add

   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? )

   Path:  .well-known/tte1/c/{DevURN}/k
   Methods:  PUT
   Parameters:
      devSecret:  Base64 encoded version of the secret
      devLabel:
   Return Values:  TODO

6.3.  Sensor Update

   TODO

   Path:  .well-known/tte1/s/{DevURN}/v
   Methods:  PUT
   Parameters:  None
   Body:  Encrypted SENML
   Return Values:  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].


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



Jennings                 Expires April 16, 2013                [Page 10]


Internet-Draft         Transitive Trust Enrollment          October 2012


   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.


8.  Variations

8.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 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?



Jennings                 Expires April 16, 2013                [Page 11]


Internet-Draft         Transitive Trust Enrollment          October 2012


   Could multiple colors of intensity improve the speed of this as this
   is very slow.

8.2.  Bulk Enrollment

   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.

8.3.  Public Key Crypto

   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.


9.  Implementation Notes

   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.

9.1.  Random Numbers

   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



Jennings                 Expires April 16, 2013                [Page 12]


Internet-Draft         Transitive Trust Enrollment          October 2012


   a random number is generated but resets to 0 on reboot.


10.  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 ContURL?


11.  IANA Considerations

   TODO register .well-known/tte1


12.  Acknowledgments

   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.


13.  Appendix A: JOSE SHA224-CFB

   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.





Jennings                 Expires April 16, 2013                [Page 13]


Internet-Draft         Transitive Trust Enrollment          October 2012


13.1.  Example

   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
   }


14.  References

14.1.  Normative References

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

   [I-D.barnes-jose-jsms]
              Barnes, R., "JavaScript Message Security Format",
              draft-barnes-jose-jsms-00 (work in progress), June 2012.

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

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

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.







Jennings                 Expires April 16, 2013                [Page 14]


Internet-Draft         Transitive Trust Enrollment          October 2012


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

   [I-D.jennings-senml]
              Jennings, C., Shelby, Z., and J. Arkko, "Media Types for
              Sensor Markup Language (SENML)", draft-jennings-senml-07
              (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@iii.ca




























Jennings                 Expires April 16, 2013                [Page 15]


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