One document matched: draft-oflynn-6lowapp-bootstrapping-00.txt
6lowapp C. O'Flynn
Internet-Draft Atmel Corporation
Intended status: Informational January 27, 2010
Expires: July 31, 2010
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."
O'Flynn Expires July 31, 2010 [Page 1]
Internet-Draft draft-bootstrapping January 2010
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.
O'Flynn Expires July 31, 2010 [Page 2]
Internet-Draft draft-bootstrapping January 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5
1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Why a New Standard? . . . . . . . . . . . . . . . . . . . 6
2. Examples of Node Configuration . . . . . . . . . . . . . . . . 6
2.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Initial Meter Installation . . . . . . . . . . . . . . 6
2.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 7
2.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 7
2.2.2. Adding a TV to a network with a DVD player and
remote . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3. Providing GPS Location Data . . . . . . . . . . . . . 7
2.3. Commercial Building Automation . . . . . . . . . . . . . . 7
2.3.1. Light Installation . . . . . . . . . . . . . . . . . . 7
3. Background and Requirements . . . . . . . . . . . . . . . . . 8
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. IETF Requirements . . . . . . . . . . . . . . . . . . 8
3.1.2. Generic Requirements . . . . . . . . . . . . . . . . . 8
3.1.2.1. Merging . . . . . . . . . . . . . . . . . . . . . 8
3.1.2.2. Mobility . . . . . . . . . . . . . . . . . . . . . 9
3.1.2.3. Resources . . . . . . . . . . . . . . . . . . . . 9
3.1.2.4. User Interface . . . . . . . . . . . . . . . . . . 10
3.1.2.5. Security . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Requirement Summary . . . . . . . . . . . . . . . . . 10
3.2. Considerations of Requirements . . . . . . . . . . . . . . 11
3.2.1. Resources . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Security Considerations . . . . . . . . . . . . . . . 11
3.2.2.1. Passive Attacks . . . . . . . . . . . . . . . . . 12
3.2.2.2. Active Attacks . . . . . . . . . . . . . . . . . . 12
3.2.2.3. Timing Attack . . . . . . . . . . . . . . . . . . 12
3.3. Existing Solutions . . . . . . . . . . . . . . . . . . . . 12
3.3.1. Device Label . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Ressurecting Duckling . . . . . . . . . . . . . . . . 13
3.3.3. Button Press . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Out Of Band (OOB) Wireless . . . . . . . . . . . . . . 14
3.3.5. Out Of Band (OOB) Physical . . . . . . . . . . . . . . 15
4. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 15
5. User Interfaces . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Required Functions . . . . . . . . . . . . . . . . . . . . 17
5.1.1. User Feedback: Identify Node . . . . . . . . . . . . . 18
5.1.2. User Feedback: Confirm Authentication Data to User . . 18
5.1.3. User Feedback: FAILED . . . . . . . . . . . . . . . . 18
5.1.4. User Feedback: OK . . . . . . . . . . . . . . . . . . 18
5.1.5. User Request: Disconnect from Network & Clears . . . . 18
5.1.6. User Request: Scan for Network to Join . . . . . . . . 18
O'Flynn Expires July 31, 2010 [Page 3]
Internet-Draft draft-bootstrapping January 2010
5.1.7. User Request: Advertise Network . . . . . . . . . . . 18
5.2. Example User Interface Profiles . . . . . . . . . . . . . 18
5.2.1. No-Interface End Node . . . . . . . . . . . . . . . . 19
5.2.2. Minimal-Interface End Node . . . . . . . . . . . . . . 19
5.2.2.1. Identify Node . . . . . . . . . . . . . . . . . . 19
5.2.2.2. Confirm Authentication Data with User . . . . . . 19
5.2.2.3. Button Input . . . . . . . . . . . . . . . . . . . 19
5.2.3. Numerical-Interface End Node . . . . . . . . . . . . . 19
5.2.3.1. Confirm Authentication Data with User . . . . . . 19
5.2.4. Alphanumeric-Interface End Node . . . . . . . . . . . 20
5.2.4.1. Confirm Authentication Data with User . . . . . . 20
6. Bootstrap Profiles . . . . . . . . . . . . . . . . . . . . . . 20
7. Bootstrap Transport Layers . . . . . . . . . . . . . . . . . . 20
8. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 20
8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. EAP-PSK . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. Asymmetric with User Authentication, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4. Asymmetric with Certificate Authority, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . . . 21
10. Example Exchanges . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 21
10.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 21
10.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 21
10.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 22
10.5. Consumer: Adding a TV to a network with a DVD player
and remote . . . . . . . . . . . . . . . . . . . . . . . . 23
10.6. Consumer: Providing GPS Location Data . . . . . . . . . . 25
10.7. Commercial: Building Automation . . . . . . . . . . . . . 25
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
O'Flynn Expires July 31, 2010 [Page 4]
Internet-Draft draft-bootstrapping January 2010
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 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] from ROLL, and RFC
5673 [RFC5673] from ROLL, and a paper by Romer and Mattern [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
O'Flynn Expires July 31, 2010 [Page 5]
Internet-Draft draft-bootstrapping January 2010
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.
O'Flynn Expires July 31, 2010 [Page 6]
Internet-Draft draft-bootstrapping January 2010
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.
O'Flynn Expires July 31, 2010 [Page 7]
Internet-Draft draft-bootstrapping January 2010
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 [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 [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 [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 [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 [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
O'Flynn Expires July 31, 2010 [Page 8]
Internet-Draft draft-bootstrapping January 2010
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.
O'Flynn Expires July 31, 2010 [Page 9]
Internet-Draft draft-bootstrapping January 2010
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
O'Flynn Expires July 31, 2010 [Page 10]
Internet-Draft draft-bootstrapping January 2010
underlying protocol.
o Works from any node authorized to do so by the network. In simple
networks this might be any end node.
o 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.
o 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.
o 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 [RFC3552]. A more detailed description of
problems facing these networks is found in
draft-struik-6lowapp-security-considerations [DRAFTSTRUIK].
O'Flynn Expires July 31, 2010 [Page 11]
Internet-Draft draft-bootstrapping January 2010
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. [WPS]
O'Flynn Expires July 31, 2010 [Page 12]
Internet-Draft draft-bootstrapping January 2010
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:
o Simple, requires no extra hardware on end nodes.
o Machine readable barcodes would assist in deploying large numbers
of nodes. They could just be scanned before being deployed.
o Fairly secure.
DISADVANTAGES:
o Extra cost of labels and ensuring the labels match any
preprogrammed information.
o Requires one node on network to have advanced user interface.
o 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
[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:
o Simple, requires no extra hardware on end nodes.
o Very intuitive to end users.
DISADVANTAGES:
o Requires at least one node to be special (aka: mother).
o Could not handle a network merge.
O'Flynn Expires July 31, 2010 [Page 13]
Internet-Draft draft-bootstrapping January 2010
o 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
[RF4CE] uses this method.
ADVANTAGES:
o Simple, most nodes probably have hardware already to run protocol.
o Very intuitive to end users.
o Can work with a 'merge' algorithm.
DISADVANTAGES:
o 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:
o Very secure (provided OOB channel is secure).
o Intuitive to end users - just touch two nodes together.
o Can work with a 'merge' algorithm.
o Functions in hostile / intristically safe environments
DISADVANTAGES:
o Requires additional hardware on end nodes, with associated cost
and power requirements.
O'Flynn Expires July 31, 2010 [Page 14]
Internet-Draft draft-bootstrapping January 2010
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:
o No-cost solution as all nodes require this interface anyway.
o Intuitive to end users - just connect two nodes together.
o Can work with almost any network configuration.
o Can provide power to end nodes.
DISADVANTAGES:
o 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
O'Flynn Expires July 31, 2010 [Page 15]
Internet-Draft draft-bootstrapping January 2010
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.
O'Flynn Expires July 31, 2010 [Page 16]
Internet-Draft draft-bootstrapping January 2010
Consider the following diagram showing the interaction between these
sections:
+-----------+ +-----------+
| Bootstrap | | User |
| Profile | | Interface |
+-----+-----+ +-----+-----+
^ ^
| |
+--------+ |
| |
| |
+-----------+ | |
| Security | | v
| Method | | +----+--------+
+-------+---+ | | |
^ +-->+ Bootstrap |
| | |
+--------->+ Protocol |
| |
+-----+-------+
^
|
v
+-----+-----+
| Bootstrap |
| Transport |
| Layer |
+-----------+
Figure 1
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
O'Flynn Expires July 31, 2010 [Page 17]
Internet-Draft draft-bootstrapping January 2010
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 [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.
O'Flynn Expires July 31, 2010 [Page 18]
Internet-Draft draft-bootstrapping January 2010
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.
O'Flynn Expires July 31, 2010 [Page 19]
Internet-Draft draft-bootstrapping January 2010
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.
O'Flynn Expires July 31, 2010 [Page 20]
Internet-Draft draft-bootstrapping January 2010
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.
10.1. Smart Energy: Meter Manufacture
10.2. Smart Energy: Meter Installation
10.3. Smart Energy: Home Expansion
O'Flynn Expires July 31, 2010 [Page 21]
Internet-Draft draft-bootstrapping January 2010
10.4. Consumer: Connecting DVD Remote to DVD Player
Supported User Interface Profiles
+----------------+------------+----------------+
| Profile | DVD Player | Remote Control |
+----------------+------------+----------------+
| none | Y | Y |
| simple | Y | Y |
| numerical | Y | N |
| alphanumerical | Y | N |
| Graphical | Y | N |
+----------------+------------+----------------+
Supported Bootstrap Transport Layers
+----------+------------+----------------+
| Layer | DVD Player | Remote Control |
+----------+------------+----------------+
| Physical | Y | Y |
| 802.15.4 | Y | Y |
| IrDA | Y | N |
+----------+------------+----------------+
Supported Security Methods
+------------------+------------+----------------+
| Method | DVD Player | Remote Control |
+------------------+------------+----------------+
| None | Y | Y |
| EAP-PSK | Y | N |
| Asymmetric, User | Y | Y |
| Asymmetric, CA | Y | N |
+------------------+------------+----------------+
The DVD player and remote control have a number of ways in which they
could be joined together. The remote control does not have any
unique identifier printed on it, thus no pre-shared key can be
identified. This leaves either an unsecure joining method, or some
asymmetric security method.
The remote control has a button on it for 'join', as does the DVD
player. The user pushes the button on the DVD player, and then
pushes the button on the remote control. Based on the UI profile,
this causes the following to occur:
o DVD Player scans for existing network in advertise mode. Finding
none, it starts a new network and that network enters advertise
O'Flynn Expires July 31, 2010 [Page 22]
Internet-Draft draft-bootstrapping January 2010
mode.
o The DVD remote scans for a network, and then finds the DVD
player's network.
o The devices generate a shared secret, and both blink their LED in
a unique pattern.
o The user user confirms both devices are blinking the same pattern,
as both LEDs are blinking in unison.
o The DVD player displays 'JOIN OK' on it's LCD panel.
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
+----------------+----+----------------+
| Profile | TV | Remote Control |
+----------------+----+----------------+
| none | Y | Y |
| simple | Y | Y |
| numerical | Y | N |
| alphanumerical | Y | N |
| Graphical | Y | N |
+----------------+----+----------------+
Supported Bootstrap Transport Layers
+----------+----+----------------+
| Layer | TV | Remote Control |
+----------+----+----------------+
| Physical | Y | Y |
| 802.15.4 | Y | Y |
| IrDA | Y | N |
+----------+----+----------------+
O'Flynn Expires July 31, 2010 [Page 23]
Internet-Draft draft-bootstrapping January 2010
Supported Security Methods
+------------------+----+----------------+
| Method | TV | Remote Control |
+------------------+----+----------------+
| None | Y | Y |
| EAP-PSK | Y | N |
| Asymmetric, User | Y | Y |
| Asymmetric, CA | Y | N |
+------------------+----+----------------+
The TV and remote control have a number of ways in which they could
be joined together. The remote control does not have any unique
identifier printed on it, thus no pre-shared key can be identified.
This leaves either an unsecure joining method, or some asymmetric
security method.
The remote control has a button on it for 'join', as does the TV. In
this example two sequence will be considered: where the TV button is
pressed first, and where the remote control button is pressed first.
If the TV join button is pressed first:
o TV scans for existing networks in advertise mode. Finding none,
it starts a new network and that network enters advertise mode.
o The remote scans for a network, and then finds the TV's network.
o The remote informs the TV it is on an existing network, and thus
will require the TV to join this network.
o The devices generate a shared secret, and both blink their LED in
a unique pattern.
o The DVD player in addition blinks, so the user is informed that if
they confirm the join action the resulting network will have all
three devices in it.
o The user confirms both devices are blinking the same pattern, as
both LEDs are blinking in unison.
o The TV displays 'JOIN OK' onscreen, along with any information
about the network it just joined.
If the remote control join button is pressed first:
o Remote control scans for existing networks in advertise mode.
Finding none, it advertises it's network.
O'Flynn Expires July 31, 2010 [Page 24]
Internet-Draft draft-bootstrapping January 2010
o The TV scans for a network, and then finds the remote control's
network.
o The devices generate a shared secret, and both blink their LED in
a unique pattern.
o The DVD player in addition blinks, so the user is informed that if
they confirm the join action the resulting network will have all
three devices in it.
o The user confirms both devices are blinking the same pattern, as
both LEDs are blinking in unison.
o The TV displays 'JOIN OK' onscreen, along with any information
about the network it just joined.
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.
O'Flynn Expires July 31, 2010 [Page 25]
Internet-Draft draft-bootstrapping January 2010
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
for a guide). If the draft does not require IANA to do anything, the
section contains an explicit statement that this is the case (as
above). If there are no requirements for IANA, the section will be
removed during conversion into an RFC by the RFC Editor.
14. References
14.1. Normative References
[BSSP] Bluetooth Special Interest Group, "Bluetooth Secure Simple
Pairing Whitepaper", August 2006.
[DRAFTSTRUIK]
Struik, R., "Security Architectural Design Considerations
for Low-Power Wireless Sensor Networks", Oct 2009.
[GIZMODO] Gizmodo, "Confessions: The Meanest Thing Gizmodo Did at
CES", January 2008.
[RF4CE] ZigBee Alliance, "Zigbee RF4CE Specification Version
1.00", March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009.
[ROMER04] Romer, K. and F. Mattern, "The design space of wireless
sensor networks", IEEE Wireless Communications, vol. 11,
no. 6, pp. 54-61, December 2004.
O'Flynn Expires July 31, 2010 [Page 26]
Internet-Draft draft-bootstrapping January 2010
[STAJANO99]
Stajano, F. and A. Anderson, "The Resurrecting Duckling:
Security Issues for Ad-hoc Wireless Networks", Proceedings
of the 7th International Workshop on Security Protocols ,
LNCS , vol. 1796, pp. 172-194, 1999.
[WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup Specification
v1.0", 2007.
14.2. Informative References
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
Appendix A. Additional Stuff
This becomes an Appendix.
Author's Address
Colin Patrick O'Flynn
Atmel Corporation
Colorado Springs, Colorado
USA
Phone:
Email: colin.oflynn@atmel.com
O'Flynn Expires July 31, 2010 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-23 04:15:56 |