Core C. O'Flynn
Internet-Draft Atmel Corporation
Intended status: Informational B. Sarikaya
Expires: May 12, 2011 Huawei USA
Y. Ohba
Toshiba
Z. Cao
China Mobile
R. Cragie
Pacific Gas and Electric
November 8, 2010
Security Bootstrapping of Resource-Constrained Devices
draft-oflynn-core-bootstrapping-03
Abstract
The Internet of Things is marching its way towards completion. Nodes
can use standards from the 6LoWPAN and ROLL WG to achieve IP
connectivity. IEEE Standards ensure connectivity at lower layers for
resource-constrained devices. Yet a central problem remains at a
more basic layer without a suitable answer: how to initially
configure the network. Without configuration the network never
advances beyond a large box of nodes. Current solutions tend to be
specific to a certain vendor, node type, or application.
This document outlines exactly what problems are faced in solving
this problem. General problems faced in any low-power wireless
network are outlined first; followed by how these apply to
bootstrapping. A selection of currently proposed techniques is
presented. From these a more generic approach is presented, which
can solve the problem for a wide range of situations.
An emphasis is on performing this bootstrapping in a secure manner.
This document does not cover operation of the network securely. This
document does provide the basis for allowing the network to operate
securely however, by providing standard methods for key exchanges and
authentication.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
O'Flynn, et al. Expires May 12, 2011 [Page 1]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 12, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
O'Flynn, et al. Expires May 12, 2011 [Page 2]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 5
1.2. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 6
2.1. Areas of Boostrapping . . . . . . . . . . . . . . . . . . 6
2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
3. Communications Channel . . . . . . . . . . . . . . . . . . . . 8
3.1. Supported Communication Channels . . . . . . . . . . . . . 8
4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 8
4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Asymmetric with User Authentication, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Asymmetric with Certificate Authority, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Cryptographically Generated Address Based Address
Ownership Verification . . . . . . . . . . . . . . . . . . 9
5. Bootstrap Protocols . . . . . . . . . . . . . . . . . . . . . 9
5.1. System Level Objectives . . . . . . . . . . . . . . . . . 10
5.2. EAP Authentication Framework . . . . . . . . . . . . . . . 10
5.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Examples of Node Configuration . . . . . . . . . . . 19
A.1. Smart Energy . . . . . . . . . . . . . . . . . . . . . . . 19
A.1.1. Initial Meter Installation . . . . . . . . . . . . . . 19
A.1.2. Home Expansions . . . . . . . . . . . . . . . . . . . 19
A.2. Consumer Products . . . . . . . . . . . . . . . . . . . . 20
A.2.1. Connecting DVD Remote to DVD Player . . . . . . . . . 20
A.2.2. Adding a TV to a network with a DVD player and
remote . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2.3. Providing GPS Location Data . . . . . . . . . . . . . 20
A.3. Commercial Building Automation . . . . . . . . . . . . . . 20
A.3.1. Light Installation . . . . . . . . . . . . . . . . . . 20
Appendix B. Example Exchanges . . . . . . . . . . . . . . . . . . 20
B.1. Smart Energy: Meter Manufacture . . . . . . . . . . . . . 20
B.2. Smart Energy: Meter Installation . . . . . . . . . . . . . 20
B.3. Smart Energy: Home Expansion . . . . . . . . . . . . . . . 21
B.4. Consumer: Connecting DVD Remote to DVD Player . . . . . . 21
B.5. Consumer: Adding a TV to a network with a DVD player
and remote . . . . . . . . . . . . . . . . . . . . . . . . 22
O'Flynn, et al. Expires May 12, 2011 [Page 3]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
B.6. Consumer: Providing GPS Location Data . . . . . . . . . . 24
B.7. Commercial: Building Automation . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
O'Flynn, et al. Expires May 12, 2011 [Page 4]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
1. Introduction
Familiarity with constrained network types is assumed here.
Documents produced in the 6LoWPAN, ROLL, and CoRE Working Groups
(WGs) would be a useful reference for the reader. In particular RFC
4919 [RFC4919] from 6LoWPAN, RFC 5548 [RFC5548] and RFC 5673
[RFC5673] from ROLL, CoAP [I-D.ietf-core-coap] from CoRE, and a paper
by Romer and Mattern [ROMER04]. Familiarity with application
specific examples such as Zigbee or Smart Energy groups is assumed.
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.
Requirements on each solution will be stated to enable their use as a
security bootstrapping protocol.
1.1. What is Bootstrapping?
Node configuration is known as bootstrapping in this document.
Bootstrapping is any processing required before the network can
operate. Typically this will require a number of settings to be
transferred between nodes at all layers. This could include anything
from link-layer information (i.e., wireless channels, link-layer
encryption keys) to application-layer information (i.e., network
names, application encryption keys).
Bootstrapping is complete when settings have been securely
transferred prior to normal operation in the network.
1.2. Why IETF?
The bootstrapping problem is not specific to any MAC or PHY. This
problem exists across any two nodes which have no previous knowledge
of each other. In particular, this problem is complicated when the
nodes are resource-constrained and may not have an advanced user
interface. The IETF is instrumental in defining standards which will
be used by The Internet of Things. Ensuring these standards can be
used across nodes and networks requires some form of bootstrapping
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.
O'Flynn, et al. Expires May 12, 2011 [Page 5]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
2. Bootstrapping Architecture
2.1. Areas of Boostrapping
In order to provide a flexible architecture, the bootstrapping method
is split into five distinct areas and two distinct phases. The five
areas are a 'user interface', 'bootstrap profile', 'security method',
'bootstrap protocol', and the 'communications channel'.
The phases are provisioning phase and bootstrapping phase. In the
provisioning phase, statically configured parameters (e.g.,
certificates) needed for the bootstrapping phase is provisioned. In
the bootstrapping phase, dynamically configured information is set up
using the statically configured information provided in the
provisioning phase.
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.
User interface is out-of-scope and will not be further discussed.
Two nodes communicate through some channel. For our purposes this is
split into the 'control channel' and 'data channel'. The control
channel is used for the bootstrap protocol, and the data channel is
used during normal network operation. A node may support multiple
control or data channels. When the control and data channels are the
same, the bootstrapping is done In Band (IB). When the control and
data channels are different, the bootstrapping is performed Out Of
Band (OOB). An 802.15.4 network for instance would use an 802.15.4
control channel for IB bootstrapping, but a control channel of
perhaps IrDA or USB for OOB bootstrapping.
The 'bootstrap profile', i.e. statically configured parameters during
the provisioning phase, 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, et al. Expires May 12, 2011 [Page 6]
Internet-Draft draft-oflynn-core-bootstrapping November 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
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
control channel 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.
2.2. Architecture
Security bootstrapping architecture is structured in a hierarchy of
nodes going from the least resource constraint to the most resource
constraint. At the top there is a root node. The root node is
called Coordinator or Trust Center in Zigbee and 6LowWAN Border
Router (6LBR) in 6LoWPAN ND.
At the next level there are interior Routers. Routers are able to
run a routing protocol between other routers and the root. Router
are called 6LowWAN Routers (6BR) in 6LoWPAN ND.
At the lowest level there are the nodes. The nodes do not run a
routing protocol. They can connect to the nearest router over a
single radio link. The nodes are called End Device in Zigbee and
host in in 6LoWPAN ND.
Routers first join the network as a node and go through security
bootstrapping operations in order to create a Master Session Key
(MSK). Next routers execute routing protocol, e.g.
[I-D.ietf-roll-rpl] specific steps to create session keys with their
neighbors and to establish upstream and downstream next hop parents.
At each node hierarachy level described above, there are lower-layer
and higher-layer protocols to bootstrap their ciphering keys, where
the lower-layer refers to layers below IP layer including IEEE
O'Flynn, et al. Expires May 12, 2011 [Page 7]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer
refers to IP layer and the above. In general, required bootstrapping
procedures depend on the bootstrapping protocols to use. Section
Section 5 describes the bootstrapping procedures where EAP
(Extensible Authentication Protocol) [RFC3748] and other protocols
are used as the bootstrapping protocols.
3. Communications Channel
The communications channel is the method used between two nodes to
communicate. There are two main communication channels: the
'control' and 'data' channels. The control channel is used during
bootstrapping, and the data channel is used during network operation.
3.1. Supported Communication Channels
There is no limit on what communications channels are supported. The
following gives an example of several supported channels:
o IEEE 802.15.4
o Power-Line Communications
o IrDA
o RFID
o Some simple physical link
o Cellular
o Ethernet
o IPv6
o Wi-Fi
Depending on the node's function, it may use different channels as
the data or control channel. Nodes may have multiple data and/or
control channels as wel.
4. Bootstrap Security Method
The bootstrap security method defines allowable security methods. A
node may choose to support or use a subset of these methods. This is
NOT the security architecture used for the application, but only the
O'Flynn, et al. Expires May 12, 2011 [Page 8]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
security used during bootstrapping. Typically some high-security
method is used to generate a shared secret, which then switches to
simplier symmetric encryption to secure the actual bootstrapping
channel. The techniques negotiated should take advantage of hardware
resources available, such as hardware encryption accelerators on an
end node.
4.1. None
This is the simplist security method. No encryption or
authentication is provided, messages are exchanged completely in
clear-text. It is assumed some other layer provides security, such
as a physical connection between devices.
4.2. Asymmetric with User Authentication, Followed by Symmetric
A Diffie-Hellman style key exchange is used to generate a shared
secret. The authentication will be provided by the user, by
confirming cryptographic signatures between two devices. With the
shared secret generated through the DH, some symmetric encryption is
used to secure the actual bootstrapping channel.
4.3. Asymmetric with Certificate Authority, Followed by Symmetric
Public key exchanges are used (aka: DH again), but with a Certificate
Authority. Once a shared secret exists, symmetric encryption is used
to secure the actual bootstrapping channel.
4.4. Cryptographically Generated Address Based Address Ownership
Verification
A node may generate the global unique address using different
techniques other than the stateless address autoconfiguration. For
example, Cryptographically Generated Addresses (CGA) [RFC3972] is a
type of global unique address that can be used to verify the address
ownership. When the node uses CGA, it MUST execute SeND protocol
[RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol
[I-D.ietf-6lowpan-nd] must be executed between the node and the edge
router.
5. Bootstrap Protocols
In this section we first present system level objectives that
security bootstrapping protocols are expected to achieve. Next, we
present EAP authentication framework and then describe three
different protocols.
O'Flynn, et al. Expires May 12, 2011 [Page 9]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
5.1. System Level Objectives
Authentication/ reauthentication: nodes joining the network MUST at
the first place authenticate to the trust center. In order to
achieve secure multi-hop routing, the node MUST authenticate to its
upstream and downstream neighbors. A bootstrapping solution MUST
support re-authentication of resource-constrained devices and re-
keying of dynamically generated keys.
Data Confidentiality: the data communication between two endpoints
MAY be encrypted using the derived key, avoiding being eavesdropped
by a non-trusted third part.
Data Integrity: the data communication between two endpoints MUST NOT
be altered by some intermediate nodes. The nodes should be able to
detect the non-integral data.
Keys and key freshness: the keys used for data communication MUST
have a lifetime, in order to keep their freshness. A bootstrapping
solution MUST support both symmetric and asymmetric key
authentication. If distribution of a key to be used for a resource-
constrained device is required, a bootstrapping solution MUST support
secure key distribution to prevent the key from eavesdropping,
alternation and replay attacks.
Multi domain support: A bootstrapping solution MUST be able to allow
resource-constrained devices that may be subscribed to different
administrative domains to be connected to the same access network at
the same time.
Identities: A bootstrapping solution MUST be able to allow a
resource-constrained device to use various types of identities used
for authentication, including device identities, user identities or
combinations of different types of identities. Also a bootstrapping
solution MUST be able to allow a resource-constrained device to
change its identities used for authentication over time.
Authentication infrastructure: A bootstrapping solution MUST be able
to operate with or without an authentication infrastructure.
5.2. EAP Authentication Framework
In EAP, there are three distinct entities: the client or EAP peer,
the authenticator and the authentication or EAP server [RFC5247].
The EAP peer is the node that requires to be authenticated before
being admitted to the network. The authentication server is the
device authenticating the node for bootstrapping. The authenticator
O'Flynn, et al. Expires May 12, 2011 [Page 10]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
is the device that is admitting the node to the network and it
resides in between the peer and authentication server.
EAP client and EAP server exchange EAP messages to execute the
authentication algorithm, a.k.a. EAP method. The authenticator is
responsible for forwarding EAP messages between the client and
server. In 802.1X, EAP messages are carried in Layer 2 and in PANA
in IP or Layer 3. EAP messages between the authenticator and
authentication server are carried using AAA protocols (RADIUS or
Diameter).
At the end of a successful EAP method execution a master session key
(MSK) is generated at both the EAP peer and EAP server.
Authenticator receives MSK from EAP server at the end of EAP method
execution using key transport. MSK is used in deriving a session key
between the node and the authenticator using a protocol called secure
association protocol (SAP). Derivation of the session key terminates
bootstrapping of a node.
Additional keying material derived between EAP client and server that
is exported by the EAP method is called Extended Master Session Key
(EMSK). EMSK is not used in session key derivation but it could be
used for the needs of other applications in higher layer protocols.
In the architecture introduced in Section 2.2 the node or router is
the peer and the root is the authenticator. When the supplicant and
authenticator are one hop away the authenticator can be reached
directly. However, this is rarely the case. In other cases the
authenticator authenticates neighboring supplicants first. The
router nodes that are authenticated become relay authenticators in
the next phase and they relay authentication messages from the
supplicants to the authenticator and vice versa. This continues
until all nodes are authenticated.
EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request
messages sent by the server and EAP-Response messages sent by the
peer. At the end, the server indicates the status of authentication,
usually by EAP-Success message which also carries the MSK. The first
EAP-Request/Response pair is used for the server to request the
identity and the peer to provide it. In the other pairs of EAP
exchanges EAP method is executed.
Several EAP methods have been standardized each for different
purposes. To authenticate devices with certificates, EAP Transport
Layer Security (TLS) v1.2 specified in [RFC5216] which supports
certificate-based mutual authentication is used.
Smart Energy Profile 2.0 Application Protocol Specification [SE2.0]
O'Flynn, et al. Expires May 12, 2011 [Page 11]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
mandates each device to be factory programmed with a certificate.
The certificate is bound to a unique network ID, e.g. the device's
MAC address or EUI-64 address. During EAP-Identity exchange the EAP
peer provides its EUI-64 address as an identity to EAP server. This
enables the server to validate the device certificate.
5.3. PANA
PANA (Protocol for carrying Authentication for Network Access)
[RFC5191] defines an EAP transport over UDP where a PANA Client (PaC)
is an EAP peer and a PANA Authentication Agent (PAA) is an EAP
authenticator. There are three bootstrapping scenarios using PANA.
1. Use of PANA for bootstrapping link-layer security.
In this case, PANA is used for network access authentication to
bootstrap link-layer ciphering. Security for higher-layer (i.e.,
IP layer and above) protocols is bootstrapped from an IB or OOB
mechanism other than PANA. For example, in a 6LoWPAN deployment
PANA authentication can take place to bootstrap IEEE 802.15.4 MAC
layer ciphering keys. In ZigBee IP, IEEE 802.15.4 MAC layer
ciphering keys used as session keys are derived from a group key
so called a Network Key that is securely distributed to each
joining node upon successful PANA authentication using AES key
wrap over PANA [I-D.ohba-pana-keywrap] where the key encryption
key is derived from the EAP MSK (Master Session Key) [RFC3748].
2. Use of PANA for bootstrapping higher-layer security.
In this scenario, PANA is used as an OOB mechanism for higher-
layer authentication to bootstrap ciphering keys for one or more
higher-layer protocols independently of network access
authentication. The PAA may reside in a higher-layer network
element such as an ANSI C12.22 authentication host [C1222] and a
CoAP server, or an independent server dedicated for service
authentication for multiple higher-layer protocols. When
bootstrapping ANSI C12.22 security for which no IB key management
mechanism is available, ANSI C12.22 ciphering keys are directly
derived from EAP key material established from PANA
authentication. When bootstrapping CoAP security with DTLS
protection, a PSK (Pre-Shared Key) credential in the combined
usage of DTLS (Datagram Transport Layer Security) [RFC4347] and
PSK mode of TLS [RFC4279] is derived from EAP key material and
DTLS ciphering keys are generated as a result of a successful
DTLS handshake. Similarly, when bootstrapping CoAP security with
IPsec ESP protection, a PSK credential of IKEv2 [RFC5996] is
derived from EAP key material and IPsec ESP ciphering keys are
generated as a result of a successful IKEv2 handshake.
O'Flynn, et al. Expires May 12, 2011 [Page 12]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
The ability to bootstrap multiple higher-layer protocols from a
single execution of PANA authentication is important to save the
computational resources for resource-constrained devices
especially where public-key based authentication is used.
3. Use of PANA for bootstrapping both link-layer and higher-layer
security.
This case is the combination of the other two cases, and the most
optimized way for bootstrapping resource-constrained devices.
This case is only applicable where both the network access
authentication and the higher-layer authentication use the same
authentication server with the same authentication credentials.
The second and third scenarios are generally referred to as Single
Sign-On in section 4.2.2.2 of [NISTIR7628VOL1], where the root keys
for higher-layer protocols can be derived from EAP EMSK (Extended
Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295].
A PANA Relay Element (PRE) is needed to enable PANA messaging between
a PANA Client (PaC) which is the node to be authenticated and a PANA
Authentication Agent (PAA) which is the authenticator where the two
nodes cannot reach each other by means of regular IP routing. This
happens during authentication since only a link-local IPv6 address
can be used prior to the completion of a succesful authentication.
PRE which is one hop away from PaC receives PANA messages and relays
the message contents (payload) by encapsulating it in a message
parameter called Attribute Value Pair (AVP). PRE also needs to send
header contents such as PaC's IP address and UDP port number in a
different AVP. PRE has IP routing established with PAA which could
be several hops away. PAA sends its reply messages in which the
payload is encapsulated in an AVP. It also adds the AVP containing
PaC's IP address and UDP port number. PRE sends creates a link local
PDU using these AVPs and sends it to PaC.
The requirements for the use of PANA as a bootsrapping protocol can
be stated as follows:
o A new entity called PANA Relay Element needs to be added to the
PANA architecture. Behaviour of PANA Relay Element needs to be
defined.
o New AVPs needed for PANA Relay Element operation for properly
relaying messages from the client to the authenticator and vice
versa are required to be specified.
O'Flynn, et al. Expires May 12, 2011 [Page 13]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
o An extension to PANA to securely distribute keys from the PANA
Authentication Agent to the PANA Client using AES Key Wrap with
Padding algorithm needs to be defined. This is needed in order to
use PANA for group key distribution.
5.4. HIP-DEX
[RFC4423] introduces the Host Identity Protocol (HIP) where the Host
Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit
length Host Identity Tag (HIT) is derived from the HI (hashed) and
functions as an IPv6 address (/128 prefix) for applications. A four-
packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX)
establishes a security association (SA, similar to IKE), indexed by
the HITs, but independent of the IP address. So HIP can be
considered as a shim layer between the transport(TCP/UDP) and IP,
providing authentication, data confidentiality, mobility in one
basket.
The HIP-BEX involves many crypto primitives that are difficult to run
on constrained nodes. HIP Diet Exchange (HIP-DEX)
[I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight.
Basically, HIP-DEX a variant of the HIP-BEX specifically designed to
use as few crypto primitives as possible yet still provide the same
class of security features as HIP-BEX.
HIP-DEX can be used for mutual authentication between two endpoints.
After mutual authentication, the two endpints establish a shared
secret, which is fresh and fed into the encryption algorithm for data
confidentiality. So HIP-DEX can achieve the authentication, key
freshness and data confidentiality objectives of security
bootstrapping.
When a node wants to authenticate to the network using HIP and Diet-
HIP, it should be able to complete the HIP-BEX or HIP-DEX with the
trust anchor or some delegate. In HIP, it does not matter how many
domains, and nodes can authenticate each other as long as they have
the secret.
In the architecture introduced in Section 2.2 the node and router
could be the HIP end-points. Depending on who initiates the HIP Diet
Exchange, the node or router could act as the HIP initiator and HIP
responder respectively. And the initiator and responder can be
multiple hops way from each other, as long as there is an IP
connectivity between them.
An important requirement for the HIP-DEX to work in the architecture,
the initiator should be able to get the IP address of the responder,
either using DNS infrastructure or local configuration.
O'Flynn, et al. Expires May 12, 2011 [Page 14]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
5.5. 802.1X
IEEE 802.1X defines how EAP packets can be transported over in Layer
2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into
EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and
the authenticator. EAPOL can also be used in 802.11 wireless links.
To enable IEEE 802.15.4 devices to use EAP authentication, EAP
packets encapsulated in EAPOL frames can be carried as payload in
802.15.4 data frames [802.15.4]. EAPOL is well defined and widely
used and it lends itself to be easily carried in 802.15.4 data
frames. For this, Frame Type subfield of the Frame Control Field of
IEEE 802.15.4 MAC header needs to be set to a special value to
indicate the type of the payload, i.e. 802.1X encapsulated EAP
packets. EAPOL packets are encoded following common EAPOL PDU
structure defined in [802.1x] into the data payload field of 802.15.4
data frames.
Authentication proceeds as follows: authenticator authenticates the
supplicants that are on the next hop first. This enables a secure
link between the authenticator and these first-hop nodes. First-hop
nodes or router become Relay Authenticators in the next phase of
authentication. Relay authenticators tunnel EAPOL frames to the
authenticator in the secure link established. This way all the
supplicants are gradually authenticated.
The keys established from a successful EAP method (such as PSK mode
of TLS), the node runs neighbor discovery protocol to get an IPv6
address assigned [I-D.ietf-6lowpan-nd]. Data transfer can be secured
using DTLS or IPSec. Keys derived from EAP TLS are used in either
generating DTLS ciphering keys after a successful DTLS handshake or
IPSec ESP ciphering keys after a successful IKEv2 handshake.
802.1X can achieve the authentication, key freshness and data
confidentiality objectives of security bootstrapping. Multi domain
operation is intrinsically supported due to the use of EAP and AAA.
The requirements for the use of 802.1X defined EAPOL as a
bootsrapping protocol can be stated as follows:
o A special value in the Frame Type subfield of the Frame Control
Field of IEEE 802.15.4 MAC header to indicate the type of the
payload,
o Group addresses for 802.15.4 corresponding to EAPOL Group Address
Assignments defined in Table 11.1 of [802.1x], especially to be
used in EAPOL-Start packet.
O'Flynn, et al. Expires May 12, 2011 [Page 15]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
o Which MAC frames of beacon, data, acknowledgment and MAC command
as defined in [802.15.4] with what security levels are mapped to
controlled port, which MAC frames with what security levels are
mapped to uncontrolled port and which MAC frames are never mapped
to any of controlled/uncontrolled port (i.e., the payload of those
frames are used by the MAC-ayer ieself and never used by upper
layers).
6. Security Considerations
TBD.
7. IANA Considerations
This memo includes no request to IANA.
8. Acknowledgements
Thanks to Zach Shelby for editing, comments, and overall assistance.
Special thanks also to Rene Struik and Carsten Borman for their
comments that helped us improve the writing.
9. References
9.1. Normative References
[802.15.4]
IEEE Std 802.15.4-2006, "Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low Rate
Wireless Personal Area Networks (WPANs)", September 2006.
[802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network
Access Control", February 2010.
[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.
O'Flynn, et al. Expires May 12, 2011 [Page 16]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
[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.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
[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.
[SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical
Requirements Document", April 2010.
9.2. Informative References
[C1222] American National Standard, "Protocol Specification For
Interfacing to Data Communication Networks", ANSI C12.22-
2008, 2008.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low-power and Lossy Networks",
draft-ietf-6lowpan-nd-14 (work in progress), October 2010.
[I-D.ietf-core-coap]
Shelby, Z., Frank, B., and D. Sturek, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-03
(work in progress), October 2010.
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Networks, D., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-14 (work in
O'Flynn, et al. Expires May 12, 2011 [Page 17]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
progress), October 2010.
[I-D.moskowitz-hip-rg-dex]
Moskowitz, R., "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-rg-dex-02 (work in progress),
July 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.
[I-D.ohba-pana-keywrap]
Chakrabarti, S., Cragie, R., Duffy, P., Ohba, Y., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA) Extension for Key Wrap",
draft-ohba-pana-keywrap-01 (work in progress),
October 2010.
[NISTIR7628VOL1]
The Smart Grid Interoperability Panel - Cyber Security
Working Group, "Guidelines for Smart Grid Cyber Security:
Vol. 1, Smart Grid Cyber Security Strategy, Architecture,
and High-Level Requirements", NISTIR 7628, vol. 1, 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.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
O'Flynn, et al. Expires May 12, 2011 [Page 18]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295,
August 2008.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, February 2009.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Appendix A. Examples of Node Configuration
Before any detail on methods is explored, the following section will
provide various examples this document could cover. Exact
requirements will be brought forward in subsequent sections. For the
reader's general understanding this section is placed to give an idea
of an acceptable usage scenario.
A.1. Smart Energy
A.1.1. Initial Meter Installation
The meter is initially loaded with code and network keys through a
physical interface at the factory. The meter is installed at a
customers home, and configured by the installer through the backbone
link (via GSM modem, etc). Both operations can be performed through
methods defined herein.
A.1.2. Home Expansions
The user wishes to join a thermostat onto the network. They press a
button on the thermostat, which enters join mode. They press a
button on the smart meter, which allows nodes to join the network.
The devices both have displays, so they display a certain number
which the user verifies match on both devices. The thermostat has
now securely joined the network.
O'Flynn, et al. Expires May 12, 2011 [Page 19]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
A.2. Consumer Products
A.2.1. Connecting DVD Remote to DVD Player
The user pushes a join button on the DVD remote and DVD player. The
devices find each other, and blink in unison to indicate to the user
which two devices will join. The user presses the button to confirm
this, and the two devices are now joined together.
A.2.2. Adding a TV to a network with a DVD player and remote
The user then presses the join button on the DVD player and TV. The
devices again find each other and blink in unison, with the addition
that the remote control also blinks to indicate it is present in the
network.
A.2.3. Providing GPS Location Data
A user has a simple GPS receiver (that has no user interface) they
wish to broadcast location data with. The user switches on their
camera, and enters a PIN from the base of the GPS. The user can now
view GPS information such as satellite health from their camera. In
addition photos are automatically tagged with location information.
A.3. Commercial Building Automation
A.3.1. Light Installation
The electrician installs the light fixture. Each light has a barcode
printed on it. They use a handheld barcode scanner tool, which acts
as the commissioning tool. When they scan a barcode with the tool,
the tool asks the electrician to enter some additional information
such as light fixture location. The tool securely registers the
light fixture on the network, along with setting parameters inside
the light fixture.
Appendix B. Example Exchanges
The following details how the protocol handles certain conditions and
situations through examples. Note that each example is a more
detailed description of the examples in Appendix A.
B.1. Smart Energy: Meter Manufacture
B.2. Smart Energy: Meter Installation
O'Flynn, et al. Expires May 12, 2011 [Page 20]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
B.3. Smart Energy: Home Expansion
B.4. Consumer: Connecting DVD Remote to DVD Player
Supported User Interface Profiles
+----------------+------------+----------------+
| Profile | DVD Player | Remote Control |
+----------------+------------+----------------+
| none | Y | Y |
| simple | Y | Y |
| numerical | Y | N |
| alphanumerical | Y | N |
| Graphical | Y | N |
+----------------+------------+----------------+
Supported Bootstrap Transport Layers
+----------+------------+----------------+
| Layer | DVD Player | Remote Control |
+----------+------------+----------------+
| Physical | Y | Y |
| 802.15.4 | Y | Y |
| IrDA | Y | N |
+----------+------------+----------------+
Supported Security Methods
+------------------+------------+----------------+
| Method | DVD Player | Remote Control |
+------------------+------------+----------------+
| None | Y | Y |
| EAP | Y | N |
| Asymmetric, User | Y | Y |
| Asymmetric, CA | Y | N |
+------------------+------------+----------------+
The DVD player and remote control have a number of ways in which they
could be joined together. The remote control does not have any
unique identifier printed on it, thus no pre-shared key can be
identified. This leaves either an unsecure joining method, or some
asymmetric security method.
The remote control has a button on it for 'join', as does the DVD
player. The user pushes the button on the DVD player, and then
pushes the button on the remote control. Based on the UI profile,
this causes the following to occur:
O'Flynn, et al. Expires May 12, 2011 [Page 21]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
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.
B.5. Consumer: Adding a TV to a network with a DVD player and remote
This network will have three devices: a TV, a DVD Player, and a
Remote Control. The user will run the bootstrap protocol between the
TV and Remote Control in this example, although it could also be run
between the TV and DVD player.
Supported User Interface Profiles
+----------------+----+----------------+
| Profile | TV | Remote Control |
+----------------+----+----------------+
| none | Y | Y |
| simple | Y | Y |
| numerical | Y | N |
| alphanumerical | Y | N |
| Graphical | Y | N |
+----------------+----+----------------+
Supported Bootstrap Transport Layers
+----------+----+----------------+
| Layer | TV | Remote Control |
+----------+----+----------------+
| Physical | Y | Y |
| 802.15.4 | Y | Y |
| IrDA | Y | N |
+----------+----+----------------+
O'Flynn, et al. Expires May 12, 2011 [Page 22]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
Supported Security Methods
+------------------+----+----------------+
| Method | TV | Remote Control |
+------------------+----+----------------+
| None | Y | Y |
| EAP-GPSK | Y | N |
| Asymmetric, User | Y | Y |
| Asymmetric, CA | Y | N |
+------------------+----+----------------+
The TV and remote control have a number of ways in which they could
be joined together. The remote control does not have any unique
identifier printed on it, thus no pre-shared key can be identified.
This leaves either an unsecure joining method, or some asymmetric
security method.
The remote control has a button on it for 'join', as does the TV. In
this example two sequence will be considered: where the TV button is
pressed first, and where the remote control button is pressed first.
If the TV join button is pressed first:
o TV scans for existing networks in advertise mode. Finding none,
it starts a new network and that network enters advertise mode.
o The remote scans for a network, and then finds the TV's network.
o The remote informs the TV it is on an existing network, and thus
will require the TV to join this network.
o The devices generate a shared secret, and both blink their LED in
a unique pattern.
o The DVD player in addition blinks, so the user is informed that if
they confirm the join action the resulting network will have all
three devices in it.
o The user confirms both devices are blinking the same pattern, as
both LEDs are blinking in unison.
o The TV displays 'JOIN OK' onscreen, along with any information
about the network it just joined.
If the remote control join button is pressed first:
o Remote control scans for existing networks in advertise mode.
Finding none, it advertises it's network.
O'Flynn, et al. Expires May 12, 2011 [Page 23]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
o The TV scans for a network, and then finds the remote control's
network.
o The devices generate a shared secret, and both blink their LED in
a unique pattern.
o The DVD player in addition blinks, so the user is informed that if
they confirm the join action the resulting network will have all
three devices in it.
o The user confirms both devices are blinking the same pattern, as
both LEDs are blinking in unison.
o The TV displays 'JOIN OK' onscreen, along with any information
about the network it just joined.
B.6. Consumer: Providing GPS Location Data
B.7. Commercial: Building Automation
Authors' Addresses
Colin Patrick O'Flynn
Atmel Corporation
Colorado Springs, Colorado
USA
Phone:
Email: colin.oflynn@atmel.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Email: sarikaya@ieee.org
Yoshihiro Ohba
Toshiba
Tokyo, Japan
Email: yoshihiro.ohba@toshiba.co.jp
O'Flynn, et al. Expires May 12, 2011 [Page 24]
Internet-Draft draft-oflynn-core-bootstrapping November 2010
Zhen Cao
China Mobile
Beijing, China
Email: caozhen@chinamobile.com
Robert Cragie
Pacific Gas and Electric
89 Greenfield Crescent
Wakefield, UK WF4 4WA
Email: robert.cragie@gridmerge.com
O'Flynn, et al. Expires May 12, 2011 [Page 25]