One document matched: draft-kumar-6lo-selective-bootstrap-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4861 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY RFC4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5889 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5889.xml">
<!ENTITY RFC6690 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6690.xml">
<!ENTITY RFC6763 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6763.xml">
<!ENTITY RFC6775 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC5191 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml">
<!ENTITY RFC6345 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6345.xml">
<!ENTITY RFC5216 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY RFC6347 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC4279 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
<!ENTITY RFC6655 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6655.xml">
<!ENTITY RFC7252 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC7250 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY RFC7251 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7251.xml">
<!ENTITY RFC7390 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7390.xml">
<!ENTITY AES PUBLIC "" "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.197.2001.xml">
<!ENTITY I-D.jennings-core-transitive-trust-enrollment SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-core-transitive-trust-enrollment.xml">
<!ENTITY I-D.pritikin-anima-bootstrapping-keyinfra SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pritikin-anima-bootstrapping-keyinfra.xml">
<!ENTITY I-D.struik-6tisch-security-considerations SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.struik-6tisch-security-considerations.xml">
<!ENTITY I-D.he-iot-security-bootstrapping SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.he-iot-security-bootstrapping.xml">
<!ENTITY I-D.ohba-6tisch-security SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ohba-6tisch-security.xml">
<!ENTITY I-D.ietf-core-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-resource-directory.xml">
<!ENTITY I-D.richardson-6tisch--security-6top SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.richardson-6tisch--security-6top.xml">
<!ENTITY I-D.kumar-dice-dtls-relay SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kumar-dice-dtls-relay.xml">
<!ENTITY I-D.vanderstok-core-comi SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vanderstok-core-comi.xml">
]>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-kumar-6lo-selective-bootstrap-00">
<front>
<title abbrev="Bootstrap">Security Bootstrapping over IEEE 802.15.4 in selective order</title>
<author initials="S.S." surname="Kumar" fullname="Sandeep S. Kumar">
<organization>Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<city>Eindhoven</city>
<region></region>
<code>5656 AE</code>
<country>NL</country>
</postal>
<email>ietf.author@sandeep-kumar.org</email>
</address>
</author>
<author fullname="Peter van der Stok" initials="P." surname="van der Stok">
<organization>Consultant</organization>
<address>
<email>consultancy@vanderstok.org</email>
</address>
</author>
<date/>
<area>Internet Area</area>
<workgroup>6lo</workgroup>
<abstract>
<t>
Low-resource devices in a Low-resource and Lossy Network (LLN) can be based on a mesh network using the IEEE 802.15.4 link standard. Security in these networks MUST be enforced at the link level. Provisioning the devices in a secure manner with keys (often called security bootstrapping) to encrypt and authenticate the link-layer messages is the subject of this specification. This proposal distinguishes itself from other bootstrap proposals by requiring that the devices can be secured in an order determined by the needs of the installation procedure. Other proposals use an "onion model", where first the devices one-hop away from the initial device (often the border router) are secured, followed by the devices that are one-hop away from already secured devices.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) <xref target="RFC4944" /> on IEEE 802.15.4 <xref target="ieee802.15.4" /> wireless networks is becoming common in many professional domains such as lighting controls. However commissioning of such networks is not easy due to a lack of standardized secure bootstrapping mechanisms for these networks.</t>
<t>The security of IEEE 802.15.4 MAC frames is based on Advanced Encryption Standard (AES)
<xref target="FIPS.197.2001" /> in Counter with CBC-MAC Mode (CCM) <xref target="CCM" /> which provides confidentiality and authenticity. There are different security levels or combinations of authenticated encryption defined in IEEE 802.15.4 as shown in <xref target="MAC_security" />.</t>
<texttable anchor='MAC_security' title="IEEE 802.15.4 supported Security Levels">
<ttcol align='center'> Security Level </ttcol>
<ttcol align='center'> Confidentiality</ttcol>
<ttcol align='center'> Message Integrity Code (MIC)</ttcol>
<c>0</c> <c>None</c> <c>None</c>
<c>1</c> <c>None</c> <c>Yes (4 byte MIC)</c>
<c>2</c> <c>None</c> <c>Yes (8 byte MIC)</c>
<c>3</c> <c>None</c> <c>Yes (16 byte MIC)</c>
<c>4</c> <c>Yes</c> <c>None</c>
<c>5</c> <c>Yes</c> <c>Yes (4 byte MIC)</c>
<c>6</c> <c>Yes</c> <c>Yes (8 byte MIC)</c>
<c>7</c> <c>Yes</c> <c>Yes (16 byte MIC)</c>
</texttable>
<t>Although IEEE 802.15.4 defines how security can be enabled between nodes, it does not specify the provisioning and management of the keys. Therefore securing a 6lowpan network with devices from multiple manufacturers with different provisioning techniques is often tedious and time consuming.
</t>
<t>
Some industry standards have tried to solve the issue by using a mix of other protocols with extensions. For example, Zigbee-IP <xref target="ZigbeeIP" /> uses Protocol for carrying Authentication for Network Access (PANA) <xref target="RFC5191" /> with the additional PANA-Relay <xref target="RFC6345"/> to carry EAP-TLS <xref target="RFC5216" /> packets to the joining node as shown in <xref target="PANA-blocks"/>. </t>
<figure anchor="PANA-blocks" title="EAP over PANA for bootstrapping"><artwork align="left"><![CDATA[
+-----------------+
| EAP Peer | +-------------+
+-----------------+ |PANA Relay |
|PANA Client (PaC)|<-->|Element (PRE)|
+-----------------+ +------^------+
Joining Node |
|
|
+-------v-----------+ +-----------+
|EAP Authenticator | |EAP Server |
+-------------------+<-------->+-----------+
|PANA Authentication| |AAA Server |
|Agent (PAA) | +-----------+
+-------------------+
]]></artwork></figure>
<t>The additional protocol stack of PANA and EAP provides for a large amount of flexibility in terms of potential security protocols and cryptographic algorithms that can be used for authentication and key distribution. However this flexibility is often not needed in IoT scenarios or often not wanted for inter-operability reasons (e.g. Zigbee-IP only uses EAP-TLS mode with two possible cryptosuites). DTLS-Relay <xref target="I-D.kumar-dice-dtls-relay" /> as depicted in <xref target="DTLSRelay-blocks" /> is an alternative simpler proposal based on trust enrolment <xref target="I-D.jennings-core-transitive-trust-enrollment" /> that provides the same results by reusing the security protocols (like DTLS <xref target="RFC6347" />) that already exist on IoT devices. </t>
<figure anchor="DTLSRelay-blocks" title="DTLS Relay for bootstrapping"><artwork align="left"><![CDATA[
+--------+ +-------+ +-------+
| DTLS | | DTLS | | DTLS |
| Client |<------>| Relay |<-------->|Server |
+--------+ +-------+ +-------+
Joining AAA
Node Server
]]></artwork></figure>
<t>Numerous other recent proposals like <xref target="I-D.pritikin-anima-bootstrapping-keyinfra" />, <xref target="I-D.richardson-6tisch--security-6top" />, <xref target="I-D.struik-6tisch-security-considerations" />, <xref target="I-D.ohba-6tisch-security" />, <xref target="I-D.he-iot-security-bootstrapping" /> discuss network bootstrapping in multi-hop networks and their architectural implications. However an essential aspect of all these techniques (including the PANA-Relay and DTLS-Relay) is that they rely on an "Onion" topology for bootstrapping: devices which are one-hop wireless from the Border Router (or Commissioning Device) are provisioned first. Devices multiple hops removed from the border router are provisioned by an already provisioned neighbour (an "Onion" layer) until the whole network is bootstrapped.
</t>
<t>Such an "Onion" model can be limiting in various professional domains where a large number of devices need to be commissioned (provided with installation information) in an order determined by their physical layout rather than by the wireless network topology. The wireless network topology is often unknown to a commissioner and may vary over time due to environmental conditions (e.g. presence of scaffolding during construction). Therefore, "onion" bootstrapping proposals force a tedious separation of the actual device commissioning done by a domain expert from the security bootstrapping of the devices. The purpose of the bootstrapping proposal of this specification is a simultaneous execution of commissioning and bootstrapping.
</t>
<t>
In this specification, the bootstrapping order of the nodes can be selected by a commissioner.
</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
<t>Readers are expected to be familiar with all the terms and concepts
that are discussed in <xref target="RFC4861">"neighbour Discovery for
IP version 6"</xref>, <xref target="RFC4862">"IPv6 Stateless Address
Autoconfiguration"</xref>, <xref target="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref>,
<xref target="RFC6775">"neighbour Discovery Optimization
for Low-power and Lossy Networks"</xref> and <xref target="RFC4944">
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>.
</t><t>
This specification uses the following terms from <xref target="RFC6775"/>:
<list style="hanging">
<t hangText="6LoWPAN link:">
A wireless link determined by single IP hop reachability of
neighbouring nodes. These are considered links with undetermined
connectivity properties as in <xref target="RFC5889"/>.</t>
<t hangText="6LoWPAN Node (6LN):">
A 6LoWPAN node is any host or router participating in a LoWPAN.
This term is used when referring to situations in which either a
host or router can play the role described.</t>
<t hangText="6LoWPAN Router (6LR):">
An intermediate router in the LoWPAN that is able to send and
receive Router Advertisements (RAs) and Router Solicitations (RSs)
as well as forward and route IPv6 packets. 6LoWPAN routers are
present only in route-over topologies.</t>
<t hangText="6LoWPAN Border Router (6LBR):">
A border router located at the junction of separate 6LoWPAN
networks or between a 6LoWPAN network and another IP network.
There may be one or more 6LBRs at the 6LoWPAN network boundary. A
6LBR is the responsible authority for IPv6 prefix propagation for
the 6LoWPAN network it is serving. An isolated LoWPAN also
contains a 6LBR in the network, which provides the prefix(es) for
the isolated network.</t>
<t hangText="Router:">
Either a 6LR or a 6LBR. Note that nothing in this document
precludes a node being a router on some interfaces and a host on
other interfaces as allowed by <xref target="RFC2460"/>. </t>
</list>
This specification uses the following new terms:
<list style="hanging">
<t hangText="Commissioning Tool (CT):">
A processor that contains keying material, authorizes nodes to join, and communicates the keying material. </t>
<t hangText="6LoWPAN Joining Node (6JN):">
A 6LoWPAN node that is next to join a secured LoWPAN mesh. This term is used when either the node sends a join request to the CT or the CT sends key material to the node for joining.</t>
<t hangText="6LoWPAN Secured Router (6SR):">
A 6LoWPAN router that has joint a secured LoWPAN mesh. This term is used when the router has received the key material to join the LoWPAN mesh.</t>
<t hangText="6LoWPAN Un-secured Router (6UR):">
A 6LoWPAN router that has NOT joint a secured LoWPAN mesh. This term is used when the router has received no key material to join the LoWPAN mesh.</t>
</list>
</t>
</section>
<section anchor="usecase" title="Use Case">
<t>
In lighting controls a major shift is on its way from lighting specific networking standards like <xref target="DALI"/> to Internet networking standards. This shift has a profound influence on the installation and commissioning of the lighting control network. With special purpose networks, the installation of the lighting control and the network were done during the same installation phase.
</t><t>
The choice for the Internet Protocol is motivated by the reduction of costs by separation of concerns, in this case: The separation of the network installation from the lighting control installation and commissioning. For Internet based installations the following phases are expected in a fair number of installations:
<list style="hanging">
<t hangText="Electric installation:"> All electric cabling is laid out and connections are validated.</t>
<t hangText="Network installation:"> All network interfaces are connected and validated.</t>
<t hangText="Lighting installation:"> All lighting fixtures are named and other information is loaded into them (commissioning); simultaneously the security bootstrapping of the network is done.</t>
</list>
</t><t>
Dependent on the installation company, the proposed network configuration, and the installation contract, these phases and their order may not be respected and a bootstrap protocol may be used different from the one described in this specification.
</t><t>
For an IEEE 802.15.4 network <xref target="ieee802.15.4"/> the specified three phases imply that after the network installation, non-battery powered devices are connected to their electricity supply, and the IEEE802.15.4 layer-2 mesh and the 6LoWPAN IP layer-3 mesh is configured. Also the preferred IP routing protocol must be working to route messages between IEEE 802.15.4 interfaces based on their IP address. During the Lighting installation, devices are selected according to an installation-dependent protocol, named, and layer 2 security keys are loaded into the devices. When all designated devices have received their security keys, the network is closed such that only authorized nodes can route messages in the network, and data packets can only be exchanged between the layer-2 secured devices. The layer-3 routing protocol MUST continue routing messages before, during and after the Lighting installation procedure.
</t><t>
The selection of the devices is executed by an installation engineer using a Commissioning Tool (CT). According to an installation-dependent protocol a device is selected from the set of not yet selected devices, and its identity is communicated to the CT. The CT exchanges messages with the selected device to distribute the keys (see <xref target="Bootstrap_dtls"/>) and other installation specific data. The order of selection is completely installation and installer dependent, is optimized for low cost, and is not aware of network topology.
</t>
</section>
<section anchor="Requirements" title="Requirements">
<t>
This section lists the requirements for the bootstrap solution.
<list>
<t>Selection of device: The commissioner is able to select an installed device and commission it without the knowledge of the wireless network topology. </t>
<t>Device authenticity: A commissioner should be able to verify that the credentials of the device being bootstrapped match the credentials of the one selected to commission.</t>
<t>Device authorization: A commissioner should be able to decide if a particular authenticated device can indeed be part of the secure network being created. </t>
<t>Commissioning Tool (CT) authenticity and authorization: The device being commissioned can verify if the CT is allowed to bootstrap the device. Alternatively, the device may allow any CT to bootstrap it provided a mechanism exists, either in-band or out-of-band, to reset it and start over again. </t>
<t>Key Confidentiality: The layer-2 key that is used to secure the network should be encrypted such that only the device being commissioned can decrypt the key.</t>
<t>Key Authenticity: The device should be able to verify that the layer-2 key has not been tampered during transport. </t>
</list>
</t>
</section>
<section anchor="Bootstrap" title="Mesh Bootstrap Procedure">
<t>
The flow of the mesh bootstrap procedure involves a joining node (6JN), a Commissioning Tool (CT) and a path over secured routers (6SR) and unsecured routers (6UR). It is assumed that Neighbour discovery has been executed, and a router protocol supports the routing through the mesh. In the beginning all routers (6LR) are unsecured.
</t><t>
A 6JN announces its presence by sending a join request to the CT. The join request is routed over the mesh involving possibly 6UR and 6LR to the CT. The 6JN MAY be identified by its EUI64 identifier <xref target="EUI64"/>. The identifier MAY be transported in the join request.
</t>
<t>
In an alternative approach with its own operational constraints, the CT already has a list of all node identifiers, and uses a different bootstrapping protocol. This approach is not the subject of this specification.
</t>
<t>
The CT on receiving the join request can decide if 6JN is a legitimate device and if it can be part of secure network being commissioned. If positive, then the CT sends the layer-2 key material to the node via a secured channel. The receiving node installs the key material and passes from unsecured to secured node. The secured node sets up secured links with its 6SR using the received key material. When all nodes are secured, the network is secured, and communication (routing) is only allowed via secured channels.
</t>
<section anchor="Bootstrap_arch" title="Network Layout">
<t>
The network to be secured consists of a set of wireless nodes interconnected to a mesh network via IEEE 802.15.4 interfaces. The mesh network may be connected to a border router (6LBR) as described in <xref target="RFC6775"/>. The 6LBR may be connected to a backbone. The CT can be connected to the mesh network to be connected in several ways:
<list>
<t> CT is connected to an IEEE802.11 interface that communicates with the IEEE802.11 Access Point Located in the 6LBR.</t>
<t> CT is connected to the backbone directly or via a path composed of one or more routers.</t>
</list>
</t><t>
It is required that messages can be routed between the CT and each of the candidate devices in the mesh to be secured.
</t><t> In an alternative network, not considered here, the CT is connected with an IEEE 802.15.4 interface to the mesh network. In this case the 6LBR is not required. A mobile CT can then do one-hop commissioning of the devices.
</t>
</section>
<section anchor="discovery" title="Commissioning Tool discovery">
<t>
The discovery of the Commissioning Tool (CT) by the 6LR is outside the scope of this specification. The CT can be discovered in several ways dependent on the infrastructure, for example:
<list style="hanging">
<t hangText="Mesh connected to backbone:"> In this case the CT can announce its presence in DNS using DNS-SD <xref target="RFC6763"/>. The 6JN can query DNS for the address of the nodes supporting the CT service.
</t>
<t hangText="Resource Directory present:"> When a Resource Directory (RD) <xref target="I-D.ietf-core-resource-directory"/> is present, the CT can store the presence of its service in the RD. The 6JN can query the RD for the address of the nodes supporting the CT service.
</t>
<t hangText="Stand alone mesh:"> The 6JN can send a multicast to /.well-known/core querying the existence of the CT service.
</t>
</list>
</t>
</section>
<section anchor="Bootstrap_protocol" title="Bootstrap security layer">
<t>
The purpose of this document is to specify a so-called "bootstrap-layer" between layer-2 and layer-3 to satisfy the use case of <xref target="usecase"/>. In the text the "joining node" (6JN) is the unsecured router (6UR) that is selected to be the next 6LR to be secured.
The following considerations have led to the definitions of the bootstrap layer:
<list>
<t>Messages MUST be routed between CT and the 6JN.</t>
<t>The route between CT and 6JN may pass through the 6LBR.</t>
<t>The route between CT and 6JN may pass through secured routers (6SR) and unsecured routers (6UR).</t>
</list>
The last consideration follows directly from the installation-dependent order of 6JN selection. The last consideration also means that a 6SR has to communicate over secured and unsecured links.
</t><t>
Every 6LR maintains in the bootstrap-layer:
<list>
<t> A list of its neighbours. (This list can be shared with neighbour discovery, or with other protocols).</t>
<t> A Boolean variable, ALL_SECURED, which initially is false.</t>
</list>
These two items constitute the bootstrap state of a 6LR.
</t><t>
The neighbour list of the node contains information whether a link between itself and the neighbour is secured. Dependent on the value of the bootstrap state, packets are refused, encrypted, decrypted, and passed on between layer-2 and layer-3.
</t>
<section anchor="icmp" title="ICMP messages">
<t>
The protocol uses one ICMP message transporting two bootstrap requests:
<list style="hanging">
<t hangText="Join Secure Request (JSR):"> This is an unsecured message that is sent from an 6UR to the CT with the request to be secured. </t>
<t hangText="Set Secure Request (SSR):"> this is a secured message that is sent from a 6SR to signal its secured state to a neighbour 6LR </t>
</list>
The layout of the ICMP messages is:
</t>
<figure anchor="icmp-message" title="ICMP message layout">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>IP fields:
<list style='hanging' hangIndent='15'>
<t hangText="IPv6 source:"> In a JSR this the non link-local address of the sending 6UR; in a SSR this is the link-local address of the sending 6SR.</t>
<t hangText="IPv6 destination:"> In a JSR this is non link-local address of the CT; in a SSR this is the link-local address of a neighbour 6LR.</t>
<t hangText="Hop Limit:"> Set to MULTIHOP_HOPLIMIT on transmit. MUST
be ignored on receipt.</t>
</list></t>
<t>ICMP Fields:
<list style='hanging' hangIndent='15'>
<t hangText="Type:"> TBD for JSR and for SSR</t>
<t hangText="Code:"> Set to one for JSR and set to two for SSR.</t>
<t hangText="Checksum:"> The ICMP checksum. See <xref
target="RFC4443"/>.</t>
<t hangText="Status:"> 8-bit unsigned integer. Indicates the status
of a registration in the CT. MUST be set to 0 in JSR. See <xref
target="status-codes"/>.</t>
<t hangText="Reserved:"> This field is unused. It MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText="Registration Lifetime:"> 16-bit unsigned integer. The
amount of time in a unit of 60 seconds that the 6LR should retain
the secure state in the Neighbor entry for the sender of the SSR.</t>
<t hangText="EUI-64:">64 bits. This field is used to uniquely
identify the interface of the registered address by including the
EUI-64 identifier <xref target="EUI64"/> assigned to it
unmodified.</t>
</list>
</t><t>
The Status values used in JSR and SSR are (to be done/ eventually removed):</t>
<texttable anchor='status-codes'> <!--update status-codes-iana in sync-->
<ttcol align='center'> Status </ttcol>
<ttcol align='center'> Description</ttcol>
<c>0</c> <c>Success</c>
<c>1</c> <c>Duplicate Address</c>
<c>2</c> <c>Impossible</c>
<c>3-255</c> <c>Allocated using Standards Action <xref target="RFC5226"/></c>
</texttable>
</section> <!-- ICMP message -->
<section anchor="protocol" title="Joining a 6LR to the secured mesh">
<t>
</t>
<figure anchor="boot-flow" title="Message flow diagram of bootstrap protocol"><artwork align="left"><![CDATA[
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| CT | | 6LBR | | 6SR | | 6UR | | 6JN | | 6SR |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | (secured) |(unsecured)|(unsecured)|(unsecured)|
| | | | | |
| | | | <--(1)----| |
| | | <---(2)---| JSR | |
| |<---(3)--- | | | |
| <--(4)-- | | | | |
| | | | | |
|=================(5)=========================>| |
| | (many packets DTLS | |
| | | | | |
| | | | <--(6)----| ---(7)--->|
| | | | SSR | SSR |
| | | | | |
| | | | |<---(8)----|
| | | | | SSR |
| | | | | |
| | (secured) |(unsecured)|(unsecured)| (secured) |
| | | | | |
]]></artwork></figure>
<t>
<xref target="boot-flow"/> is a message flow diagram representing the bootstrapping protocol message exchange. The diagram is quite close to the message flow diagram of <xref target="I-D.richardson-6tisch--security-6top"/>. It is assumed that the neighbours have discovered each other at layer-2 with the IEEE802.15.4 beacons. Also it is assumed that all NS, RS, RA, and DAD messages have been exchanged with Neighbour Discovery. Also the routing protocol has started.
</t><t>
Assume, that at some point during the security bootstrap protocol, the 6LBR interface and the two 6SR interfaces have been secured. Before the bootstrap protocol starts the variable ALL_SECURED is set to false in all nodes.
</t><t>
The 6JN sends at (1) a JSR over an unsecured channel containing its EUI64 identifier. At (2) the message is routed on over an unsecure channel, and at (3) it is routed to the 6LBR over a secure channel. At (4) the unsecured request is passed on to the CT. After reception, the CT sets up a secure end-to-end DTLS link with 6JN (described further in <xref target="Bootstrap_dtls" />) and securely transfers the keys over this DTLS session at (5). The secure DTLS packets are routed over secure and unsecure layer-2 channels in the mesh. Once the keys are installed, the 6JN sends a SSR to both neighbours at (6) and (7). At (8) the 6SR neighbour returns a SSR to 6JN. Afterwards the link between 6JN and 6SR is secured.
</t><t>
When all designated 6LR have become 6SR, the CT sends a network close messages to all designated 6SR. On reception, the 6SR nodes set their variable ALL_SECURED to true.
</t>
</section> <!-- joining a 6LR -->
<section anchor="packet" title="Packet handling">
<t>
Dependent on the bootstrap state of the 6LR, the following rules are followed by the bootstrap layer for the communication with a neighbouring 6LR, called N. The packet handling is specified under 3 conditions:
</t><t>
Condition 1: The link with N is signalled secure in the neighbour list:
<list style="symbols">
<t> An unsecured packet arriving from N is refused.</t>
<t> A secured, authenticated packet arriving from N is decrypted and if authentication is verified, passed on to layer 3.</t>
</list>
</t><t>
Condition 2: The link with N is signalled NOT secure in the neighbour list, and ALL_SECURED is false:
<list style="symbols">
<t> When the receiving node is secured, a secured packet arriving from N is decrypted and if authentication is verified, passed on to layer-3. This is needed for the SSR packet at step (8) in <xref target="boot-flow"/>.</t>
<t> When the receiving node is not secured, a secured packet from N is refused. </t>
<t> An unsecured packet from N is passed on to layer-3. </t>
</list>
</t><t>
Condition 3: ALL_SECURED is true:
<list style="symbols">
<t> All unsecured packets are refused. </t>
</list>
</t><t>
Packets coming from layer-3 with destination N are sent according to the rules:
<list style="symbols">
<t> When the link with N is signalled secure in the neighbour list, the packet is encrypted and authenticated.</t>
<t> When the link with N is signalled unsecure in the neighbour list, the packet is sent without encryption or authentication. </t>
</list>
</t>
</section> <!-- Packet handling -->
<section anchor="setsec" title="Securing a channel">
<t>
After termination of the secure key transfer (see <xref target="Bootstrap_dtls"/>, the node fills the ACL table maintained at layer-2 <xref target="ieee802.15.4"/>. The next stage is to determine whether the neighbours are also equipped with the keys. Once the neighbour of a secured node is secured, the link between the two MUST be declared secure in the list of both neighbours. The determination of a secure link is done by exchanging SSR messages, according to the following protocol:
<list>
<t>A node that has set its keys in the ACL table sends a secured SSR message to all its neighbours.
</t>
<t>On reception of a secured SSR from node N, and the link of node N is not secured in the list of neighbours, and the receiving node is secured, the receiving node sends a secured SSR to node N; consecutively, the receiving node sets the link of neighbour N to secured in the list of neighbours.
</t>
<t>On reception of a secured SSR from node N and the receiving node is NOT secured, the receiving node rejects the message.
</t>
</list>
</t>
</section> <!-- securing channel -->
</section> <!-- Bootstrap security layer -->
<section anchor="Bootstrap_dtls" title="Secure key transfer">
<t>
The layer-2 keys are distributed to the devices over a secure DTLS session as indicated in message (5) in <xref target="boot-flow" />. This DTLS session is created using a trust anchor that is deployed in the devices during manufacturing. The trust anchor can be for e.g. one of these listed below:
<list style="symbols">
<t>Pre-shared key: The manufacturer of the device can embed a pre-shared key as a trust anchor during the personalization of the device in the factory. The key along with EUI-64 of the device is then shared with authorized commissioners such that a secure DTLS channel based on <xref target="RFC4279" /> can be established between the CT and 6JN. It is recommended to use the cipher suite TLS_PSK_WITH_AES_128_CCM_8 <xref target="RFC6655" /> which is the mandatory to implement cipher suite for use with shared secret based DTLS in Constrained Application Protocol (CoAP) <xref target="RFC7252" />. </t>
<t>Raw public key: The manufacturer of the device can embed a {pubic-key, private-key} pair of an asymmetric cryptographic algorithm as a trust anchor during the personalization of the device in the factory. The public-key (or a hash of the public-key) is available out-of-band (for e.g. printed on the device) to the commissioner to enable authentication and authorization of the selected device over a secure DTLS channel based on <xref target="RFC7250" />. It is recommended to use the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251" /> which is the recommended cipher suite for raw-public key based DTLS in CoAP. </t>
<t>Certificates: The manufacturer of the device can embed a {public-key, private-key} pair along with a certificate (signed by the manufacturer or a trusted third party) linking the public-key to an identity in the device. This could be for example an IEEE 802.1AR certificate <xref target="IDevID" /> which links the public-key to the EUI-64 of the device. The DTLS session is then established between the CT and JN based on the trust in the certificate. It is recommended to use the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 which is recommended for certificate based DTLS in CoAP.</t>
</list>
</t>
<t>
It is important to note that only the pre-shared key option above provides mutual authentication of the DTLS channel. For raw public key and certificate option, an additional root public key needs to be provisioned in the device for authenticating the CT with a mutually authenticated DTLS handshake.
</t>
</section> <!-- secure key transfer -->
</section> <!-- Mesh bootstrap procedure -->
<section anchor="key-setting" title="Setting layer-2 key values">
<t>
Once the DTLS session is established (using any of the trust anchors mentioned above), the layer-2 keys can be transported within the secure session. The setting of the values in the device can be achieved using a CoAP request on a well-defined CoAP resource which is used for configuring the MAC layer keys, in analogy to the multicast address setting in <xref target="RFC7390"/>.
</t><t>
Another solution is using a YANG file that specifies configurable key entries, the values of which can be set with for example CoMI <xref target="I-D.vanderstok-core-comi"/>.
</t><t>
CoAP endpoints implementing the layer-2 key setting RESTful
interface MUST support the CoAP Internet Media
Type "application/coap-group+json".
</t><t>
A resource offering this representation can be annotated for direct
discovery <xref target="RFC6690"/> using the Resource Type (rt=) Link Target
Attribute "core.ky", where "ky" is shorthand for "layer-2 key values". An authorized client uses this media type to query/
manage layer-2 key values of a CoAP endpoint as defined in the
following subsections.
</t>
<t>
TODO: specify payload format and resource name "/coap-key2"
</t>
</section> <!-- setting key values -->
<section anchor="iana" title="IANA Considerations">
<t>
The document registers one new ICMPv6 "type" number under the
subregistry "ICMPv6 "type" Numbers":
<list style="symbols">
<t>Bootstrap Request (xxx) </t>
</list>
</t>
</section>
<section anchor="sec" title="Security Considerations">
<t><list style="symbols">
<t> During the commissioning period, rogue nodes can use the network and send requests to 6LR and thus compromise the nodes. It is recommended that during the period from network start up till the end of the secure bootstrapping, no resources can be accessed in the 6LR. Consequently, the nodes can only exchange ICMP messages. In this case the routing tables and the neighbour tables of the 6LR can be corrupted. Such corruption will be detrimental to the bootstrap process and can be detected, after which the installer SHOULD take measures to remove the rogue nodes.
</t>
<t>
After all nodes in the network have been commissioned, the network needs to be finally secured by setting ALL_SECURED to true for all nodes. This final message needs to be securely sent by the CT either in unicast or multicast to all the nodes in the network. If additional nodes need to be added to the network at a later point in time, a new secure message needs to be sent by the CT with ALL_SECURED set to false. This message can either be sent to the whole network or (if known) only to the neighbours of the joining node. Both messages that change the ALL_SECURED state should be authenticated by the CT and not re-playable.
</t>
<t>
The large number of messages exchanged between the joining node and CT can be misused by a rogue node to create a Denial-of-Service (DoS) at nodes closer to the 6LBR, 6LBR itself or at the CT. This can be limited by ensuring that the DTLS handshake is only performed by the CT with a node that the commissioner has presently chosen to bootstrap. Thus the rogue messages are only limited to ICMP "Bootstrap Request" messages.
</t>
</list></t>
</section>
<section anchor="ack" title="Acknowledgements">
<t> The authors would like to thank Peter Lenoir and Dee Denteneer for the valuable discussions that helped in shaping the solution.
</t>
</section>
<section anchor="changes" title="Change log">
<t>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2460;
&RFC4443;
&RFC4861;
&RFC4862;
&RFC4919;
&RFC4944;
&RFC5226;
&RFC5889;
&RFC6775;
&RFC6347;
</references>
<references title="Informative References">
&RFC6763;
&RFC5191;
&RFC6345;
&RFC5216;
&RFC4279;
&RFC6655;
&RFC6690;
&RFC7252;
&RFC7250;
&RFC7251;
&RFC7390;
&I-D.kumar-dice-dtls-relay;
&I-D.jennings-core-transitive-trust-enrollment;
&I-D.ietf-core-resource-directory;
&I-D.richardson-6tisch--security-6top;
&I-D.pritikin-anima-bootstrapping-keyinfra;
&I-D.struik-6tisch-security-considerations;
&I-D.ohba-6tisch-security;
&I-D.he-iot-security-bootstrapping;
&I-D.vanderstok-core-comi;
&AES;
<reference anchor="CCM">
<front>
<title>SP 800-38C Recommendation for Block Cipher Modes of Operation:
The CCM Mode for Authentication and Confidentiality</title>
<author surname="National Institute of Standards and Technology">
<organization></organization>
</author>
<date month="May" year="2004" />
</front>
</reference>
<reference anchor="DALI">
<front>
<title>Digital Addressable Lighting Interface, IEC 62386</title>
<author surname="IEC">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
</reference>
<reference anchor="ieee802.15.4">
<front>
<title>IEEE Standard 802.15.4-2006</title>
<author surname="Institute of Electrical and Electronics Engineers">
<organization></organization>
</author>
<date month="" year="2006" />
</front>
</reference>
<reference anchor="ZigbeeIP">
<front>
<title>"ZigBee IP Specification"</title>
<author surname="ZigBee Alliance">
<organization></organization>
</author>
<date month="" year="" />
</front>
</reference>
<reference anchor="EUI64" target="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html">
<front>
<title>Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority</title>
<author>
<organization>IEEE
</organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="IDevID"
target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE 802.1AR Secure Device Identifier</title>
<author surname="IEEE Standard"></author>
<date month="December" year="2009" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 01:06:19 |