| 6lo | S. Kumar |
| Internet-Draft | Philips Research |
| Intended status: Standards Track | P. van der Stok |
| Expires: September 5, 2015 | Consultant |
| March 4, 2015 |
Security Bootstrapping over IEEE 802.15.4 in selective order
draft-kumar-6lo-selective-bootstrap-00
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.
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-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 September 5, 2015.
Copyright (c) 2015 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.
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944] on IEEE 802.15.4 [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.
The security of IEEE 802.15.4 MAC frames is based on Advanced Encryption Standard (AES) [FIPS.197.2001] in Counter with CBC-MAC Mode (CCM) [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 Table 1.
| Security Level | Confidentiality | Message Integrity Code (MIC) |
|---|---|---|
| 0 | None | None |
| 1 | None | Yes (4 byte MIC) |
| 2 | None | Yes (8 byte MIC) |
| 3 | None | Yes (16 byte MIC) |
| 4 | Yes | None |
| 5 | Yes | Yes (4 byte MIC) |
| 6 | Yes | Yes (8 byte MIC) |
| 7 | Yes | Yes (16 byte MIC) |
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.
Some industry standards have tried to solve the issue by using a mix of other protocols with extensions. For example, Zigbee-IP [ZigbeeIP] uses Protocol for carrying Authentication for Network Access (PANA) [RFC5191] with the additional PANA-Relay [RFC6345] to carry EAP-TLS [RFC5216] packets to the joining node as shown in Figure 1.
+-----------------+
| EAP Peer | +-------------+
+-----------------+ |PANA Relay |
|PANA Client (PaC)|<-->|Element (PRE)|
+-----------------+ +------^------+
Joining Node |
|
|
+-------v-----------+ +-----------+
|EAP Authenticator | |EAP Server |
+-------------------+<-------->+-----------+
|PANA Authentication| |AAA Server |
|Agent (PAA) | +-----------+
+-------------------+
Figure 1: EAP over PANA for bootstrapping
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 [I-D.kumar-dice-dtls-relay] as depicted in Figure 2 is an alternative simpler proposal based on trust enrolment [I-D.jennings-core-transitive-trust-enrollment] that provides the same results by reusing the security protocols (like DTLS [RFC6347]) that already exist on IoT devices.
+--------+ +-------+ +-------+ | DTLS | | DTLS | | DTLS | | Client |<------>| Relay |<-------->|Server | +--------+ +-------+ +-------+ Joining AAA Node Server
Figure 2: DTLS Relay for bootstrapping
Numerous other recent proposals like [I-D.pritikin-anima-bootstrapping-keyinfra], [I-D.richardson-6tisch--security-6top], [I-D.struik-6tisch-security-considerations], [I-D.ohba-6tisch-security], [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.
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.
In this specification, the bootstrapping order of the nodes can be selected by a commissioner.
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 [RFC2119].
Readers are expected to be familiar with all the terms and concepts that are discussed in "neighbour Discovery for IP version 6" [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], "neighbour Discovery Optimization for Low-power and Lossy Networks" [RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944].
This specification uses the following terms from [RFC6775]:
This specification uses the following new terms:
In lighting controls a major shift is on its way from lighting specific networking standards like [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.
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:
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.
For an IEEE 802.15.4 network [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.
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 Section 5.4) 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.
This section lists the requirements for the bootstrap solution.
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.
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 [EUI64]. The identifier MAY be transported in the join request.
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.
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.
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 [RFC6775]. The 6LBR may be connected to a backbone. The CT can be connected to the mesh network to be connected in several ways:
It is required that messages can be routed between the CT and each of the candidate devices in the mesh to be secured.
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.
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:
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 Section 3. 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:
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.
Every 6LR maintains in the bootstrap-layer:
These two items constitute the bootstrap state of a 6LR.
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.
The protocol uses one ICMP message transporting two bootstrap requests:
The layout of the ICMP messages is:
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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICMP message layout
IP fields:
ICMP Fields:
The Status values used in JSR and SSR are (to be done/ eventually removed):
| Status | Description |
|---|---|
| 0 | Success |
| 1 | Duplicate Address |
| 2 | Impossible |
| 3-255 | Allocated using Standards Action [RFC5226] |
+------+ +------+ +------+ +------+ +------+ +------+ | | | | | | | | | | | | | 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) | | | | | | |
Figure 4: Message flow diagram of bootstrap protocol
Figure 4 is a message flow diagram representing the bootstrapping protocol message exchange. The diagram is quite close to the message flow diagram of [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.
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.
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 Section 5.4) 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.
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.
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:
Condition 1: The link with N is signalled secure in the neighbour list:
Condition 2: The link with N is signalled NOT secure in the neighbour list, and ALL_SECURED is false:
Condition 3: ALL_SECURED is true:
Packets coming from layer-3 with destination N are sent according to the rules:
After termination of the secure key transfer (see Section 5.4, the node fills the ACL table maintained at layer-2 [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:
The layer-2 keys are distributed to the devices over a secure DTLS session as indicated in message (5) in Figure 4. 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:
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.
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 [RFC7390].
Another solution is using a YANG file that specifies configurable key entries, the values of which can be set with for example CoMI [I-D.vanderstok-core-comi].
CoAP endpoints implementing the layer-2 key setting RESTful interface MUST support the CoAP Internet Media Type "application/coap-group+json".
A resource offering this representation can be annotated for direct discovery [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.
TODO: specify payload format and resource name "/coap-key2"
The document registers one new ICMPv6 "type" number under the subregistry "ICMPv6 "type" Numbers":
The authors would like to thank Peter Lenoir and Dee Denteneer for the valuable discussions that helped in shaping the solution.