One document matched: draft-he-iot-security-bootstrapping-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited by Steinthor Bjarnason -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-homenet-arch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-arch.xml">
<!ENTITY I-D.behringer-autonomic-network-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behringer-autonomic-network-framework.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7030 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7030.xml">
]>
<rfc category="info" docName="draft-he-iot-security-bootstrapping-00"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="security Bootstrapping of 802.15.4 based IoT">Security
Bootstrapping of IEEE 802.15.4 based Internet of Things</title>
<author fullname="Danping He" initials="D." surname="He">
<organization>Huawei</organization>
<address>
<email>ana.hedanping@huawei.com</email>
</address>
</author>
<date day="18" month="January" year="2015"/>
<abstract>
<t>Network level security bootstrapping and joining device level
security bootstrapping mechanisms are described in this document. They
are proposed for security bootstrapping of the Internet of Things
networks, which implement IETF protocols (e.g. 6LoWPAN, 6lo, RPL, AODV,
DSR) over IEEE 802.15.4. The network level security bootstrapping is
useful at the very beginning of a newly deployed IoT network. It
automatically and hierarchically adds all the devices to security domain
and helps establish security communication. The joining device level
security bootstrapping provides comprehensive mechanism for different
IoT devices joining an existing IoT network.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>An IoT network is composed of various numbers of connected things
with communication ability and different functionalities (sensing unit,
control logic). They cooperate together to accomplish specific tasks
required by users. Things in an IoT network might be supplied by
different vendors, and are normally resource-constrained devices that
with limited power supply, communication capability, CPU performance and
memory volume.</t>
<t><xref target="IEEE802.15.4"/>is a standard which specifies the
physical layer and media access control for low-rate wireless personal
area networks (LR-WPANs). It is widely used in wireless sensor networks
nowadays, 6LoWPAN WG (concluded) developed RFC 4944<xref
target="RFC4944"/> to describe how to transmit IPv6 packets over
802.15.4, and support mesh routing in LR-WPANs. 6lo WG defines generic
IPv6 packet header compression method <xref target="RFC7400"/> for
LR-WPANs. 6tisch tries to build adaptation protocol for 802.15.4e
protocol. Roll develops routing protocol RPL<xref target="RFC6550"/> for
IPv6 based low power and lossy networks. IEEE 802.15.4 is foreseen as
the most used lower layer protocol for low rate IoT networks with
resource constrained devices.</t>
<t>Creating security domains from previously unassociated IoT devices is
a key operation in the IoT network and in the lifecycle of a thing.
Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard
security bootstrapping protocol should be light-weight with low
complexity. The protocol must allow for commissioning of devices from
different manufacturers and facilitate transitions of control amongst
devices during the device's and system's lifecycle.</t>
<t>Traditional security bootstrapping approaches include device
authentication and key generation/distribution, which tend to impose
configuration burdens upon users. For example, users need to follow a
series of instruction steps for WPA2-PSK (WiFi Protected Access 2,
Pre-shared key) configuration, even though the pre-shared key mode is
the simplest option for using WPA. Establishing security among IoT
devices becomes more complicated since they don't always provide user
interface to input necessary security information. Furthermore, the
scale of the IoT network can be large, human intervention in large scale
security bootstrapping is expensive and low efficient.</t>
<t><xref target="I-D.pritikin-anima-bootstrapping-keyinfra"/> proposes a
zero-touch bootstrapping key infrastructure to allow joining device
securely and automatically bootstraps itself based on 802.1AR
certificate. It can't be directly used in 802.15.4 devices due to the
high security complexity and heavy communication overhead. Its
architecture is not built by considering different possible 802.15.4
network topologies and the underlying routing protocols developed by
IETF.</t>
<t><xref target="I-D.struik-6tisch-security-considerations"/>defines
high level requirements and proposes two types of security mechanisms:
single-stage and two-stage. Even though the two types of security AA
mechanisms offer flexible solutions. The underlying security
architecture can neither be used directly by 802.15.4 IoT networks. IEEE
802.15.4 also defines two-step mechanism for nodes joining network with
layer 2 authentication. Without considering use of IPv6 infrastructure,
the solution is not comprehensive.</t>
<t>Another key challenge for security bootstrapping of a device the
above mentioned mechanisms is that they are not feasible to commission a
device when the adjacent devices have not been commissioned yet. As a
result, this document describes and standardizes two types of automatic
bootstrapping methods for 802.15.4 based IoT networks: network level
security bootstrapping and joining device level security
bootstrapping.</t>
</section>
<section title="new section">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>This specification requires readers to be familiar with all the terms
and concepts that are discussed in "Neighbor Discovery for IP version 6
(IPv6)" <xref target="RFC4861"/>, "IPv6 over Low-Power Wireless Personal
Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
Goals" <xref target="RFC4919"/>.This specification makes extensive use
of the same terminology defined in <xref target="RFC4944"/>.</t>
</section>
<section title="IEEE 802.15.4 based IoT topologies">
<t>A general architectural overview of the IEEE 802.15.4 based IoT is
provided in Figure 1. All the devices communicate to backbone server
through 6LBR. FFDs communicate with each other directly or indirectly
via hopping or 6LBR. RFDs directly connect to FFDs, and the number of
RFDs that attach to a FFD may vary.</t>
<figure>
<artwork><![CDATA[ /////-------------------\\\\\
| Server |
\\\\\-------------------/////
|
+-------------------------------------------------------------------+
| 6LBR |
+--------------------------------+----------------------------------+
| +--------+-----------+ |
| +-**->| FFD_2 |<--**-+ |
| | +--------------------+ | |
+-----------------+--+ +---+--------------+
| FFD_1 | <---------*****--------> | FFD_N |
+--------------------+ +------------------+
| | |
+--------------+ +--------------+ +--------------+
| RFD_11 | | RFD_1M | | FFD_N1 |
+--------------+ +--------------+ +--------------+
Figure 1
]]></artwork>
</figure>
</section>
<section title="Network level security bootstrapping">
<t>At the very beginning of the networking once nodes are deployed,
network level security bootstrapping assist automatically creates
security domain and hierarchically adds devices to network. The
mechanism is realized by three phases:</t>
<t><list style="hanging">
<t hangText="Phase 1: ">Security bootstrapping for the first hop
FFDs via 6LBR</t>
<t hangText="Phase 2: ">Security bootstrapping for further FFDs via
configured FFDs</t>
<t hangText="Phase 3: ">Security bootstrapping for RFDs via
configured FFDs</t>
</list></t>
<section title="Security bootstrapping for the first hop FFDs via 6LBR">
<t>When devices are power-on, 6LBR broadcasts beacon frames to
neighboring nodes. The FFDs that receive the beacon frames are the
first-hop FFDs. As shown in Figure 2, upon receiving the beacon frame,
a first-hop FFD associates with 6LBR at link layer according to IEEE
802.15.4. The FFD then presents credential to 6LBR, which are
forwarded to trust center to be validated. EAP can be used to realize
the authentication procedure. If the validation is successful, the IP
address and network key are generated and delivered to the FFD.
Further configurations such as cluster head selection, routing
protocol, etc., can be realized afterwards. Otherwise if the
validation fails, the 6LBR refuses adding the FFD to its domain.</t>
<figure>
<artwork><![CDATA[
First-hop FFD 6LBR TC
| | |
| Beaconing | |
|<--------------------------------| |
| | |
| IEEE 802.15.4 | |
| MAC unsecure association | |
|<------------------------------->| |
| | |
| | |
| Authentication | Auth.material check |
|<------------------------------->|<---------------------->|
| Network key and IP address | IP address |
| | |
| | |
| Further Configuration | |
|<------------------------------->| |
| | |
| | |
Figure 2
]]></artwork>
</figure>
</section>
<section title="Security bootstrapping for further FFDs via configured FFDs">
<t>The configured FFDs broadcast beacon frames to neighboring nodes.
The unconfigured FFD that receives the beacon frame associates with
the configured FFD at link layer. A FFD may receive multiple beacon
frames from more than one configured FFDs, it can select the first one
to associate or the one with strongest received power strength. The
selection policy is out of the scope of the current document. The
unconfigured FFD then presents credential to the associated configured
FFD, which are forwarded to 6LBR and TC to be validated. If EAP is
used, PANA can be used to relay the authentication message from
configured FFDs to 6LBR. If the validation is successful, the IP
address and network key are generated and delivered to the FFD.
Further configurations such as routing protocol can be realized
afterwards. Otherwise if the validation fails, the 6LBR refuses adding
the FFD to its domain.</t>
<figure>
<artwork><![CDATA[ Unconfigured FFD Configured FFD 6LBR TC
| | | |
| Beaconing | | |
|<--------------------------------| | |
| | | |
| IEEE 802.15.4 | | |
| MAC unsecure association | | |
|<------------------------------->| | |
| | | |
| | | |
| Authentication | Relay | Auth.check |
|<------------------------------->|<------------>|<---------------->|
| Network key and IP address | | IP address |
| | | |
| | | |
| Further Configuration | | |
|<-------------------------------- ------------->| |
| | | |
| | | |
Figure 3 ]]></artwork>
</figure>
</section>
<section title="Security bootstrapping for RFDs via configured FFDs">
<t>The configured FFDs broadcast beacon frames to neighboring nodes.
The unconfigured RFD that receives the beacon frame associates with
the configured FFD at link layer. A RFD may receive multiple beacon
frames from more than one configured FFDs. It can select one device to
associate, e.g. the first one that replies or the one with strongest
received power strength. The unconfigured RFD then presents credential
to the associated configured FFD, which are forwarded to 6LBR and TC
to be validated. If the validation is successful, the IP address and
network key are generated and delivered to the RFD. Otherwise if the
validation fails, the FFD refuses adding the RFD to its domain.</t>
<figure>
<artwork><![CDATA[ RFD Configured FFD 6LBR TC
| | | |
| Beaconing | | |
|<--------------------------------| | |
| | | |
| IEEE 802.15.4 | | |
| MAC unsecure association | | |
|<------------------------------->| | |
| | | |
| | | |
| Authentication | Relay | Auth.check |
|<------------------------------->|<------------>|<---------------->|
| Network key and IP address | | IP address |
| | | |
| | | |
| Further Configuration | | |
|<-------------------------------- ------------->| |
| | | |
| | | |
Figure 4 ]]></artwork>
</figure>
</section>
</section>
<section title="Joining Device Security Bootstrapping">
<t>New devices may be added to an existing IoT due to various reasons.
As a result the security bootstrapping can be devided into the
bootstrapping of joining RFD and bootstrapping of joining FFD.</t>
<section title="Bootstrapping of joining RFD via configured FFD">
<t>A joining RFD broadcasts beacon frames to neighboring nodes. The
configured FFDs that receive the beacon frames, decide whether
allowing the RFD associating at link layer. A RFD may receive multiple
replies from more than one configured FFDs. It can select one device
to associate, e.g. the first one that replies or the one with
strongest received power strength. The joining RFD then presents
credential to the associated configured FFD, which is forwarded to
6LBR and TC to be validated. If the validation is successful, the IP
address and network key are generated and delivered to the RFD.
Otherwise if the validation fails, the FFDrefuses adding the RFD to
its domain.</t>
<figure>
<artwork><![CDATA[ Joining RFD Configured FFD 6LBR TC
| | | |
| Beaconing | | |
|-------------------------------->| | |
| | | |
| IEEE 802.15.4 | | |
| MAC unsecure association | | |
|<------------------------------->| | |
| | | |
| | | |
| Authentication | Relay | Auth.check |
|<------------------------------->|<------------>|<--------------->|
| Network key and IP address | | IP address |
| | | |
| | | |
| Further Configuration | | |
|<-------------------------------- ------------->| |
| | | |
| | | |
Figure 5
]]></artwork>
</figure>
</section>
<section title="Bootstrapping of joining FFD via configured FFD/6LBR ">
<t>A joining FFD broadcasts beacon frames to neighboring nodes. The
configured FFDs that receive the beacon frames, decide whether
allowing the FFD associating at link layer. A FFD may receive multiple
replies from more than one configured FFDs or directly from the 6LBR.
It can select one device to associate, e.g. the first one that replies
or the one with strongest received power strength. The joining FFD
then presents credential to the associated configured FFD/6LBR, which
is forwarded to TC to be validated. If the validation is successful,
the IP address and network key are generated and delivered to the FFD.
Further configurations such as routing protocol can be realized
afterwards. Otherwise if the validation fails, the 6LBR refuses adding
the FFD to its domain.</t>
<figure>
<artwork><![CDATA[
+---------------------------+
Joining FFD | Configured FFD 6LBR | TC
| +------+--------------+-----+ |
| Beaconing | | |
|-------------------------------->| | |
| | | |
| IEEE 802.15.4 | | |
| MAC unsecure association | | |
|<------------------------------->| | |
| | | |
| | | |
| Authentication | Relay | Auth.check |
|<------------------------------->|<------------>|<---------------->|
| Network key and IP address | | IP address |
| | | |
| | | |
| Further Configuration | | |
|<-------------------------------- ------------->| |
| | | |
| | | |
Figure 6]]></artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgement">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.4944'?>
<?rfc include='reference.RFC.7400'?>
<?rfc include='reference.RFC.6550'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.4919'?>
<reference anchor="IEEE802.15.4"
target="http://standards.ieee.org/findstds/standard/802.15.4-2011.html">
<front>
<title>IEEE Std. 802.15.4-2011</title>
<author fullname="" surname="IEEE Standard">
<organization/>
</author>
<date month="October" year="2011"/>
</front>
</reference>
&RFC2119;
</references>
<references title="Informative References">
<reference anchor="I-D.pritikin-anima-bootstrapping-keyinfra">
<front>
<title>Bootstrapping Key Infrastructures</title>
<author fullname="Max Pritikin " initials="M." surname="Pritikin">
<organization/>
</author>
<author fullname="Michael H. Behringer " initials="M.H."
surname="Behringer ">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Steinthor Bjarnason " initials="S."
surname="Bjarnason ">
<organization>3</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date day="3" month="November" year="2014"/>
</front>
</reference>
<reference anchor="I-D.struik-6tisch-security-considerations">
<front>
<title>6TiSCH Security Architectural Considerations</title>
<author fullname="Rene Struik" initials="R." surname="Struik ">
<organization/>
</author>
<date day="9" month="January" year="2015"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:23 |