One document matched: draft-oflynn-6lowapp-bootstrapping-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY RFC4919 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY RFC5548 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5548.xml">
<!ENTITY RFC5673 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5673.xml">
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-oflynn-6lowapp-bootstrapping-00" ipr="trust200811">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="draft-bootstrapping">Initial Configuration of Resource-Constrained Devices</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Colin Patrick O'Flynn" initials="C.O."
surname="O'Flynn">
<organization>Atmel Corporation</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Colorado Springs</city>
<region>Colorado</region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>colin.oflynn@atmel.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="January" year="2010" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>6lowapp</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>6lowpan</keyword>
<keyword>resource constrained</keyword>
<keyword>802.15.4</keyword>
<keyword>bootstrapping</keyword>
<keyword>commissioning</keyword>
<keyword>configuration</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.</t>
<t>
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.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="RFC4919">RFC 4919</xref>
from 6LoWPAN, <xref target="RFC5548">RFC 5548</xref> from
ROLL, and <xref target="RFC5673">RFC 5673</xref> from ROLL, and a paper by
<xref target="ROMER04">Romer and Mattern</xref>. Familarity with application
specific examples is also useful, such as Zigbee or Smart Energy groups.</t>
<t>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.</t>
<t>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. </t>
<t>
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.
</t>
<section title="What is Bootstrapping?">
<t>
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).
</t>
<t>
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.
</t>
</section>
<section title="Why IETF?">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Why a New Standard?">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section anchor="config_examples" title="Examples of Node Configuration">
<t>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.
</t>
<section title="Smart Energy">
<section title="Initial Meter Installation">
<t>
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.
</t>
</section>
<section title="Home Expansions">
<t>
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.
</t>
</section>
</section>
<section title="Consumer Products">
<section title="Connecting DVD Remote to DVD Player">
<t>
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.
</t>
</section>
<section title="Adding a TV to a network with a DVD player and remote">
<t>
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.
</t>
</section>
<section title="Providing GPS Location Data">
<t>
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.
</t>
</section>
</section>
<section title="Commercial Building Automation">
<section title="Light Installation">
<t>
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.
</t>
</section>
</section>
</section>
<section title="Background and Requirements">
<section title="Requirements">
<section title="IETF Requirements">
<t>
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.
</t>
<t>
<xref target="RFC5673">RFC 5673</xref> 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.
</t>
<t>
<xref target="RFC5548">RFC 5548</xref> 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.
</t>
<t>
<xref target="RFC4919">RFC 4919</xref> 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.
</t>
<t>
Security requirements and recommendations are found in a variety of IETF
sources. <xref target="RFC3748">RFC 3748</xref> section 7.1 defines
security considerations for EAP. A more focused look at LoWPAN-style
network considerations is provided in
<xref target="DRAFTSTRUIK">draft-struik-6lowapp-security-considerations</xref>.
</t>
</section>
<section title="Generic Requirements">
<t>
Several examples from different application spaces will be presented. This
will help to furthur guide requirements.
</t>
<section title="Merging">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Mobility">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Resources">
<t>
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.
</t>
</section>
<section title="User Interface">
<t>
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.
</t>
</section>
<section title="Security">
<t>
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.
</t>
<t>
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.
</t>
<t>
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'.
</t>
</section>
</section>
<section title="Requirement Summary">
<t>
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.
</t>
<t>
<list style="symbols">
<t>Works from any node authorized to do so by the network. In
simple networks this might be any end node.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<section title="Considerations of Requirements">
<section title="Resources">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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 <xref target="RFC3552">RFC 3552</xref>. A more detailed description
of problems facing these networks is found in <xref target="DRAFTSTRUIK">
draft-struik-6lowapp-security-considerations</xref>.
</t>
<t>
Specific attacks of interest for bootstrapping are passive attacks,
active attacks, and timing attacks. Each will be considered in sequence.
</t>
<section title="Passive Attacks">
<t>
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.
</t>
</section>
<section title="Active Attacks">
<t>
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.
</t>
</section>
<section title="Timing Attack">
<t>
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.
</t>
</section>
</section>
</section>
<section title="Existing Solutions">
<t>
There are a number of existing solutions presented. This section outlines
them, and why they are not suited to be adopted as-is.
</t>
<section title="Device Label">
<t>
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.
<xref target="WPS">The
printer is now allowed on the network securely.</xref>
</t>
<t>
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.
</t>
<t>ADVANTAGES:<list style="symbols">
<t>Simple, requires no extra hardware on end nodes.</t>
<t>Machine readable barcodes would assist in deploying large numbers of
nodes. They could just be scanned before being deployed.</t>
<t>Fairly secure.</t>
</list></t>
<t>DISADVANTAGES:<list style="symbols">
<t>Extra cost of labels and ensuring the labels match any preprogrammed information.</t>
<t>Requires one node on network to have advanced user interface.</t>
<t>OOB is one-way only.</t>
</list></t>
</section>
<section title="Ressurecting Duckling">
<t>
This method simply works because some 'mother' node is present
near the first operation of the end node. <xref target="STAJANO99">
As an example, when
a remote control is powered up, it simply associates with the
nearby TV </xref>. This is very intuitive to the end user.
</t>
<t>
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.
</t>
<t>ADVANTAGES:<list style="symbols">
<t>Simple, requires no extra hardware on end nodes.</t>
<t>Very intuitive to end users.</t>
</list></t>
<t>DISADVANTAGES:<list style="symbols">
<t>Requires at least one node to be special (aka: mother).</t>
<t>Could not handle a network merge.</t>
<t>Hard for use to ensure node connects to a specific 'mother'
node, when multiple mothers are present.</t>
</list></t>
</section>
<section title="Button Press">
<t>
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
<xref target="RF4CE">RF4CE</xref> uses this method.
</t>
<t>ADVANTAGES:<list style="symbols">
<t>Simple, most nodes probably have hardware already to run protocol.</t>
<t>Very intuitive to end users.</t>
<t>Can work with a 'merge' algorithm. </t>
</list></t>
<t>DISADVANTAGES:<list style="symbols">
<t>Low security.</t>
</list></t>
</section>
<section title="Out Of Band (OOB) Wireless">
<t>
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.
</t>
<t>ADVANTAGES:<list style="symbols">
<t>Very secure (provided OOB channel is secure).</t>
<t>Intuitive to end users - just touch two nodes together.</t>
<t>Can work with a 'merge' algorithm. </t>
<t>Functions in hostile / intristically safe environments</t>
</list></t>
<t>DISADVANTAGES:<list style="symbols">
<t>Requires additional hardware on end nodes, with associated
cost and power requirements.</t>
</list></t>
</section>
<section title="Out Of Band (OOB) Physical">
<t>
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.
</t>
<t>ADVANTAGES:<list style="symbols">
<t>No-cost solution as all nodes require this interface anyway.</t>
<t>Intuitive to end users - just connect two nodes together.</t>
<t>Can work with almost any network configuration. </t>
<t>Can provide power to end nodes.</t>
</list></t>
<t>DISADVANTAGES:<list style="symbols">
<t>No current standard used between nodes.</t>
</list></t>
</section>
</section>
</section>
<section title="Bootstrapping Architecture">
<t>
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'.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<figure anchor='figure_architecture'>
<preamble>Consider the following diagram showing the interaction between these sections:</preamble>
<artwork><![CDATA[
+-----------+ +-----------+
| Bootstrap | | User |
| Profile | | Interface |
+-----+-----+ +-----+-----+
^ ^
| |
+--------+ |
| |
| |
+-----------+ | |
| Security | | v
| Method | | +----+--------+
+-------+---+ | | |
^ +-->+ Bootstrap |
| | |
+--------->+ Protocol |
| |
+-----+-------+
^
|
v
+-----+-----+
| Bootstrap |
| Transport |
| Layer |
+-----------+
]]></artwork>
</figure>
</section>
<section title="User Interfaces">
<t>
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.
</t>
<section title="Required Functions">
<section title="User Feedback: Identify Node">
<t>
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.
</t>
</section>
<section title="User Feedback: Confirm Authentication Data to User">
<t>
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 <xref target="BSSP">Secure Simple Pairing's</xref> numeric comparison .
</t>
</section>
<section title="User Feedback: FAILED">
<t>
Alerts the user to a failed bootstrap attempt.
</t>
</section>
<section title="User Feedback: OK">
<t>
Alerts the user to a successful bootstrap attempt.
</t>
</section>
<section title="User Request: Disconnect from Network & Clears">
<t>
This disconnects the node from the network, and clears settings back to a factory-default
configuration.
</t>
</section>
<section title="User Request: Scan for Network to Join">
<t>
This enters the 'join' mode on an end node, scanning for a network in 'advertise' mode.
</t>
</section>
<section title="User Request: Advertise Network">
<t>
This mode advertises the current running network. If no network is running, the
node may start a new network.
</t>
</section>
</section>
<section title="Example User Interface Profiles">
<t>
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.
</t>
<section title="No-Interface End Node">
<t>
A no-interface end node has no method of user interaction.
</t>
</section>
<section title="Minimal-Interface End Node">
<t>
A minimal-interface node has a single LED and single button.
</t>
<section title="Identify Node">
<t>
The LED blinks.
</t>
</section>
<section title="Confirm Authentication Data with User">
<t>
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.
</t>
</section>
<section title="Button Input">
<t>
The button controls all available user requests.
</t>
<t>
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.
</t>
<t>
If the button is held down for X seconds, the user is requesting a Disconnect/Memory Clear.
</t>
</section>
</section>
<section title="Numerical-Interface End Node">
<t>
A numerical-interface end node has a display capable of displaying at least 6 numbers
</t>
<section title="Confirm Authentication Data with User">
<t>
A number is calculated based on the crypto data. Example: Bluebooth Secure Simple Pairing.
</t>
</section>
</section>
<section title="Alphanumeric-Interface End Node">
<t>
A numerical-interface end node has a display capable of displaying up to 24 characters.
</t>
<section title="Confirm Authentication Data with User">
<t>
A character string is calculated based on the crypto data.
</t>
</section>
</section>
</section>
</section>
<section title="Bootstrap Profiles">
<t>
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.
</t>
<t>
Specifics TBD.
</t>
</section>
<section title="Bootstrap Transport Layers">
<t>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. </t>
<t>
Specifics TBD.
</t>
</section>
<section title="Bootstrap Security Method">
<t>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.
</t>
<section title="None">
<t>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.
</t>
</section>
<section title="EAP-PSK">
<t>EAP-PSK is used as the authentication method. Keys must be pre-shared through some other method.
</t>
</section>
<section title="Asymmetric with User Authentication, Followed by Symmetric">
<t>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.
</t>
</section>
<section title="Asymmetric with Certificate Authority, Followed by Symmetric">
<t>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.
</t>
</section>
</section>
<section title="Bootstrap Protocol">
<t>
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.
</t>
<t>
Specifics TBD.
</t>
</section>
<section title="Example Exchanges">
<t>
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 <xref target="config_examples"/>.
</t>
<section title="Smart Energy: Meter Manufacture">
</section>
<section title="Smart Energy: Meter Installation">
</section>
<section title="Smart Energy: Home Expansion">
</section>
<section title="Consumer: Connecting DVD Remote to DVD Player">
<texttable>
<preamble>Supported User Interface Profiles</preamble>
<ttcol align='center'>Profile</ttcol>
<ttcol align='center'>DVD Player</ttcol>
<ttcol align='center'>Remote Control</ttcol>
<c>none</c>
<c>Y</c>
<c>Y</c>
<c>simple</c>
<c>Y</c>
<c>Y</c>
<c>numerical</c>
<c>Y</c>
<c>N</c>
<c>alphanumerical</c>
<c>Y</c>
<c>N</c>
<c>Graphical</c>
<c>Y</c>
<c>N</c>
</texttable>
<texttable>
<preamble>Supported Bootstrap Transport Layers</preamble>
<ttcol align='center'>Layer</ttcol>
<ttcol align='center'>DVD Player</ttcol>
<ttcol align='center'>Remote Control</ttcol>
<c>Physical</c>
<c>Y</c>
<c>Y</c>
<c>802.15.4</c>
<c>Y</c>
<c>Y</c>
<c>IrDA</c>
<c>Y</c>
<c>N</c>
</texttable>
<texttable>
<preamble>Supported Security Methods</preamble>
<ttcol align='center'>Method</ttcol>
<ttcol align='center'>DVD Player</ttcol>
<ttcol align='center'>Remote Control</ttcol>
<c>None</c>
<c>Y</c>
<c>Y</c>
<c>EAP-PSK</c>
<c>Y</c>
<c>N</c>
<c>Asymmetric, User</c>
<c>Y</c>
<c>Y</c>
<c>Asymmetric, CA</c>
<c>Y</c>
<c>N</c>
</texttable>
<t>
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.
</t>
<t>
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:
<list style="symbols">
<t>DVD Player scans for existing network in advertise mode. Finding none,
it starts a new network and that network enters advertise mode.</t>
<t>The DVD remote scans for a network, and then finds the DVD player's network.</t>
<t>The devices generate a shared secret, and both blink their LED in a unique pattern.</t>
<t>The user user confirms both devices are blinking the same pattern, as both LEDs are
blinking in unison.</t>
<t>The DVD player displays 'JOIN OK' on it's LCD panel.</t>
</list>
</t>
</section>
<section title="Consumer: Adding a TV to a network with a DVD player and remote">
<t>
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.
</t>
<texttable>
<preamble>Supported User Interface Profiles</preamble>
<ttcol align='center'>Profile</ttcol>
<ttcol align='center'>TV</ttcol>
<ttcol align='center'>Remote Control</ttcol>
<c>none</c>
<c>Y</c>
<c>Y</c>
<c>simple</c>
<c>Y</c>
<c>Y</c>
<c>numerical</c>
<c>Y</c>
<c>N</c>
<c>alphanumerical</c>
<c>Y</c>
<c>N</c>
<c>Graphical</c>
<c>Y</c>
<c>N</c>
</texttable>
<texttable>
<preamble>Supported Bootstrap Transport Layers</preamble>
<ttcol align='center'>Layer</ttcol>
<ttcol align='center'>TV</ttcol>
<ttcol align='center'>Remote Control</ttcol>
<c>Physical</c>
<c>Y</c>
<c>Y</c>
<c>802.15.4</c>
<c>Y</c>
<c>Y</c>
<c>IrDA</c>
<c>Y</c>
<c>N</c>
</texttable>
<texttable>
<preamble>Supported Security Methods</preamble>
<ttcol align='center'>Method</ttcol>
<ttcol align='center'>TV</ttcol>
<ttcol align='center'>Remote Control</ttcol>
<c>None</c>
<c>Y</c>
<c>Y</c>
<c>EAP-PSK</c>
<c>Y</c>
<c>N</c>
<c>Asymmetric, User</c>
<c>Y</c>
<c>Y</c>
<c>Asymmetric, CA</c>
<c>Y</c>
<c>N</c>
</texttable>
<t>
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.
</t>
<t>
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.
</t>
<t>
If the TV join button is pressed first:
<list style="symbols">
<t>TV scans for existing networks in advertise mode. Finding none,
it starts a new network and that network enters advertise mode.</t>
<t>The remote scans for a network, and then finds the TV's network.</t>
<t>The remote informs the TV it is on an existing network, and thus will require the TV
to join this network.</t>
<t>The devices generate a shared secret, and both blink their LED in a unique pattern.</t>
<t>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.</t>
<t>The user confirms both devices are blinking the same pattern, as both LEDs are
blinking in unison.</t>
<t>The TV displays 'JOIN OK' onscreen, along with any information about the network it just
joined.</t>
</list>
If the remote control join button is pressed first:
<list style="symbols">
<t>Remote control scans for existing networks in advertise mode. Finding none,
it advertises it's network.</t>
<t>The TV scans for a network, and then finds the remote control's network.</t>
<t>The devices generate a shared secret, and both blink their LED in a unique pattern.</t>
<t>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.</t>
<t>The user confirms both devices are blinking the same pattern, as both LEDs are
blinking in unison.</t>
<t>The TV displays 'JOIN OK' onscreen, along with any information about the network it just
joined.</t>
</list>
</t>
</section>
<section title="Consumer: Providing GPS Location Data">
</section>
<section title="Commercial: Building Automation">
</section>
</section>
<section title="Conclusion">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Contributors">
<t>
Initial draft by Colin O'Flynn. Thanks to Zach Shelby for editing,
comments, and overall assistance.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> 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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC4919;
&RFC5548;
&RFC5673;
&RFC2119;
&RFC3748;
<reference anchor="DRAFTSTRUIK">
<front>
<title>Security Architectural Design Considerations for Low-Power Wireless Sensor Networks</title>
<author initials="R." surname="Struik">
<organization>Certicom Corp.</organization>
</author>
<date year="2009" month="Oct" day="19"/>
</front>
<format type='HTML' target="http://tools.ietf.org/html/draft-struik-6lowapp-security-considerations"/>
</reference>
<reference anchor="ROMER04">
<front>
<title>The design space of wireless sensor networks</title>
<author initials="K.R." surname="Romer">
<organization></organization>
</author>
<author initials="F.M." surname="Mattern">
</author>
<date year="2004" month="December" />
</front>
<seriesInfo name="IEEE" value="Wireless Communications"/>
<seriesInfo name="vol." value="11"/>
<seriesInfo name="no." value="6"/>
<seriesInfo name="pp." value="54-61"/>
</reference>
<reference anchor="STAJANO99">
<front>
<title>The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks</title>
<author initials="F.S." surname="Stajano">
<organization></organization>
</author>
<author initials="A.R." surname="Anderson">
</author>
<date year="1999"/>
</front>
<seriesInfo name="Proceedings of the 7th International Workshop on Security Protocols" value=""/>
<seriesInfo name="LNCS" value=""/>
<seriesInfo name="vol." value="1796"/>
<seriesInfo name="pp." value="172-194"/>
</reference>
<reference anchor="GIZMODO">
<front>
<title>Confessions: The Meanest Thing Gizmodo Did at CES</title>
<author>
<organization>Gizmodo</organization>
</author>
<date year="2008" month="January" day="10"/>
</front>
<format type='HTML' target="http://gizmodo.com/343348/confessions-the-meanest-thing-gizmodo-did-at-ces"/>
</reference>
<reference anchor="WPS">
<front>
<title>Wi-Fi Protected Setup Specification v1.0</title>
<author>
<organization>Wi-Fi Alliance</organization>
</author>
<date year="2007"/>
</front>
</reference>
<reference anchor="BSSP">
<front>
<title>Bluetooth Secure Simple Pairing Whitepaper</title>
<author>
<organization>Bluetooth Special Interest Group</organization>
</author>
<date year="2006" month="August" day="3" />
</front>
<format type='HTML' target="http://www.bluetooth.com/NR/rdonlyres/0A0B3F36-D15F-4470-85A6-F2CCFA26F70F/0/SimplePairing_WP_V10r00.pdf" />
</reference>
<reference anchor="RF4CE">
<front>
<title>Zigbee RF4CE Specification Version 1.00</title>
<author>
<organization>ZigBee Alliance</organization>
</author>
<date year="2009" month="March" day="17"/>
</front>
<format type='HTML' target="http://www.zigbee.org/ZigBeeRF4CESpeciification/tabid/464/Default.aspx"/>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC3552;
&I-D.narten-iana-considerations-rfc2434bis;
</references>
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
<!-- Change Log
v00 2009-12-07 CPO Initial Version
v01 2009-12-19 CPO Added more references, cleaned up
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:44:24 |