Initial Configuration of Resource-Constrained Devices
draft-oflynn-6lowapp-bootstrapping-00

Abstract

The Internet of Things is marching it's way towards completition. 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 operationg 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 to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 31, 2010.

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

Table of Contents

1.  Introduction
    1.1.  What is Bootstrapping?
    1.2.  Why IETF?
    1.3.  Why a New Standard?
2.  Examples of Node Configuration
    2.1.  Smart Energy
        2.1.1.  Initial Meter Installation
        2.1.2.  Home Expansions
    2.2.  Consumer Products
        2.2.1.  Connecting DVD Remote to DVD Player
        2.2.2.  Adding a TV to a network with a DVD player and remote
        2.2.3.  Providing GPS Location Data
    2.3.  Commercial Building Automation
        2.3.1.  Light Installation
3.  Background and Requirements
    3.1.  Requirements
        3.1.1.  IETF Requirements
        3.1.2.  Generic Requirements
            3.1.2.1.  Merging
            3.1.2.2.  Mobility
            3.1.2.3.  Resources
            3.1.2.4.  User Interface
            3.1.2.5.  Security
        3.1.3.  Requirement Summary
    3.2.  Considerations of Requirements
        3.2.1.  Resources
        3.2.2.  Security Considerations
            3.2.2.1.  Passive Attacks
            3.2.2.2.  Active Attacks
            3.2.2.3.  Timing Attack
    3.3.  Existing Solutions
        3.3.1.  Device Label
        3.3.2.  Ressurecting Duckling
        3.3.3.  Button Press
        3.3.4.  Out Of Band (OOB) Wireless
        3.3.5.  Out Of Band (OOB) Physical
4.  Bootstrapping Architecture
5.  User Interfaces
    5.1.  Required Functions
        5.1.1.  User Feedback: Identify Node
        5.1.2.  User Feedback: Confirm Authentication Data to User
        5.1.3.  User Feedback: FAILED
        5.1.4.  User Feedback: OK
        5.1.5.  User Request: Disconnect from Network & Clears
        5.1.6.  User Request: Scan for Network to Join
        5.1.7.  User Request: Advertise Network
    5.2.  Example User Interface Profiles
        5.2.1.  No-Interface End Node
        5.2.2.  Minimal-Interface End Node
            5.2.2.1.  Identify Node
            5.2.2.2.  Confirm Authentication Data with User
            5.2.2.3.  Button Input
        5.2.3.  Numerical-Interface End Node
            5.2.3.1.  Confirm Authentication Data with User
        5.2.4.  Alphanumeric-Interface End Node
            5.2.4.1.  Confirm Authentication Data with User
6.  Bootstrap Profiles
7.  Bootstrap Transport Layers
8.  Bootstrap Security Method
    8.1.  None
    8.2.  EAP-PSK
    8.3.  Asymmetric with User Authentication, Followed by Symmetric
    8.4.  Asymmetric with Certificate Authority, Followed by Symmetric
9.  Bootstrap Protocol
10.  Example Exchanges
    10.1.  Smart Energy: Meter Manufacture
    10.2.  Smart Energy: Meter Installation
    10.3.  Smart Energy: Home Expansion
    10.4.  Consumer: Connecting DVD Remote to DVD Player
    10.5.  Consumer: Adding a TV to a network with a DVD player and remote
    10.6.  Consumer: Providing GPS Location Data
    10.7.  Commercial: Building Automation
11.  Conclusion
12.  Contributors
13.  IANA Considerations
14.  References
    14.1.  Normative References
    14.2.  Informative References
Appendix A.  Additional Stuff
§  Author's Address

1.  Introduction

Familiarity with constrained network types is assumed here. Documents produced in the 6LoWPAN, ROLL, and 6LoWAPP Working Groups (WGs) would be a useful reference for the reader. In particular RFC 4919 (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.) [RFC4919] from 6LoWPAN, RFC 5548 (Dohler, M., Watteyne, T., Winter, T., and D. Barthel, “Routing Requirements for Urban Low-Power and Lossy Networks,” May 2009.) [RFC5548] from ROLL, and RFC 5673 (Pister, K., Thubert, P., Dwars, S., and T. Phinney, “Industrial Routing Requirements in Low-Power and Lossy Networks,” October 2009.) [RFC5673] from ROLL, and a paper by Romer and Mattern (Romer, K. and F. Mattern, “The design space of wireless sensor networks,” December 2004.) [ROMER04]. Familarity 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 (ie: wireless channels, link-layer encryption keys) to application-layer information (ie: network names, application encryption keys).

Bootstrapping is complete when a secure link is established between a node which the user chooses and a network the user chooses. This secure link may not be the same link used durign normal network operation, but must exist for the purpose of bootstrapping.

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. However without a standard method of nodes discovering each other, nodes will not be able to directly communicate.

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 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 (ie: EAP), but some guidance on their use is required to ensure all implementations interoperate.

2.  Examples of Node Configuration

Before any detail on methods is explored, the following section will detail the various situations 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 what the ideal final solution should work like. These are simple examples only, and are not intended to limit the options.

2.1.  Smart Energy

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

2.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 securly joined the network.

2.2.  Consumer Products

2.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 this, and the two devices are now joined together.

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

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

2.3.  Commercial Building Automation

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

3.  Background and Requirements

3.1.  Requirements

3.1.1.  IETF Requirements

Analysing some of the previous RFCs will highlight requirements which are defined in the applicable RFC. For the bootstrapping protocol to remain consistent with these RFCs, support MUST be carried forward.

RFC 5673 (Pister, K., Thubert, P., Dwars, S., and T. Phinney, “Industrial Routing Requirements in Low-Power and Lossy Networks,” October 2009.) [RFC5673] defines routing requirements for using lossy networks in industrial environments. Section 10 in particular deals with network management. The protocol requires that some form of external configuration is present. In addition it strongly suggests that nodes can be configured over the air, however it does allow for information such as security tokens or communication frequencies to be pre-distributed in nodes.

RFC 5548 (Dohler, M., Watteyne, T., Winter, T., and D. Barthel, “Routing Requirements for Urban Low-Power and Lossy Networks,” May 2009.) [RFC5548] defines routing requirements for using lossy networks in urban environments. Section 4.1 deals with the deployment of nodes. It is noted that nodes will be deployed in networks of hundreds to thousands at once most likely. The configuration must remain flexible enough to support these mass roll-outs without significant overhead.

RFC 4919 (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.) [RFC4919] defines considerations for a 6LoWPAN network. This includes the idea that network bootstrapping should be easy to perform, and able to work "out of the box". This suggests the bootstrapping procedure should be as autonomous as possible.

Security requirements and recommendations are found in a variety of IETF sources. RFC 3748 (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) [RFC3748] section 7.1 defines security considerations for EAP. A more focused look at LoWPAN-style network considerations is provided in draft-struik-6lowapp-security-considerations (Struik, R., “Security Architectural Design Considerations for Low-Power Wireless Sensor Networks,” Oct 2009.) [DRAFTSTRUIK].

3.1.2.  Generic Requirements

Several examples from different application spaces will be presented. This will help to furthur guide requirements.

3.1.2.1.  Merging

When setting up a network, many networks may be 'accidently' set up. Consider the use who brings home a blister-pack of a wireless light switch and light. The manufacture is not aware of the environment the user will install this in; they do not know if an existing network is present. The best 'user experience' is given if the light node starts a new network, and the switch node looks for that network to join. This guarantees that the switch and light work perfectly, but does not ensure that the new switch and light become part of any existing network in the users house.

This is further complicated by the fact the user may not care that two separate networks have been formed. However later when they wish to control all the lights in the house with a central switch, the user wishes all the nodes to be on a single network. Similar situations could be imagined when using remote controls for home entertainment; each device such as the DVD player or TV may form a separate network. The user wishes one remote control to be used on both the TV and DVD player, and does not care about how this occurs.

As users realize the power of combining networks this will become more prevalent. For example initially a company may set up separate HVAC, security, and lighting networks. Later they realize that temperatures in rooms could be automatically adjusted by detecting if anyone is present, which requires input from the security and lighting networks. It is not realistic to switch every node manually over to another network, some form of combining networks is required.

3.1.2.2.  Mobility

Nodes will naturally be mobile; either by design in networks such as asset tracking, or by accident when nodes are broken. If a node needs to be replaced, the question is how easily can this be done.

An extension of this mobility requirement is that the networks may not have any central authority. Pure mesh networks are one example of this. Other networks may have a central authority, but this node might be elected by the network. The end user does not know which node is the coordinator, hence the bootstrapping protocol cannot require the user to perform an action on the central authority.

3.1.2.3.  Resources

The extreme resource constraints of the nodes provides further problems. These resource constraints include cost, memory requirements, power requirements, and size requirements. These are not consistent either: some nodes may have parasitic power measured in micro-amps, but some nodes may be directly connected to the power grid. Likewise some nodes may have a tiny 8-bit microcontroller, but other nodes will have 32-bit microcontrollers running Linux. The bootstrapping process must take into account the wide range of resource constraints. The protocol should run on a tiny end node, while not making itself useless on a larger end node.

3.1.2.4.  User Interface

The user interface will also be constrained. Typical user interfaces may be limited to a push-button and a few LEDs. More advanced nodes may have graphical displays and keyboards, however the bootstrapping process should not assume such nodes are available.

3.1.2.5.  Security

Security of any network is important. The level of security required depends on a number of network parameters including what would happen if unauthorized access occurred, how easily attacks could occur, and the difficulty of tracing attackers. Some networks would require obvious protection, such as parking meters or ATMs. An attacker would have a significant financial incentive to attack such networks, and the cost of unauthorized access is very high.

Less obvious requirements exist when the cost of unauthorized access is low. Someone controlling lights in your house or changing the TV channel has minimal impact financially, and the attacker has almost nothing to gain. However analysis of the other two parameters shows the danger in this attack; the attack is both very easy to perform, and it would be almost impossible to catch the attacker. A similar example occurred at the Consumer Electronics Show (CES) in 2006, where a device was brought in which would cycle through almost every known TV 'off' command, and broadcast it with an IR LED [GIZMODO]. It was used to interrupt vendor demos and presentations, showing the importance of making security part of every network.

A similar consideration exists for Bluetooth; there is very little financial incentive for attacks, but they are easy to perform and it would be difficult to get caught. Bluejacking is the act of sending unsolicited messages to another bluetooth-enabled device such as PDA or phone. No 'security' is broken with Bluejacking, many devices are configured to receive certain messages and prompt the user. This allows two workers with Bluetooth-enabled phones to quickly send contact details to each other for example; a perfect demonstration of the trade-off between 'easy to use' and 'secure'.

3.1.3.  Requirement Summary

From the previous two sections, a summary of the requirements which a bootstrapping protocol should follow can be made. Note these are defining the requirements for the underlying protocol, they do not mean that every implementation works this way. For example in higher security environments node mobility may be disallowed, requiring new nodes to register with a central authority. However such decisions should be 'management' decisions, and not a limitation of the underlying protocol.

• Works from any node authorized to do so by the network. In simple networks this might be any end node.
• Does not rely on nodes being in a specific state. This is required to support network merging, where nodes will already be in a 'configured' state.
• Minimal resource requirements. This means bootstrapping MUST NOT require nodes to contain resources for the sole use of bootstrapping. Again this is a 'management' type decision in that nodes MAY have extra hardware to assist during bootstrapping. This must remain OPTIONAL in the protocol though.
• Secure. The protocol must provide a secure link during network setup if required; the security in use during normal network operation is not in the scope of this document.

3.2.  Considerations of Requirements

3.2.1.  Resources

Resource requirements form the most imposing requirement. Many nodes will have very strict limits on power, size, or cost. For example a node which runs on parasitic power simply cannot afford to use a high-power protocol for node configuration. Thus the protocol must run on the 'lowest common denominator' of available hardware.

A realistic view of the application space shows that several protocols will need to be selected. Protocols which run on a home network may not be appropriate in industrial or medical environments for example. Ideally all nodes would support a 'base' protocol which would allow them to interoperate. This ensures that the market does not become fragmented with incompatible nodes; a user should know that without a doubt two nodes will interoperate.

3.2.2.  Security Considerations

Operation of the network securely is beyond the scope of this document. The bootstrapping problem is only concerned with security during the initial configuration. The bootstrapping protocol MUST provide a secure method of exchanging arbitrary information. This channel needs only to exist during bootstrapping, and for example could include OOB links. General information on network security could be found in RFC 3552 (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) [RFC3552]. A more detailed description of problems facing these networks is found in draft-struik-6lowapp-security-considerations (Struik, R., “Security Architectural Design Considerations for Low-Power Wireless Sensor Networks,” Oct 2009.) [DRAFTSTRUIK].

Specific attacks of interest for bootstrapping are passive attacks, active attacks, and timing attacks. Each will be considered in sequence.

3.2.2.1.  Passive Attacks

RF networks are naturally susceptible to passive listening attacks. Attacks can be performed with a minimum of hardware; for example on Wi-Fi networks this may require only the hardware present in a typical laptop computer. It may be expanded on by a variety of very simple or low-cost antennas. Sending a plain-text password or network key is an example of systems susceptible to passive listening.

3.2.2.2.  Active Attacks

Active attacks require an attacker to perform some manipulation of the target. This could include Man In The Middle (MITM) attacks for example, where an attacker inserts themselves between two nodes when they are initially forming a network. The two nodes think they are directly talking to each other, but instead are talking through a third proxy node.

3.2.2.3.  Timing Attack

Timing attacks are not cryptographic attacks. They instead attack protocols which have a narrow window of opportunity. For example in the push-button protocol the end user presses the button on two nodes which they wish to join. However an attacker could bring a third node close-by, and by pressing the button on this node cause the attackers node to join the network instead.

3.3.  Existing Solutions

There are a number of existing solutions presented. This section outlines them, and why they are not suited to be adopted as-is.

3.3.1.  Device Label

Device labels are used as a form of shared secret. The initial shared secret is exchange by the user, which forms an Out Of Band (OOB) channel. An example given in Wi-Fi Protected Setup (WPS) is as follows: a user brings home a new cell phone. They enter a PIN written on a label on the router. This allows the cell phone to securely join the network. Later when a printer is brought home the user can enter the PIN number written on the printer on the cell phone. The printer is now allowed on the network securely. (Wi-Fi Alliance, “Wi-Fi Protected Setup Specification v1.0,” 2007.) [WPS]

Extensions of the simple device PIN could include machine-readable barcodes. Whereas a device PIN that is entered by a human requires a large label and has limited entropy, using machine-readable barcodes substantially reduces the label size requirements while increasing the amount of information stored.

ADVANTAGES:

• Simple, requires no extra hardware on end nodes.
• Machine readable barcodes would assist in deploying large numbers of nodes. They could just be scanned before being deployed.
• Fairly secure.

DISADVANTAGES:

• Extra cost of labels and ensuring the labels match any preprogrammed information.
• Requires one node on network to have advanced user interface.
• OOB is one-way only.

3.3.2.  Ressurecting Duckling

This method simply works because some 'mother' node is present near the first operation of the end node. As an example, when a remote control is powered up, it simply associates with the nearby TV (Stajano, F. and A. Anderson, “The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks,” 1999.) [STAJANO99]. This is very intuitive to the end user.

To make the node associate with a new mother, it is killed. The node then looks for a new mother. Only the old mother or some 'master' can force this node to associate.

ADVANTAGES:

• Simple, requires no extra hardware on end nodes.
• Very intuitive to end users.

DISADVANTAGES:

• Requires at least one node to be special (aka: mother).
• Could not handle a network merge.
• Hard for use to ensure node connects to a specific 'mother' node, when multiple mothers are present.

3.3.3.  Button Press

A button press is a simple method of making two nodes associate. In the most basic form, a button is pressed on two nodes which should associate. The nodes detect each other's presence, and join up. Button-press is used by WPS, Bluetooth, and other proprietary solutions (such as XBox 360's wireless controllers). ZigBee RF4CE (ZigBee Alliance, “Zigbee RF4CE Specification Version 1.00,” March 2009.) [RF4CE] uses this method.

ADVANTAGES:

• Simple, most nodes probably have hardware already to run protocol.
• Very intuitive to end users.
• Can work with a 'merge' algorithm.

DISADVANTAGES:

• Low security.

3.3.4.  Out Of Band (OOB) Wireless

Some OOB channel is used. Examples could include IrDA or Near Field Communication (NFC). These are typically very short-range to enhance security. The end user simply touches two nodes together for example, which allows the nodes to exchange information.

ADVANTAGES:

• Very secure (provided OOB channel is secure).
• Intuitive to end users - just touch two nodes together.
• Can work with a 'merge' algorithm.
• Functions in hostile / intristically safe environments

DISADVANTAGES:

• Requires additional hardware on end nodes, with associated cost and power requirements.

3.3.5.  Out Of Band (OOB) Physical

All nodes already have a physical channel. This is primarily used to program the node for example, but may also be used to download configuration information to the node.

ADVANTAGES:

• No-cost solution as all nodes require this interface anyway.
• Intuitive to end users - just connect two nodes together.
• Can work with almost any network configuration.
• Can provide power to end nodes.

DISADVANTAGES:

• No current standard used between nodes.

4.  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 'bootstrap transport layer'.

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 in deployment and use of networks.

When bootstrapping is run between two nodes, they communicate using the 'bootstrap transport layer'. If the bootstrapping is In-Band (IB), the 'bootstrap transport layer' (BTL) is the same as the normal operating layer. When the bootstrapping is run Out Of Band (OOB) the BTL is different than the normal network operating layer. A node which is on an 802.15.4 network for instance would use a BTL of 802.15.4 for IB bootstrapping, but perhaps uses 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 BTL and bootstrap profile. For example if the BTL is secure, then a simple clear-text security method is supported. 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 BTL 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 BTL, such as EAP-PSK etc.

Consider the following diagram showing the interaction between these sections:

   +-----------+     +-----------+
   | Bootstrap |     | User      |
   | Profile   |     | Interface |
   +-----+-----+     +-----+-----+
         ^                 ^
         |                 |
         +--------+        |
                  |        |
                  |        |
   +-----------+  |        |
   | Security  |  |        v
   | Method    |  |   +----+--------+
   +-------+---+  |   |             |
           ^      +-->+  Bootstrap  |
           |          |             |
           +--------->+  Protocol   |
                      |             |
                      +-----+-------+
                            ^
                            |
                            v
                      +-----+-----+
                      | Bootstrap |
                      | Transport |
                      | Layer     |
                      +-----------+

5.  User Interfaces

User interfaces provide an interface between the bootstrap protocols and the user. This is used for instance in selecting devices or checking security. The interface must provide a number of functions as defined here.

5.1.  Required Functions

5.1.1.  User Feedback: Identify Node

During a join process, the user will be required to confirm which two nodes are being joined together. For this the 'identify node' function performs an action such as blinking an LED or displaying a message.

5.1.2.  User Feedback: Confirm Authentication Data to User

When performing a Diffie &mdash Hellman style key exchange, some form of authentication is required. This function presents the authentication data to the user, where the user confirms that the expected two devices will be joined. Example: Bluetooth Secure Simple Pairing's (Bluetooth Special Interest Group, “Bluetooth Secure Simple Pairing Whitepaper,” August 2006.) [BSSP] numeric comparison .

5.1.3.  User Feedback: FAILED

Alerts the user to a failed bootstrap attempt.

5.1.4.  User Feedback: OK

Alerts the user to a successful bootstrap attempt.

5.1.5.  User Request: Disconnect from Network & Clears

This disconnects the node from the network, and clears settings back to a factory-default configuration.

5.1.6.  User Request: Scan for Network to Join

This enters the 'join' mode on an end node, scanning for a network in 'advertise' mode.

5.1.7.  User Request: Advertise Network

This mode advertises the current running network. If no network is running, the node may start a new network.

5.2.  Example User Interface Profiles

Parts of the 'required functions' that must agree between end nodes are specified here. For example on nodes which support 'confirm authentication data with user', we need to ensure that both nodes display the same authentication data. Each level higher in the interface hierarchy automatically inherits every profile below it.

5.2.1.  No-Interface End Node

A no-interface end node has no method of user interaction.

5.2.2.  Minimal-Interface End Node

A minimal-interface node has a single LED and single button.

5.2.2.1.  Identify Node

The LED blinks.

5.2.2.2.  Confirm Authentication Data with User

The authentication data will be confirmed by a blink pattern. The user can confirm that both nodes blink in the same pattern, which means both nodes have swapped the correct data. TODO: Specify the exact function used to generate the blink pattern from the crypto data such as public keys, etc. The user confirms the data by pressing the button on the node. If they either do not press the button, or hold the button down for X seconds, they have not confirmed the data and the authentication data will be considered INVALID.

5.2.2.3.  Button Input

The button controls all available user requests.

When the button is pressed, the node automatically performs a scan for other networks in 'advertise' mode. If no networks are found, the node may then switch to 'advertise' mode. This sequence ensures two nodes will *always* find each other if they can communicate at the BTL.

If the button is held down for X seconds, the user is requesting a Disconnect/Memory Clear.

5.2.3.  Numerical-Interface End Node

A numerical-interface end node has a display capable of displaying at least 6 numbers

5.2.3.1.  Confirm Authentication Data with User

A number is calculated based on the crypto data. Example: Bluebooth Secure Simple Pairing.

5.2.4.  Alphanumeric-Interface End Node

A numerical-interface end node has a display capable of displaying up to 24 characters.

5.2.4.1.  Confirm Authentication Data with User

A character string is calculated based on the crypto data.

6.  Bootstrap Profiles

The bootstrapping profile defines what data must be exchanged. A typical application will layer many different profiles together to accomplish the entire bootstrapping process. For instance the link-layer information must be exchanged, which then might be followed by security and application profiles.

Specifics TBD.

7.  Bootstrap Transport Layers

The Bootstrap Transport Layer (BTL) defines the link used to communicate between two nodes. Ensuring two nodes are able to communicate is the job of a specific BTL.

Specifics TBD.

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

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

8.2.  EAP-PSK

EAP-PSK is used as the authentication method. Keys must be pre-shared through some other method.

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

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

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

10.  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 Section 2 (Examples of Node Configuration).

10.1.  Smart Energy: Meter Manufacture

10.2.  Smart Energy: Meter Installation

10.3.  Smart Energy: Home Expansion

10.4.  Consumer: Connecting DVD Remote to DVD Player

Supported User Interface Profiles

Supported Bootstrap Transport Layers

Supported Security Methods

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:

• DVD Player scans for existing network in advertise mode. Finding none, it starts a new network and that network enters advertise mode.
• The DVD remote scans for a network, and then finds the DVD player's network.
• The devices generate a shared secret, and both blink their LED in a unique pattern.
• The user user confirms both devices are blinking the same pattern, as both LEDs are blinking in unison.
• The DVD player displays 'JOIN OK' on it's LCD panel.

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

Supported Bootstrap Transport Layers

Supported Security Methods

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:

• TV scans for existing networks in advertise mode. Finding none, it starts a new network and that network enters advertise mode.
• The remote scans for a network, and then finds the TV's network.
• The remote informs the TV it is on an existing network, and thus will require the TV to join this network.
• The devices generate a shared secret, and both blink their LED in a unique pattern.
• 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.
• The user confirms both devices are blinking the same pattern, as both LEDs are blinking in unison.
• 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:

• Remote control scans for existing networks in advertise mode. Finding none, it advertises it's network.
• The TV scans for a network, and then finds the remote control's network.
• The devices generate a shared secret, and both blink their LED in a unique pattern.
• 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.
• The user confirms both devices are blinking the same pattern, as both LEDs are blinking in unison.
• The TV displays 'JOIN OK' onscreen, along with any information about the network it just joined.

10.6.  Consumer: Providing GPS Location Data

10.7.  Commercial: Building Automation

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

12.  Contributors

Initial draft by Colin O'Flynn. Thanks to Zach Shelby for editing, comments, and overall assistance.

13.  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 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” March 2008.) [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.

14.  References

14.1. Normative References

14.2. Informative References

Appendix A.  Additional Stuff

This becomes an Appendix.

Author's Address