Core C. O'Flynn
Internet-Draft Atmel Corporation
Intended status: Informational B. Sarikaya
Expires: September 1, 2010 Huawei USA
February 28, 2010
Initial Configuration of Resource-Constrained Devices
draft-oflynn-core-bootstrapping-00
Abstract
The Internet of Things is marching its way towards completion. Nodes
can use standards from the 6LoWPAN and ROLL WG to achieve IP
connectivity. IEEE Standards ensure connectivity at lower layers for
resource-constrained devices. Yet a central problem remains at a
more basic layer without a suitable answer: how to initially
configure the network. Without configuration the network never
advances beyond a large box of nodes. Current solutions tend to be
specific to a certain vendor, node type, or application.
This document outlines exactly what problems are faced in solving
this problem. General problems faced in any low-power wireless
network are outlined first; followed by how these apply to
bootstrapping. A selection of currently proposed techniques is
presented. From these a more generic approach is presented, which
can solve the problem for a wide range of situations.
An emphasis is on performing this bootstrapping in a secure manner.
This document does not cover operation of the network securely. This
document does provide the basis for allowing the network to operate
securely however, by providing standard methods for key exchanges and
authentication.
Status of this Memo
This Internet-Draft is submitted 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 & Sarikaya Expires September 1, 2010 [Page 1]
Internet-Draft draft-oflynn-core-bootstrapping February 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 September 1, 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 & Sarikaya Expires September 1, 2010 [Page 2]
Internet-Draft draft-oflynn-core-bootstrapping February 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 . . . . . . . . . . . . . . . . . . . . 10
3.1.2.4. User Interface . . . . . . . . . . . . . . . . . . 10
3.1.2.5. Security . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Requirement Summary . . . . . . . . . . . . . . . . . 11
3.2. Considerations of Requirements . . . . . . . . . . . . . . 12
3.2.1. Resources . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Security Considerations . . . . . . . . . . . . . . . 12
3.2.2.1. Passive Attacks . . . . . . . . . . . . . . . . . 12
3.2.2.2. Active Attacks . . . . . . . . . . . . . . . . . . 12
3.2.2.3. Timing Attack . . . . . . . . . . . . . . . . . . 13
3.3. Existing Bootstrapping Methods . . . . . . . . . . . . . . 13
3.3.1. Device Label . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Resurrecting Duckling . . . . . . . . . . . . . . . . 14
3.3.3. Button Press . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Out Of Band (OOB) Wireless . . . . . . . . . . . . . . 15
3.3.5. Out Of Band (OOB) Physical . . . . . . . . . . . . . . 15
4. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 16
5. User Interfaces . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Required Functions . . . . . . . . . . . . . . . . . . . . 17
5.1.1. User Feedback: Identify Node . . . . . . . . . . . . . 17
5.1.2. User Feedback: Confirm Authentication Data to User . . 17
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 & Sarikaya Expires September 1, 2010 [Page 3]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
5.1.7. User Request: Advertise Network . . . . . . . . . . . 18
5.2. Example User Interface Profiles . . . . . . . . . . . . . 18
5.2.1. No-Interface End Node . . . . . . . . . . . . . . . . 18
5.2.2. Minimal-Interface End Node . . . . . . . . . . . . . . 18
5.2.2.1. Identify Node . . . . . . . . . . . . . . . . . . 18
5.2.2.2. Confirm Authentication Data with User . . . . . . 18
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 . . . . . . . . . . . 19
5.2.4.1. Confirm Authentication Data with User . . . . . . 19
6. Bootstrap Profiles . . . . . . . . . . . . . . . . . . . . . . 19
7. Communications Channel . . . . . . . . . . . . . . . . . . . . 20
7.1. Supported Communication Channels . . . . . . . . . . . . . 20
8. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 20
8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. EAP-GPSK . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. Asymmetric with User Authentication, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4. Asymmetric with Certificate Authority, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 21
8.5. Cryptographically Generated Address Based Address
Ownership Verification . . . . . . . . . . . . . . . . . . 21
9. Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . . . 21
10. Example Exchanges . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 22
10.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 22
10.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
O'Flynn & Sarikaya Expires September 1, 2010 [Page 4]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
1. Introduction
Familiarity with constrained network types is assumed here.
Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups
(WGs) would be a useful reference for the reader. In particular RFC
4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] from ROLL, and RFC
5673 [RFC5673] from ROLL, and a paper by Romer and Mattern [ROMER04].
Familiarity with application specific examples is also useful, such
as Zigbee or Smart Energy groups.
A summary of those will be presented, as far as network requirements
are concerned. The general network requirements will be further
concentrated into requirements surrounding only the bootstrapping
issues.
A number of solutions which are currently in use will be presented
and compared to the requirements. From these the requirements of the
final solution is identifiable, and a proposal is made on this.
Note this document has considerable extra information that is not
designed to be worked into the final I-D. It also has some example
specifications of particular applications that would not be present
in the final version as they are out of scope of the proposed working
group. As a general guide they are very useful, but realistically
will be split off to either another I-D or some other location.
1.1. What is Bootstrapping?
Node configuration is known as bootstrapping in this document.
Bootstrapping is any processing required before the network can
operate. Typically this will require a number of settings to be
transferred between nodes at all layers. This could include anything
from link-layer information (ie: wireless channels, link-layer
encryption keys) to application-layer information (ie: network names,
application encryption keys).
Bootstrapping is complete when settings have been securely
transferred prior to normal operation in the network.
1.2. Why IETF?
The bootstrapping problem is not specific to any MAC or PHY. This
problem exists across any two nodes which have no previous knowledge
of each other. In particular, this problem is complicated when the
nodes are resource-constrained and may not have an advanced user
interface. The IETF is instrumental in defining standards which will
be used by The Internet of Things. Ensuring these standards can be
used across nodes and networks requires some form of bootstrapping
O'Flynn & Sarikaya Expires September 1, 2010 [Page 5]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
which any node can use.
Existing standards will be used as much as possible in this document.
The method proposed here should work across many different underlying
layers. It could be used to allow two nodes on the same physical
network to join at the physical layer, or allow two nodes on an
incompatible physical network to join at the IPv6 layer.
1.3. Why a New Standard?
Simply put, no existing standard brings together all the required
aspects. At lower layers, standards exist to solve the problem in
special cases. Examples are Wi-Fi Protected Setup, Bluetooth
Pairing, or ZigBee solutions such as RF4CE. As will be discussed
later, these are not flexible enough to run on the wide variety of
nodes which a smart network will use.
At higher layers, standards exist to perform a secure authentication
or service discovery. However these standards almost always assume
the two nodes have some existing way of communicating, such as being
plugged into the same network. This will often not be the case.
Thus this document is aimed to bridge this gap. Many existing
standards can be applied to solve the problem (e.g.: EAP), but some
guidance on their use is required to ensure all implementations
interoperate.
2. Examples of Node Configuration
Before any detail on methods is explored, the following section will
provide various examples this document could cover. Exact
requirements will be brought forward in subsequent sections. For the
reader's general understanding this section is placed to give an idea
of an acceptable usage scenario.
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 herein.
O'Flynn & Sarikaya Expires September 1, 2010 [Page 6]
Internet-Draft draft-oflynn-core-bootstrapping February 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 & Sarikaya Expires September 1, 2010 [Page 7]
Internet-Draft draft-oflynn-core-bootstrapping February 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 manufacturer 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 one in which
O'Flynn & Sarikaya Expires September 1, 2010 [Page 8]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
devices automatically form a network, as the user sees their devices
'just work'. A manufacture may pre-load devices with security keys
in this case to ensure they communicate out of the box. If the user
purchases products from different manufactures or product lines
however, these devices may all set up different networks.
These seperate networks may be totally unaware of each other. Later
on the user may wish for the seperate networks to function as one
system, as they wish for all lights to be centrally controlled.
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 systems this will become more
prevalent. For example initially a company may set up separate HVAC,
security, and lighting systems. 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 systems.
Depending on the network architecture multiple networks may need to
merge together to provide this intercommunication. A very simple
wireless network for example would require all nodes to be on the
same physical layer. Physical layer means either the same channel,
or in a channel-hopping network the same channel sequence. Thus when
nodes on multiple networks are brought together in these
circumstances, the nodes would have to merge to one large network.
More complex and larger networks may solve this problem at a higher
layer. For example the HVAC, security, and lighting systems in a
building may be on completely different networks. Each system
however has a communications link to the same router, and nodes can
communicate by normal IP routing.
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.
Even if nodes are fixed, the environment around them can change. A
wireless network could find it's peers changed when a metal filing
cabinet is installed, or the old leaking microwave is used.
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
O'Flynn & Sarikaya Expires September 1, 2010 [Page 9]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
require the user to perform an action on the central authority.
3.1.2.3. Resources
The extreme resource constraints of the nodes provides further
problems. These resource constraints include cost, memory
requirements, power requirements, and size requirements. These are
not consistent either: some nodes may have parasitic power measured
in micro-amps, but some nodes may be directly connected to the power
grid. Likewise some nodes may have a tiny 8-bit microcontroller, but
other nodes will have 32-bit microcontrollers running Linux. The
bootstrapping process must take into account the wide range of
resource constraints. The protocol should run on a tiny end node,
while not making itself useless on a larger end node.
3.1.2.4. User Interface
The user interface may 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 may be 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
O'Flynn & Sarikaya Expires September 1, 2010 [Page 10]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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'.
EAP authentication requires EAP packets to be encapsulated at the
link layer in resource constrained links. Efficient encapsulation
techniques MUST be developed, separately for each link type such as
IEEE 802.15.4.
Address ownership verification between a node and its router using
CGA requires a modified version of IPv6 neighbor discovery protocol
to be executed. An example neighbor discovery protocol is 6LOWPAN
neighbor discovery protocol [I-D.ietf-6lowpan-nd].
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 policy decisions, and not a limitation of the 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 policy 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
bootstrapping if required; the security in use during normal
network operation is not in the scope of this document.
O'Flynn & Sarikaya Expires September 1, 2010 [Page 11]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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].
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 transmit data. This could
include Man In The Middle (MITM) attacks for example, where an
O'Flynn & Sarikaya Expires September 1, 2010 [Page 12]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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 Bootstrapping Methods
There are a number of existing bootstrapping methods presented. This
section provides an outline of them, along with discussing advantages
and disadvantages to each method.
3.3.1. Device Label
Device labels are used as a form of shared secret. The initial
shared secret is exchanged 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. A PIN is written on
the label on the end router, they enter this PIN into the cell phone.
This allows the cell phone to securely join the network, as both the
cell phone and router know the shared PIN. Later when a printer is
brought home, the user reads a PIN off the printer. They again enter
this PIN into the cell phone, which can communicate the PIN to the
router. Now the router and printer again have a shared secret, and
the printer is allowed on the network securely. [WPS]
Extensions of the simple device PIN could include machine-readable
barcodes. Whereas a device PIN that is entered by a human requires a
label and has limited entropy, using machine-readable barcodes
reduces the label size requirements while increasing the amount of
information stored.
Nodes which have displays would also not have a fixed PIN. Instead
they display a new PIN each time. A fixed PIN could either be read
covertly if an attacker had physical access, or brute-forced since it
is fixed. The dynamic PIN provides additional security since it is
valid only once.
ADVANTAGES:
O'Flynn & Sarikaya Expires September 1, 2010 [Page 13]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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 Depending on deployment details (e.g.: label entropy, dynamic
PINs) security can be quite good.
DISADVANTAGES:
o Extra cost of labels and ensuring the labels match any
preprogrammed information when using fixed PINs.
o Requires one node on network to have advanced user interface.
o OOB is one-way only.
3.3.2. Resurrecting 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, the node is 'killed'.
This reverts the node back to the state when it was first powered on,
and it will then attempt to associate with a new nearby mother node.
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 Hard 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.
O'Flynn & Sarikaya Expires September 1, 2010 [Page 14]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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.
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'Flynn & Sarikaya Expires September 1, 2010 [Page 15]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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 'communications channel'.
The user interface provides both user input and user output. Simple
nodes may only have a push-button and LED, more complex nodes may
have a graphical display and keyboard. The user interface provides
interaction between the user and bootstrapping methods. The user
interface would be used during bootstrapping as an OOB channel. It
may also be used to specify bootstrapping policies.
The user interface provides the interaction between the user and the
bootstrap protocol. The user interface will vary depending on the
capabilities of the node. Examples might include a push-button and
LED on simple nodes, to full-blown graphical user interfaces. Note
that a 'bootstrapping tool' used to initially deploy a network is
just a special user interface. This allows a very uniform protocol
in deployment and use of networks.
Two nodes communicate through some channel. For our purposes this is
split into the 'control channel' and 'data channel'. The control
channel is used for the bootstrap protocol, and the data channel is
used during normal network operation. A node may support multiple
control or data channels. When the control and data channels are the
same, the bootstrapping is done In Band (IB). When the control and
data channels are different, the bootstrapping is performed Out Of
Band (OOB). An 802.15.4 network for instance would use an 802.15.4
control channel for IB bootstrapping, but a control channel of
perhaps IrDA or USB for OOB bootstrapping.
The 'bootstrap profile' defines what information should be exchanged
during the process. A single node may run the protocol multiple
times with different profiles. If the user wishes to associate a new
lightswitch, the protocol is first run with the '802.15.4 Wireless
O'Flynn & Sarikaya Expires September 1, 2010 [Page 16]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
Profile', through which it learns the channel and PAN-ID. The node
then runs a 'Security Exchange Profile' to learn the needed
encryption keys. Finally it runs a 'Lightswitch Association Profile'
through which it learns which light to associate with.
The 'security method' defines supported security methods for
bootstrapping. The supported security methods will depend on the
control channel and bootstrap profile. In one node if the control
channel is secure, then a simple clear-text security method is
supported. For example when a physical connection between two nodes
is used, the control channel is considered secure. However when the
BTL is not secure, this clear-text security method is not supported.
The 'bootstrap profile' additionally defines allowed security
methods. Higher security nodes may outlaw ever performing a clear-
text exchange, even if the control channel is deemed secure.
The 'bootstrap protocol' defines the actual messages exchanged during
bootstrapping. The messages are used to transfer between nodes data,
node information, and network state. The selected security method
runs on top of the control channel, such as EAP-GPSK etc.
5. User Interfaces
User interfaces provide an interface between the bootstrap protocols
and the user. This is used for instance in selecting devices or
checking security. The interface must provide a number of functions
as defined here.
5.1. Required Functions
5.1.1. User Feedback: Identify Node
During a join process, the user will be required to confirm which two
nodes are being joined together. For this the 'identify node'
function performs an action such as blinking an LED or displaying a
message.
5.1.2. User Feedback: Confirm Authentication Data to User
When performing a Diffie &mdash Hellman style key exchange, some form
of authentication is required. This function presents the
authentication data to the user, where the user confirms that the
expected two devices will be joined. Example: Bluetooth Secure
Simple Pairing's [BSSP] numeric comparison .
O'Flynn & Sarikaya Expires September 1, 2010 [Page 17]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
5.1.3. User Feedback: FAILED
Alerts the user to a failed bootstrap attempt.
5.1.4. User Feedback: OK
Alerts the user to a successful bootstrap attempt.
5.1.5. User Request: Disconnect from Network & Clears
This disconnects the node from the network, and clears settings back
to a factory-default configuration.
5.1.6. User Request: Scan for Network to Join
This enters the 'join' mode on an end node, scanning for a network in
'advertise' mode.
5.1.7. User Request: Advertise Network
This mode advertises the current running network. If no network is
running, the node may start a new network.
5.2. Example User Interface Profiles
Parts of the 'required functions' that must agree between end nodes
are specified here. For example on nodes which support 'confirm
authentication data with user', we need to ensure that both nodes
display the same authentication data. Each level higher in the
interface hierarchy automatically inherits every profile below it.
5.2.1. No-Interface End Node
A no-interface end node has no method of user interaction.
5.2.2. Minimal-Interface End Node
A minimal-interface node has a single LED and single button.
5.2.2.1. Identify Node
The LED blinks.
5.2.2.2. Confirm Authentication Data with User
The authentication data will be confirmed by a blink pattern. The
user can confirm that both nodes blink in the same pattern, which
means both nodes have swapped the correct data. TODO: Specify the
O'Flynn & Sarikaya Expires September 1, 2010 [Page 18]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
exact function used to generate the blink pattern from the crypto
data such as public keys, etc. The user confirms the data by
pressing the button on the node. If they either do not press the
button, or hold the button down for X seconds, they have not
confirmed the data and the authentication data will be considered
INVALID.
5.2.2.3. Button Input
The button controls all available user requests.
When the button is pressed, the node automatically performs a scan
for other networks in 'advertise' mode. If no networks are found,
the node may then switch to 'advertise' mode. This sequence ensures
two nodes will *always* find each other if they can communicate at
the BTL.
If the button is held down for X seconds, the user is requesting a
Disconnect/Memory Clear.
5.2.3. Numerical-Interface End Node
A numerical-interface end node has a display capable of displaying at
least 6 numbers
5.2.3.1. Confirm Authentication Data with User
A number is calculated based on the crypto data. Example: Bluebooth
Secure Simple Pairing.
5.2.4. Alphanumeric-Interface End Node
A numerical-interface end node has a display capable of displaying up
to 24 characters.
5.2.4.1. Confirm Authentication Data with User
A character string is calculated based on the crypto data.
6. Bootstrap Profiles
The bootstrapping profile defines what and how data must be
exchanged. The bootstrapping profile is where network policies can
be placed, such as allowed methods of joining.
Bootstrap profiles bring together the various aspects of the
bootstrap method. The bootstrap profile specifies items such as:
O'Flynn & Sarikaya Expires September 1, 2010 [Page 19]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
o
o
7. Communications Channel
The communications channel is the method used between two nodes to
communicate. There are two main communication channels: the
'control' and 'data' channels. The control channel is used during
bootstrapping, and the data channel is used during network operation.
7.1. Supported Communication Channels
There is no limit on what communications channels are supported. The
following gives an example of several supported channels:
o IEEE 802.15.4
o Power-Line Communications
o IrDA
o RFID
o Some simple physical link
o Cellular
o Ethernet
o IPv6
o Wi-Fi
Depending on the node's function, it may use different channels as
the data or control channel. Nodes may have multiple data and/or
control channels as wel.
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
O'Flynn & Sarikaya Expires September 1, 2010 [Page 20]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
channel. The techniques negotiated should take advantage of hardware
resources available, such as hardware encryption accelerators on an
end node.
8.1. None
This is the simplist security method. No encryption or
authentication is provided, messages are exchanged completely in
clear-text. It is assumed some other layer provides security, such
as a physical connection between devices.
8.2. EAP-GPSK
EAP-GPSK is used as the authentication method [RFC5433]. 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.
8.5. Cryptographically Generated Address Based Address Ownership
Verification
A node may generate the global unique address using different
techniques other than the stateless address autoconfiguration. For
example, Cryptographically Generated Addresses (CGA) [RFC3972] is a
type of global unique address that can be used to verify the address
ownership. When the node uses CGA, it MUST execute SeND protocol
[RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol
[I-D.ietf-6lowpan-nd] must be executed between the node and the edge
router.
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
O'Flynn & Sarikaya Expires September 1, 2010 [Page 21]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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
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 |
+----------+------------+----------------+
O'Flynn & Sarikaya Expires September 1, 2010 [Page 22]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
Supported Security Methods
+------------------+------------+----------------+
| Method | DVD Player | Remote Control |
+------------------+------------+----------------+
| None | Y | Y |
| EAP-GPSK | 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
mode.
o The DVD remote scans for a network, and then finds the DVD
player's network.
o The devices generate a shared secret (ie: Diffie-Hellman), and
both blink their LED in a unique pattern based on this shared
secret.
o The user user confirms both devices are blinking the same pattern,
as both LEDs are blinking in unison.
o The DVD player displays 'JOIN OK' on it's LCD panel.
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.
O'Flynn & Sarikaya Expires September 1, 2010 [Page 23]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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 |
+----------+----+----------------+
Supported Security Methods
+------------------+----+----------------+
| Method | TV | Remote Control |
+------------------+----+----------------+
| None | Y | Y |
| EAP-GPSK | Y | N |
| Asymmetric, User | Y | Y |
| Asymmetric, CA | Y | N |
+------------------+----+----------------+
The TV and remote control have a number of ways in which they could
be joined together. The remote control does not have any unique
identifier printed on it, thus no pre-shared key can be identified.
This leaves either an unsecure joining method, or some asymmetric
security method.
The remote control has a button on it for 'join', as does the TV. In
this example two sequence will be considered: where the TV button is
pressed first, and where the remote control button is pressed first.
If the TV join button is pressed first:
o TV scans for existing networks in advertise mode. Finding none,
it starts a new network and that network enters advertise mode.
O'Flynn & Sarikaya Expires September 1, 2010 [Page 24]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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 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
O'Flynn & Sarikaya Expires September 1, 2010 [Page 25]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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 and Behcet Sarikaya. Thanks to Zach
Shelby and Robert Craige for editing, comments, and overall
assistance.
13. IANA Considerations
This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [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
O'Flynn & Sarikaya Expires September 1, 2010 [Page 26]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
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.
[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.ietf-6lowpan-nd]
Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S.,
Bormann, C., and E. Nordmark, "6LoWPAN Neighbor
Discovery", draft-ietf-6lowpan-nd-08 (work in progress),
February 2010.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
O'Flynn & Sarikaya Expires September 1, 2010 [Page 27]
Internet-Draft draft-oflynn-core-bootstrapping February 2010
[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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, February 2009.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Colin Patrick O'Flynn
Atmel Corporation
Colorado Springs, Colorado
USA
Phone:
Email: colin.oflynn@atmel.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Email: sarikaya@ieee.org
O'Flynn & Sarikaya Expires September 1, 2010 [Page 28]