[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Core                                                          C. O'Flynn
Internet-Draft                                         Atmel Corporation
Intended status: Informational                               B. Sarikaya
Expires: January 13, 2011                                     Huawei USA
                                                               R. Cragie
                                                Pacific Gas and Electric
                                                           July 12, 2010


         Initial Configuration of Resource-Constrained Devices
                   draft-oflynn-core-bootstrapping-01

Abstract

   The Internet of Things is marching its way towards completion.  Nodes
   can use standards from the 6LoWPAN and ROLL WG to achieve IP
   connectivity.  IEEE Standards ensure connectivity at lower layers for
   resource-constrained devices.  Yet a central problem remains at a
   more basic layer without a suitable answer: how to initially
   configure the network.  Without configuration the network never
   advances beyond a large box of nodes.  Current solutions tend to be
   specific to a certain vendor, node type, or application.

   This document outlines exactly what problems are faced in solving
   this problem.  General problems faced in any low-power wireless
   network are outlined first; followed by how these apply to
   bootstrapping.  A selection of currently proposed techniques is
   presented.  From these a more generic approach is presented, which
   can solve the problem for a wide range of situations.

   An emphasis is on performing this bootstrapping in a secure manner.
   This document does not cover operation of the network securely.  This
   document does provide the basis for allowing the network to operate
   securely however, by providing standard methods for key exchanges and
   authentication.

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



O'Flynn, et al.         Expires January 13, 2011                [Page 1]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 13, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
































O'Flynn, et al.         Expires January 13, 2011                [Page 2]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  What is Bootstrapping? . . . . . . . . . . . . . . . . . .  4
     1.2.  Why IETF?  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Why a New Standard?  . . . . . . . . . . . . . . . . . . .  5
   2.  Bootstrapping Architecture . . . . . . . . . . . . . . . . . .  5
   3.  Communications Channel . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Supported Communication Channels . . . . . . . . . . . . .  7
   4.  Bootstrap Security Method  . . . . . . . . . . . . . . . . . .  7
     4.1.  None . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  EAP Methods  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Asymmetric with User Authentication, Followed by
           Symmetric  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  Asymmetric  with Certificate Authority, Followed by
           Symmetric  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.5.  Cryptographically Generated Address Based Address
           Ownership Verification . . . . . . . . . . . . . . . . . .  8
   5.  Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Examples of Node Configuration  . . . . . . . . . . . 11
     A.1.  Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 11
       A.1.1.  Initial Meter Installation . . . . . . . . . . . . . . 11
       A.1.2.  Home Expansions  . . . . . . . . . . . . . . . . . . . 11
     A.2.  Consumer Products  . . . . . . . . . . . . . . . . . . . . 11
       A.2.1.  Connecting DVD Remote to DVD Player  . . . . . . . . . 11
       A.2.2.  Adding a TV to a network with a DVD player and
               remote . . . . . . . . . . . . . . . . . . . . . . . . 12
       A.2.3.  Providing GPS Location Data  . . . . . . . . . . . . . 12
     A.3.  Commercial Building Automation . . . . . . . . . . . . . . 12
       A.3.1.  Light Installation . . . . . . . . . . . . . . . . . . 12
   Appendix B.  Example Exchanges . . . . . . . . . . . . . . . . . . 12
     B.1.  Smart Energy: Meter Manufacture  . . . . . . . . . . . . . 12
     B.2.  Smart Energy: Meter Installation . . . . . . . . . . . . . 12
     B.3.  Smart Energy: Home Expansion . . . . . . . . . . . . . . . 12
     B.4.  Consumer: Connecting DVD Remote to DVD Player  . . . . . . 13
     B.5.  Consumer: Adding a TV to a network with a DVD player
           and remote . . . . . . . . . . . . . . . . . . . . . . . . 14
     B.6.  Consumer: Providing GPS Location Data  . . . . . . . . . . 16
     B.7.  Commercial: Building Automation  . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16



O'Flynn, et al.         Expires January 13, 2011                [Page 3]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


1.  Introduction

   Familiarity with constrained network types is assumed here.
   Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups
   (WGs) would be a useful reference for the reader.  In particular RFC
   4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] and RFC 5673
   [RFC5673] from ROLL, and a paper by Romer and Mattern [ROMER04].
   Familiarity with application specific examples is also useful, such
   as Zigbee or Smart Energy groups.

   A summary of those will be presented, as far as network requirements
   are concerned.  The general network requirements will be further
   concentrated into requirements surrounding only the bootstrapping
   issues.

   A number of solutions which are currently in use will be presented
   and compared to the requirements.  From these the requirements of the
   final solution is identifiable, and a proposal is made on this.

   Note this document has considerable extra information that is not
   designed to be worked into the final I-D.  It also has some example
   specifications of particular applications that would not be present
   in the final version as they are out of scope of the proposed working
   group.  As a general guide they are very useful, but realistically
   will be split off to either another I-D or some other location.

1.1.  What is Bootstrapping?

   Node configuration is known as bootstrapping in this document.
   Bootstrapping is any processing required before the network can
   operate.  Typically this will require a number of settings to be
   transferred between nodes at all layers.  This could include anything
   from link-layer information (i.e., wireless channels, link-layer
   encryption keys) to application-layer information (i.e., network
   names, application encryption keys).

   Bootstrapping is complete when settings have been securely
   transferred prior to normal operation in the network.

1.2.  Why IETF?

   The bootstrapping problem is not specific to any MAC or PHY.  This
   problem exists across any two nodes which have no previous knowledge
   of each other.  In particular, this problem is complicated when the
   nodes are resource-constrained and may not have an advanced user
   interface.  The IETF is instrumental in defining standards which will
   be used by The Internet of Things.  Ensuring these standards can be
   used across nodes and networks requires some form of bootstrapping



O'Flynn, et al.         Expires January 13, 2011                [Page 4]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


   which any node can use.

   Existing standards will be used as much as possible in this document.
   The method proposed here should work across many different underlying
   layers.  It could be used to allow two nodes on the same physical
   network to join at the physical layer, or allow two nodes on an
   incompatible physical network to join at the IPv6 layer.

1.3.  Why a New Standard?

   Simply put, no existing standard brings together all the required
   aspects.  At lower layers, standards exist to solve the problem in
   special cases.  Examples are Wi-Fi Protected Setup, Bluetooth
   Pairing, or ZigBee solutions such as Zigbee RF4CE [RF4CE].  As will
   be discussed later, these are not flexible enough to run on the wide
   variety of nodes which a smart network will use.

   At higher layers, standards exist to perform a secure authentication
   or service discovery.  However these standards almost always assume
   the two nodes have some existing way of communicating, such as being
   plugged into the same network.  This will often not be the case.

   Thus this document is aimed to bridge this gap.  Many existing
   standards can be applied to solve the problem (e.g.  EAP), but some
   guidance on their use is required to ensure all implementations
   interoperate.


2.  Bootstrapping Architecture

   In order to provide a flexible architecture, the bootstrapping method
   is split into five distinct areas.  The five areas are a 'user
   interface', 'bootstrap profile', 'security method', 'bootstrap
   protocol', and the 'communications channel'.

   The user interface provides both user input and user output.  Simple
   nodes may only have a push-button and LED, more complex nodes may
   have a graphical display and keyboard.  The user interface provides
   interaction between the user and bootstrapping methods.  The user
   interface would be used during bootstrapping as an OOB channel.  It
   may also be used to specify bootstrapping policies.

   The user interface provides the interaction between the user and the
   bootstrap protocol.  The user interface will vary depending on the
   capabilities of the node.  Examples might include a push-button and
   LED on simple nodes, to full-blown graphical user interfaces.  Note
   that a 'bootstrapping tool' used to initially deploy a network is
   just a special user interface.  This allows a very uniform protocol



O'Flynn, et al.         Expires January 13, 2011                [Page 5]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


   in deployment and use of networks.

   User interface is out-of-scope and will not be further discussed.

   Two nodes communicate through some channel.  For our purposes this is
   split into the 'control channel' and 'data channel'.  The control
   channel is used for the bootstrap protocol, and the data channel is
   used during normal network operation.  A node may support multiple
   control or data channels.  When the control and data channels are the
   same, the bootstrapping is done In Band (IB).  When the control and
   data channels are different, the bootstrapping is performed Out Of
   Band (OOB).  An 802.15.4 network for instance would use an 802.15.4
   control channel for IB bootstrapping, but a control channel of
   perhaps IrDA or USB for OOB bootstrapping.

   The 'bootstrap profile' defines what information should be exchanged
   during the process.  A single node may run the protocol multiple
   times with different profiles.  If the user wishes to associate a new
   lightswitch, the protocol is first run with the '802.15.4 Wireless
   Profile', through which it learns the channel and PAN-ID.  The node
   then runs a 'Security Exchange Profile' to learn the needed
   encryption keys.  Finally it runs a 'Lightswitch Association Profile'
   through which it learns which light to associate with.

   The 'security method' defines supported security methods for
   bootstrapping.  The supported security methods will depend on the
   control channel and bootstrap profile.  In one node if the control
   channel is secure, then a simple clear-text security method is
   supported.  For example when a physical connection between two nodes
   is used, the control channel is considered secure.  However when the
   BTL is not secure, this clear-text security method is not supported.
   The 'bootstrap profile' additionally defines allowed security
   methods.  Higher security nodes may outlaw ever performing a clear-
   text exchange, even if the control channel is deemed secure.

   The 'bootstrap protocol' defines the actual messages exchanged during
   bootstrapping.  The messages are used to transfer between nodes data,
   node information, and network state.  The selected security method
   runs on top of the control channel, such as EAP-GPSK etc.


3.  Communications Channel

   The communications channel is the method used between two nodes to
   communicate.  There are two main communication channels: the
   'control' and 'data' channels.  The control channel is used during
   bootstrapping, and the data channel is used during network operation.




O'Flynn, et al.         Expires January 13, 2011                [Page 6]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


3.1.  Supported Communication Channels

   There is no limit on what communications channels are supported.  The
   following gives an example of several supported channels:

   o  IEEE 802.15.4

   o  Power-Line Communications

   o  IrDA

   o  RFID

   o  Some simple physical link

   o  Cellular

   o  Ethernet

   o  IPv6

   o  Wi-Fi

   Depending on the node's function, it may use different channels as
   the data or control channel.  Nodes may have multiple data and/or
   control channels as wel.


4.  Bootstrap Security Method

   The bootstrap security method defines allowable security methods.  A
   node may choose to support or use a subset of these methods.  This is
   NOT the security architecture used for the application, but only the
   security used during bootstrapping.  Typically some high-security
   method is used to generate a shared secret, which then switches to
   simplier symmetric encryption to secure the actual bootstrapping
   channel.  The techniques negotiated should take advantage of hardware
   resources available, such as hardware encryption accelerators on an
   end node.

4.1.  None

   This is the simplist security method.  No encryption or
   authentication is provided, messages are exchanged completely in
   clear-text.  It is assumed some other layer provides security, such
   as a physical connection between devices.





O'Flynn, et al.         Expires January 13, 2011                [Page 7]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


4.2.  EAP Methods

   EAP-TLSv1.2 can be used as the authentication method [RFC5246].

   EAP-GPSK can be used as the authentication method [RFC5433].  Keys
   must be pre-shared through some other method.

4.3.  Asymmetric with User Authentication, Followed by Symmetric

   A Diffie-Hellman style key exchange is used to generate a shared
   secret.  The authentication will be provided by the user, by
   confirming cryptographic signatures between two devices.  With the
   shared secret generated through the DH, some symmetric encryption is
   used to secure the actual bootstrapping channel.

4.4.  Asymmetric  with Certificate Authority, Followed by Symmetric

   Public key exchanges are used (aka: DH again), but with a Certificate
   Authority.  Once a shared secret exists, symmetric encryption is used
   to secure the actual bootstrapping channel.

4.5.  Cryptographically Generated Address Based Address Ownership
      Verification

   A node may generate the global unique address using different
   techniques other than the stateless address autoconfiguration.  For
   example, Cryptographically Generated Addresses (CGA) [RFC3972] is a
   type of global unique address that can be used to verify the address
   ownership.  When the node uses CGA, it MUST execute SeND protocol
   [RFC3971].  In a 6LOWPAN network, a modified 6LOWPAN ND Protocol
   [I-D.ietf-6lowpan-nd] must be executed between the node and the edge
   router.


5.  Bootstrap Protocol

   The bootstrap protocol defines several messages which can be sent
   over the BTL.  The bootstrap protocol is a small wrapper around the
   standard authentication functions used, such as EAP etc.  The
   bootstrap protocol will negotiate allowable standards between nodes.
   When a TV is joining a remote control for example, the bootstrap
   protocol must understand that the remote control has very limited
   feedback to the user.  Hence the method selected must not rely on a
   complex user interface on the remote, even though the TV has a
   complex interface available.

   Specifics TBD.




O'Flynn, et al.         Expires January 13, 2011                [Page 8]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


6.  Conclusion

   Initial configuration of a network is essential to interoperability.
   This process is known as bootstrapping, and a variety of solutions
   have been proposed previously.  An analysis of the requirements shows
   that no single solution is likely to meet all the requirements,
   instead multiple solutions will be picked.  At least one of these
   must remain capable of running on the most resource constrained
   nodes, ensuring that all nodes are capable of at least a single
   common communication channel.

   This document helps to focus on a method of solving this problem in a
   flexible and extensible way.  It is very much a work in progress, and
   is expected to undergo radical changes before it becomes complete.
   Please comment on the mailing list or add missing sections as you see
   fit.


7.  Security Considerations

   TBD.


8.  IANA Considerations

   None.


9.  Acknowledgements

   Thanks to Zach Shelby for editing, comments, and overall assistance.


10.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   for a guide).  If the draft does not require IANA to do anything, the
   section contains an explicit statement that this is the case (as
   above).  If there are no requirements for IANA, the section will be
   removed during conversion into an RFC by the RFC Editor.


11.  References





O'Flynn, et al.         Expires January 13, 2011                [Page 9]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


11.1.  Normative References

   [RF4CE]    ZigBee Alliance, "Zigbee RF4CE Specification Version
              1.00", March 2009.

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

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, August 2007.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [ROMER04]  Romer, K. and F. Mattern, "The design space of wireless
              sensor networks", IEEE Wireless Communications, vol. 11,
              no. 6, pp. 54-61, December 2004.

11.2.  Informative References

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
              Discovery Optimization for Low-power and Lossy Networks",
              draft-ietf-6lowpan-nd-10 (work in progress), June 2010.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.



O'Flynn, et al.         Expires January 13, 2011               [Page 10]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5433]  Clancy, T. and H. Tschofenig, "Extensible Authentication
              Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
              RFC 5433, February 2009.


Appendix A.  Examples of Node Configuration

   Before any detail on methods is explored, the following section will
   provide various examples this document could cover.  Exact
   requirements will be brought forward in subsequent sections.  For the
   reader's general understanding this section is placed to give an idea
   of an acceptable usage scenario.

A.1.  Smart Energy

A.1.1.  Initial Meter Installation

   The meter is initially loaded with code and network keys through a
   physical interface at the factory.  The meter is installed at a
   customers home, and configured by the installer through the backbone
   link (via GSM modem, etc).  Both operations can be performed through
   methods defined herein.

A.1.2.  Home Expansions

   The user wishes to join a thermostat onto the network.  They press a
   button on the thermostat, which enters join mode.  They press a
   button on the smart meter, which allows nodes to join the network.
   The devices both have displays, so they display a certain number
   which the user verifies match on both devices.  The thermostat has
   now securely joined the network.

A.2.  Consumer Products

A.2.1.  Connecting DVD Remote to DVD Player

   The user pushes a join button on the DVD remote and DVD player.  The
   devices find each other, and blink in unison to indicate to the user
   which two devices will join.  The user presses the button to confirm



O'Flynn, et al.         Expires January 13, 2011               [Page 11]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


   this, and the two devices are now joined together.

A.2.2.  Adding a TV to a network with a DVD player and remote

   The user then presses the join button on the DVD player and TV.  The
   devices again find each other and blink in unison, with the addition
   that the remote control also blinks to indicate it is present in the
   network.

A.2.3.  Providing GPS Location Data

   A user has a simple GPS receiver (that has no user interface) they
   wish to broadcast location data with.  The user switches on their
   camera, and enters a PIN from the base of the GPS.  The user can now
   view GPS information such as satellite health from their camera.  In
   addition photos are automatically tagged with location information.

A.3.  Commercial Building Automation

A.3.1.  Light Installation

   The electrician installs the light fixture.  Each light has a barcode
   printed on it.  They use a handheld barcode scanner tool, which acts
   as the commissioning tool.  When they scan a barcode with the tool,
   the tool asks the electrician to enter some additional information
   such as light fixture location.  The tool securely registers the
   light fixture on the network, along with setting parameters inside
   the light fixture.


Appendix B.  Example Exchanges

   The following details how the protocol handles certain conditions and
   situations through examples.  Note that each example is a more
   detailed description of the examples in Appendix A.

B.1.  Smart Energy: Meter Manufacture

B.2.  Smart Energy: Meter Installation

B.3.  Smart Energy: Home Expansion










O'Flynn, et al.         Expires January 13, 2011               [Page 12]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


B.4.  Consumer: Connecting DVD Remote to DVD Player

                     Supported User Interface Profiles

             +----------------+------------+----------------+
             |     Profile    | DVD Player | Remote Control |
             +----------------+------------+----------------+
             |      none      |      Y     |        Y       |
             |     simple     |      Y     |        Y       |
             |    numerical   |      Y     |        N       |
             | alphanumerical |      Y     |        N       |
             |    Graphical   |      Y     |        N       |
             +----------------+------------+----------------+

                   Supported Bootstrap Transport Layers

                +----------+------------+----------------+
                |   Layer  | DVD Player | Remote Control |
                +----------+------------+----------------+
                | Physical |      Y     |        Y       |
                | 802.15.4 |      Y     |        Y       |
                |   IrDA   |      Y     |        N       |
                +----------+------------+----------------+

                        Supported Security Methods

            +------------------+------------+----------------+
            |      Method      | DVD Player | Remote Control |
            +------------------+------------+----------------+
            |       None       |      Y     |        Y       |
            |        EAP       |      Y     |        N       |
            | Asymmetric, User |      Y     |        Y       |
            |  Asymmetric, CA  |      Y     |        N       |
            +------------------+------------+----------------+

   The DVD player and remote control have a number of ways in which they
   could be joined together.  The remote control does not have any
   unique identifier printed on it, thus no pre-shared key can be
   identified.  This leaves either an unsecure joining method, or some
   asymmetric security method.

   The remote control has a button on it for 'join', as does the DVD
   player.  The user pushes the button on the DVD player, and then
   pushes the button on the remote control.  Based on the UI profile,
   this causes the following to occur:

   o  DVD Player scans for existing network in advertise mode.  Finding
      none, it starts a new network and that network enters advertise



O'Flynn, et al.         Expires January 13, 2011               [Page 13]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


      mode.

   o  The DVD remote scans for a network, and then finds the DVD
      player's network.

   o  The devices generate a shared secret (ie: Diffie-Hellman), and
      both blink their LED in a unique pattern based on this shared
      secret.

   o  The user user confirms both devices are blinking the same pattern,
      as both LEDs are blinking in unison.

   o  The DVD player displays 'JOIN OK' on it's LCD panel.

B.5.  Consumer: Adding a TV to a network with a DVD player and remote

   This network will have three devices: a TV, a DVD Player, and a
   Remote Control.  The user will run the bootstrap protocol between the
   TV and Remote Control in this example, although it could also be run
   between the TV and DVD player.

                     Supported User Interface Profiles

                 +----------------+----+----------------+
                 |     Profile    | TV | Remote Control |
                 +----------------+----+----------------+
                 |      none      |  Y |        Y       |
                 |     simple     |  Y |        Y       |
                 |    numerical   |  Y |        N       |
                 | alphanumerical |  Y |        N       |
                 |    Graphical   |  Y |        N       |
                 +----------------+----+----------------+

                   Supported Bootstrap Transport Layers

                    +----------+----+----------------+
                    |   Layer  | TV | Remote Control |
                    +----------+----+----------------+
                    | Physical |  Y |        Y       |
                    | 802.15.4 |  Y |        Y       |
                    |   IrDA   |  Y |        N       |
                    +----------+----+----------------+









O'Flynn, et al.         Expires January 13, 2011               [Page 14]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


                        Supported Security Methods

                +------------------+----+----------------+
                |      Method      | TV | Remote Control |
                +------------------+----+----------------+
                |       None       |  Y |        Y       |
                |     EAP-GPSK     |  Y |        N       |
                | Asymmetric, User |  Y |        Y       |
                |  Asymmetric, CA  |  Y |        N       |
                +------------------+----+----------------+

   The TV and remote control have a number of ways in which they could
   be joined together.  The remote control does not have any unique
   identifier printed on it, thus no pre-shared key can be identified.
   This leaves either an unsecure joining method, or some asymmetric
   security method.

   The remote control has a button on it for 'join', as does the TV.  In
   this example two sequence will be considered: where the TV button is
   pressed first, and where the remote control button is pressed first.

   If the TV join button is pressed first:

   o  TV scans for existing networks in advertise mode.  Finding none,
      it starts a new network and that network enters advertise mode.

   o  The remote scans for a network, and then finds the TV's network.

   o  The remote informs the TV it is on an existing network, and thus
      will require the TV to join this network.

   o  The devices generate a shared secret, and both blink their LED in
      a unique pattern.

   o  The DVD player in addition blinks, so the user is informed that if
      they confirm the join action the resulting network will have all
      three devices in it.

   o  The user confirms both devices are blinking the same pattern, as
      both LEDs are blinking in unison.

   o  The TV displays 'JOIN OK' onscreen, along with any information
      about the network it just joined.

   If the remote control join button is pressed first:

   o  Remote control scans for existing networks in advertise mode.
      Finding none, it advertises it's network.



O'Flynn, et al.         Expires January 13, 2011               [Page 15]


Internet-Draft       draft-oflynn-core-bootstrapping           July 2010


   o  The TV scans for a network, and then finds the remote control's
      network.

   o  The devices generate a shared secret, and both blink their LED in
      a unique pattern.

   o  The DVD player in addition blinks, so the user is informed that if
      they confirm the join action the resulting network will have all
      three devices in it.

   o  The user confirms both devices are blinking the same pattern, as
      both LEDs are blinking in unison.

   o  The TV displays 'JOIN OK' onscreen, along with any information
      about the network it just joined.

B.6.  Consumer: Providing GPS Location Data

B.7.  Commercial: Building Automation


Authors' Addresses

   Colin Patrick O'Flynn
   Atmel Corporation
   Colorado Springs, Colorado
   USA

   Phone:
   Email: colin.oflynn@atmel.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Email: sarikaya@ieee.org


   Robert Cragie
   Pacific Gas and Electric
   89 Greenfield Crescent
   Wakefield, UK  WF4 4WA

   Email: robert.cragie@gridmerge.com





O'Flynn, et al.         Expires January 13, 2011               [Page 16]


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