| Network Working Group | M. Richardson |
| Internet-Draft | SSW |
| Intended status: Informational | November 20, 2015 |
| Expires: May 23, 2016 |
6tisch secure join using 6top
draft-richardson-6tisch--security-6top-05
This document details a security architecture that permits a new 6tisch compliant node to join an 802.15.4e network. The process bootstraps the new node authenticating the node to the network, and the network to the node, and configuring the new node with the required 6tisch schedule. Any resemblance to WirelessHART/IEC62591 is entirely intentional.
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 RFC 2119 [RFC2119].
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 May 23, 2016.
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.
A challenging part with constructing an LLN with nodes from multiple vendors is providing enough security context to each node such that the network communication can form and remain secure. Most LLNs are small and have no operator interfaces at all, and even if they have debug interfaces (such as JTAG) with personnel trained to use that, doing any kind of interaction involving electrical connections in a dirty environment such as a factory or refinery is hopeless.
It is necessary to have a way to introduce new nodes into a 6tisch network that does not involve any direct manipulation of the nodes themselves. This act has been called "zero-touch" provisioning, and it does not occur by chance, but requires coordination between the manufacturer of the node, the service operator running the LLN, and the installers actually taking the devices out of the shipping boxes.
For the process described in this document to work, some assumptions about available infrastructure are made. These are perhaps more than assumptions, but rather architectural requirements; the exact operation of said infrastructure to be defined in a subsequent document.
In the diagrams and text that follows entities are named (and defined in the terminology section). Unless otherwise stated these are roles, not actual machines/systems. The roles are seperated by network protocols in order that they roles can be performed by different systems, not because they have to be. Different deployments will have different scaling requirements for those entities. Smaller deployments might co-located many roles together into a single ruggedized platform, while other deployments might operate all of the roles on distinct, multiply-redundant server classes located in a fully equipped datacentre.
Most terminology should be taken from [I-D.ietf-6tisch-architecture] and from [I-D.ietf-6tisch-6top-interface] and [I-D.wang-6tisch-6top-sublayer]. As well, many terms are taken from [RFC6775].
The following roles/things are defined:
The following terms are used in this document and come from other documents:
The following actors are involved: there is a new joining node. It is (radio) adjacent to the join assistant. The join assistant is part of the production network, and participates in one or more DODAGs, such that it is reachable from the 6LBR, and the JCE.
This section works from the ultimate goal, and goes backwards to prerequisite actions. (Section 6 presents the protocol from beginning to end order)
The ultimate goal of the join protocol is to provide a new node with a locally significant security credentials so that it is able to take part in the network directly. The credentials may vary by deployment. They can be one of:
One of these two items is delivered by JCE to the joining node using the 6top protocol. That is, the JCE provisions using a secure "northbound" interface. The authentication of this interface the subject of the Join Protocol as explained below.
The above credential are used for authentication to generate per-peer L2, using a key exchange protocol. The choice of key exchange protocol, and what kind of link and multicast keying needs to be done is also provisioned by the JCE. There are a number of options for doing this, such as:
Per-peer L2 keying is critical when doing peer-2-peer schedule negotiation over 15.4 Information Elements. Therefore a network-wide layer-2 key is inappropriate for the self-organizing networks, and a protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.
For networks where there is a PCE present, it will do all schedule computation. As a result the only trust relationship necessary is between the individual node and the PCE, and it MAY be acceptable to have a network-wide L2 key derived in ways such as [I-D.piro-6tisch-security-issues] describes in section ?. The trust relationship between the PCE and the joining node flows from the LDevID certificate loaded by the JCE. When the PCE and JCE are co-located, the existing 6top/DTLS security association could be reused.
The intermediate level goal of the join protocol is to enable a Join Coordination Entity (JCE) to reach out to the new node, and install the credentials detailed above. The JCE must authenticate itself to the joining node so that the joining node will know that it has joined the correct network, and the joining node must authenticate itself to the JCE so that the JCE will know that this node belongs in the network. This two way authentication occurs in the 6top/CoAP/DTLS session that is established between the JCE and the joining node.
[I-D.ietf-6tisch-6top-interface] presents a way to interface to a 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] explains how to access that information model using CoAP. This information model will include security attributes for the network. The JCE would therefore reach out to the joining node and simply provision appropriate security properties into the joining node, much like the PCE will provision schedules.
This 6top-based secure join protocol has defined a push model for security provisioning by the JCE. This has been done for three reasons:
In order for a 6top/DTLS/CoAP connection to occur between the JCE and the joining node, there needs to be end-to-end IPv6 connectivity between those two entities. The joining node will not participate in the route-over RPL mesh, but rather will be seen by the network as being a 6lowpan only leaf-node.
The joining node sends traffic to the join assistant, which forwards it using the normal RPL DODAG upwards routes, and which will reach the JCE using regular routing.
The challenge is getting connectivity from the JCE to the joining node, as the DODAG and 6LBR root will have no information about this node. Instead, the JCE will use loose-source routes (in the RH2) to address packets first to the Join Assistant, which will then forward to the joining node. This has an interaction with the (strict) source routes used by non-storing DODAGs which would be used by the 6LBR to reach the Join Assistant.
There are some alternatives to having full end to end connectivity which are discussed in the security considerations section.
This goes into security-considerations section
A number of alternatives were considered for creating end to end connectivity between the joining node and the JCE, but were rejected.
This mechanism requires 40 bytes overhead per packet, and may require specific state to be created on the Join Assistant, or may open the network up to a resource exhaustion by malicious join nodes.
This mechanism was rejected on due to byte count, because it would require code only needed for join, and because doing it securely may require a per-tunnel state to be maintained on the join assistant.
This mechanism is to just have the new node join the DODAG as a leaf node. The join assistant would issue a DAO for the new node. If a storing DODAG was used, this would directly cost state in all parent nodes of the Join Assistant, subjecting the lower-rank parts of the network to significant denial of service attacks.
On a non-storing DODAG the situation is significantly better: no state is created by the presence of the leaf node except in the 6LBR, where available resources may be higher.
This mechanism was rejected in favour of the loose source routed option as this the loose source routed option always works even for storing DODAGs, and is otherwise exactly equivalent in terms of network bandwidth cost.
One option to deal with the problem of resource consumption in the storing DODAG case is to use a second DODAG.
This mechanism was rejected as it consumes resources in all nodes for the second DODAG, and many implementations support on a single DODAG. While storing DODAGs have a lighter network impact than non-storing ones (due to the lack of source routes), the PCE can control how much network bandwidth can be wasted by malicious join nodes using the regular 6tisch mechanisms, and this can be tuned. A second DODAG would be a sunk cost with no tuning possible.
This mechanism would use 6tisch tracks so that traffic from the JCE would be switched from 6LBR to join node. A track would be required to each join assistant. This is an optimized form of source routing.
This mechanism was not rejected, rather it was observed that it may be applied to any mechanism that uses source routing, and is an optimization; it has a certain cost in the form of intermediary node state, but that this state is not created by a malicious join node, rather it is created by the PCE.
Continuing to work backwards, in order the JCE reach out to provision the Joining Node, it needs to know that the new node is present. This is done by taking advantage of the 6lowPAN Address Resolution Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address to also be sent up to the 6LBR for duplicate detection using the DAR/DAC mechanism. The 6LBR simply needs to tell the JCE about this. A new protocol may be required for the situation where the JCE, PCE and 6LBR are not co-located; it may be that this protocol could be simply a DAR in some encapsulation. The details of this are currently out of scope for the architecture, as they affect interoperability between different vendors of JCE/6LBR/PCE rather than interoperability between the assistance/offload infrastructure, and the contrained nodes. Future work may specify this part.
In addition to needing to know the joining devices address from the DAR/NS, the JCE also needs to know the joining node's IDevID. This is to determine if the node should even get any attention. At this point, the IDevID can be forged, it will be authenticated during the setup of the 6top control protocol in the DTLS certificate exchange. If the serialNumber attribute of the IDevID is less than 64 bits, then it is possible that it could be placed into the EUI-64 option of the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] EARO. The JCE needs to know the joining node's serialNumber to know if this is device that it should even attempt to provision; and if so, it may need to retrieve an appropriate certificate chain (see [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for the JCE to prove it is the legitimate owner of the joining node.
Neither 802.1AR nor [RFC5280] provide any structure for the serialNumber, except that they are positive integers of up-to 20 octets in size (numbers up to 2^160). This specification would require that the serialNumber encoded in the IDevID be the same as the EUI-64 used by the device. Some consideration needs to be given as to whether there are privacy considerations to doing this: any observer that can see the join traffic, can also see the source MAC address of the node as well.
Prior to being able to announce itself in a NS, the joining node needs to find the Join Network. This is done by listening to the extended beacon which are broadcast in designated slotframes by the network. These are the same extended beacons which are used by the production network. The extended beacons are transmitted in "MIC-only" (authentication only) mode. Nodes with the production network key can authenticate the beacons. The newly joining node can not authenticate the beacons, but it can read and process them, and can use this as a way to synchronize to the network. During the Alpha period, the joining node can send a Router Soliticiation, and receive an appropriate Router Advertisement giving the Joining Node a prefix and default route to which to send the join traffic (the ND DAD mentioned above).
It may be possible to eliminate a message exchange if space for a Router Advertisement can be found as part of the Join Network Extended Beacon. This Enhanced Beacon would be distinct to the Join Network, and would be encrypted with the well-known Join Network key.
What prefix would the joining node for communication? There are three options:
It would be ideal to use link-local addresses, but they need to be scoped to the radio interface of the join assistant which can actually reach the joining node. It may be that this can be made to work, but otherwise, the join assistant will have a ULA for each radio on which it expects join traffic.
There are three kinds of threats that a join process must deal with: threats to the joining node, threats to the resources of the network, and threats to other joining nodes.
A node may be taken out of it's box by a malicious entity and powered on. This could happen during shipping, while being stored in a warehouse. The device may be subject to physical theft, or the goal of the attacker may be to turn the device into a trojan horse of some kind. Physical protection of the device is out of scope for this document; this document will henceforth assume that the device is sealed in some tamper-evident way and this document deals with attacks over the network.
An attacker may attempt to convince the joining node that it is the legitimate Production Network; this is done by putting up a legitimate looking Join Network, and following the protocol as described in this document. The Joining Node can not know if it has the corrrect Production Network until steps 11-13, when it attempts to validate the ClientCertificate provided by the JCE.
When the joining node determines that this is the incorrect network, it must remember the PANID of the network that it has attempted to join, and then look for another network to try. It SHOULD have some limit as the number of times it will try before going back to sleep, or shutting down, and it SHOULD take care not to consume more than some specified percentage of any battery it might have.
Should a malicious production network be present at the same time/place as the legitimate production network, a the malicious agent could intercept and replay various packets from the proper join network, but ultimately this either results in a jamming-like denial of service, and/or the the ClientCertificate will not validate.
It is a legitimate situation for there to be multiple possible join networks, and the joining node may have to try each one before it finds the network that it the right one for it. The incorrect, but non-malicious networks will not attempt the 6top provisioning step, and SHOULD return a negative result in steps 8/9, refusing the node's NS. Those incorrect networks will be recognize that the node does not belong to them, because they will be able to see the Joining Node's IDevID in the ARO of step 4.
The production network has two important resources that may be attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory for routing entries.
A malicious joining node could send many NS messages to the Join Assistant (from many made up addresses), which would send many NS/DAR messages to the 6LBR, and this would consume bandwidth, and therefore energy from the members of the mesh along the path to the 6LBR. This can be mitigated by limited the total bandwidth available for joining.
A malicious joining node could send many NS messages, and if the 6LBR agreed to accept the new node (by IDevID), then the Join Assistant would MAY inject routing information into mesh for the Joining node. Non-storing DODAGs store are routing information in the DODAG Root (probably the 6LBR), which is generally not a constrained node. Storing DODAGs store routing entries at all nodes up to the DODAG, and those are constrained nodes. Using a separate Join DODAG, and having that DODAG be non-storing will reduce any impact on intermediate nodes, but it does cause resources to be used for the second DODAG, and it may have a code impact if the nodes otherwise would not implement non-storing RPL.
A joining node (or the nodes of a malicious network, co-located near the legitimate production network) may mount attacks on legitimate nodes which have not yet joined.
The malicious nodes may attempt to perform 6top operations against the joining node to keep it from being able to respond to the legitimate 6top session from the legitimate JCE. During the Join phase, the Joining node MUST have all other resources and protocols turned off, even if they would normally be accessible as read-only unauthenticated CoAP resources.
Malicious nodes could use the Join Network to mount various DTLS based attacks against the joining node, such as sending very long certificate chains to validate. One might think to limit the length of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert] the chain may as a long as the supplier chain, plus may include additional certificates due to resales of plants/equipment/etc. Validating from a trusted certificate down to the specific certificate which proves ownership would eliminate random certificate chains, but the attacker could just feed the joining node legitimate chains that it observed (and replayed) from the legitimate JCE. This does no good; the Joining node finds that the DTLS connection is invalid, but it may significantly run batteries down.
(storage of security material, computational cost)
other communication impacts of security protocol mechanics
dependencies on centralized or external functionality, inline and offline
+-----+ +------+ +----------+ +-----------+
| | | | | JOIN | | Joining |
| JCE | | 6LBR | | Assistant| | Node |
+-----+ +------+ | (proxy) | | |
| | +----------+ +-----------+
| | | |
| | |-------BEACON (1)---------->|
| | | |
| | |<----Router Solicitation----|
| | |---Router Advertisement---->|
| | | |
| | |<------CERT CACHE-----------|
| | | LOAD (2) |
| | | |
| | | |
| | |-------CERT CACHE---------->|
| | | RESPONSE (multiple) |
| | | (packets) |
| | | |
| | |<-----JOIN REQUEST (4) -----|
| | | (NS w/ARO ) |
| | | |
| |<---NS (DAR) (5)-----| |
|<--??(6)-| | |
| | | |
|--??(7)->| | |
| | | |
| |----NS (DAC)-(8)---->| |
| | +------+ | |
| |<DAO-| mesh |<--DAO--| |
| |-DAO-| node |--DACK->| |
| | ACK +------+ | |
| | |-------JOIN ACK (9)-------->|
| | | |
| | | |
|================(10)==========>|----------6top----(11)----->|
| | | DTLS |
|<===============(13)===========|<---------CoAP----(12)------|
| | | (many packets) |
Figure 1: Message sequence for JOIN message
A 6tisch join/synchronization beacon is broadcast periodically, and is authenticated with a symmetric “beacon key”:
The purpose of this key is not to provide a high level of assurance, but rather to filter out 6tisch traffic from another random traffic that may be sharing the same radio frequencies.
These beacons are used for JOIN purpose only, and are not related to the Enhanced Beacons used in the rest of 6tisch.
The joining node sends a router solicitation during the Aloha period of the beacon.
The joining node receives a router advertisement from the Join Assistant. It could include 6CO options to help compress packets, and should contain a prefix appropriate for join traffic.
At step 10, the JCE will need to present a certificate chain anchored at a trusted CA built into the joining node. It has been speculated that a significant amount of traffic could be avoided at step (10) if the common parts of the certificate chains could be cached in the join assistant.
This optional step involves the joining node asking for certificates from the join assistant.
the proxy neighbour sends requested cached certificates to the joining node
A regular Neighbour Solicitation is sent. This should contain an ARO (or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO will be proxied by the Join Assistant as part of normal 6LowPAN processing for leaf nodes (non-RPL nodes) upwards to the 6LBR
The JCE could reply in the negative, and this would cause a DAC failure, TBD
The double lines indicate that an IPIP tunnel operation may be required. If a straight DAO or seperate Join DODAG is used, then this is just a straight forwarding root to leaf node forwarding operation, and involves either using source routes (non-storing), or just forwarding for storing DODAGs.
A specific bandwidth allocation would be used for this join traffic
The production network encryption keys would be used for the join traffic
The JOIN Assistant would forward traffic to the Joining Node. Recognizing that this traffic the JOIN Network, the JOIN Assistant would use the JOIN Network key.
The joining node replies, using JOIN Network key.
The JOIN Assistant, recognizing that the traffic came from the JOIN Network, restricts the destination that can be reached to the the JCE only. It can do this in a stateless way, and it does NOT need to track the traffic at (10) to open pinhole, etc.
Recognizing that the traffic came from the JOIN Network, the traffic would be placed into a bandwidth allocation (track?) that allows such traffic.
and number of frames needed to contain it.
An end to end IPv6 CoAP/DTLS connection is created between the JCE and the Joining Node. This connection carries 6top commands to update security parameters. This results in either deployment of a single-level, locally relevant certificate (LDevID), or deployment of a network-wide symmetric "Master Key"
The JCE authenticates the joining node using a certificate chain provided inline during the DTLS negotiation. The certificate chain is rooted in a vendor certificate that the JCE must have preloaded, and is a statement as to the node's 802.1AR IDevID. The joining node authenticates the
Note: RPL Root authentication is a chartered item
The EUI-64 of the Joining node is transmitted using a Well Known layer-2 encryption key. Within the ARO/EARO of the Neighbour Solicitation is an OUI, which may be identical to the EUI-64 of the Joining node, or it might be an unrelated IDevID.
An eavesdropper can therefore learn something about the manufacturer of every device as it joins.
how is this communicated in the (extended) beacon.
(allocation of slotframes after join, network statistics, neighboetc.)
lifecycle (key management, trust management)
what prevents a node from transmitting when it is not their turn (part one: jamming)
can a node successfully communicate with a peer at a time when not supposed to, may be tied to link layer security, or will it be policed by receiver?
security architecture and fit of e.g. join protocol and provisioning into this
(SACM related work)
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6550] | Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012. |
| [RFC6775] | Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012. |
| [IEEE.802.1AR] | Institute of Electrical and Electronics Engineers, "Secure Device Identity", IEEE 802.1AR, 2009. |
| [I-D.ietf-6tisch-coap] | Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", Internet-Draft draft-ietf-6tisch-coap-03, March 2015. |
| [I-D.ietf-6tisch-6top-interface] | Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer (6top) Interface", Internet-Draft draft-ietf-6tisch-6top-interface-04, July 2015. |
| [I-D.ietf-6tisch-architecture] | Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Internet-Draft draft-ietf-6tisch-architecture-08, May 2015. |
| [I-D.irtf-nmrg-autonomic-network-definitions] | Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S. and L. Ciavaglia, "Autonomic Networking - Definitions and Design Goals", Internet-Draft draft-irtf-nmrg-autonomic-network-definitions-07, March 2015. |
| [I-D.seitz-ace-problem-description] | Seitz, L. and G. Selander, "Problem Description for Authorization in Constrained Environments", Internet-Draft draft-seitz-ace-problem-description-03, March 2015. |
| [I-D.richardson-6tisch-idevid-cert] | Richardson, M., "X509.v3 certificate extension for authorization of device ownership", Internet-Draft draft-richardson-6tisch-idevid-cert-01, March 2015. |
| [I-D.wang-6tisch-6top-sublayer] | Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer (6top)", Internet-Draft draft-wang-6tisch-6top-sublayer-04, November 2015. |
| [I-D.thubert-6lo-rfc6775-update-reqs] | Thubert, P. and P. Stok, "Requirements for an update to 6LoWPAN ND", Internet-Draft draft-thubert-6lo-rfc6775-update-reqs-06, January 2015. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008. |
| [RFC7252] | Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014. |
| [RFC6347] | Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012. |
| [I-D.thubert-6lowpan-backbone-router] | Thubert, P., "6LoWPAN Backbone Router", Internet-Draft draft-thubert-6lowpan-backbone-router-03, February 2013. |
| [I-D.ietf-netconf-zerotouch] | Watsen, K., Clarke, J. and M. Abrahamsson, "Zero Touch Provisioning for NETCONF Call Home", Internet-Draft draft-ietf-netconf-zerotouch-04, October 2015. |
| [I-D.kelsey-intarea-mesh-link-establishment] | Kelsey, R., "Mesh Link Establishment", Internet-Draft draft-kelsey-intarea-mesh-link-establishment-06, May 2014. |
| [I-D.ohba-6tisch-security] | Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P. and A. Yegin, "Security Framework and Key Management Protocol Requirements for 6TiSCH", Internet-Draft draft-ohba-6tisch-security-01, March 2014. |
| [I-D.piro-6tisch-security-issues] | Piro, G., Boggia, G. and L. Grieco, "Layer-2 security aspects for the IEEE 802.15.4e MAC", Internet-Draft draft-piro-6tisch-security-issues-03, December 2014. |