| Network Working Group | M. Richardson |
| Internet-Draft | SSW |
| Intended status: Informational | April 28, 2014 |
| Expires: October 30, 2014 |
security architecture for 6top: requirements and structure
draft-richardson-6tisch-security-architecture-02
This document details security requirements for 6tisch nodes that use 6top in an industrial settings. Layer-2 and a layer-4 authentication and authorization requirements and assumptions are identified. Two approaches to accomplishing these requirements are outlined, with the goal of eventually picking one. This internet-draft is intended for later inclusion into the 6tisch architecture document.
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 October 30, 2014.
Copyright (c) 2014 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.
There are five security problems that must be solved in the 6tisch environment in order to permit the nodes to come together and function as a network. They are:
This document, presently a stand-alone document, but later to be a section of [I-D.ietf-6tisch-architecture], explains the assumptions of how the node is expected to be provisioned in the factory, and how it will react to networks that it encounters. As is explained in every Internet of Things document, the nodes are constrainted, have no end-user interfaces, and therefore it is desired that they function in a "zero-touch" manner. [I-D.irtf-nmrg-autonomic-network-definitions] introduces the term "autonomic", and it is exactly the properties described there that are desired for 6tisch networks.
A 802.1AR [IEEE.802.1AR] certificate provisioned in each node at the factory, combined with a certificate chain provided to the network service provider, permits the node to be recognized by the network, and also for the network to assert it's authority to own and control the node. The authentication part of a security protocol (TLS, DTLS, EAP-TLS, details TBD) will establish identities, and then, said security protocol will be used to provide integrity protection for a control protocol (YANG/6top, as discussed in [I-D.wang-6tisch-6top-sublayer]) to configure the TSCH cells.
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 RFC 2119 [RFC2119].
As outlined in [I-D.ietf-roll-security-threats] there are a number of threats in LLNs, and in RPL which are solved if there is layer-2 security. The requirement is therefore to provide keying for the layer-2 security features: encryption and integrity protection.
In addition to serving to protect the routing traffic against attacks, use of the layer-2 access control serves as adminission control to the network. It is therefore part of the layer-2 join process to authenticate the new node, as well as authorize it to join the network. The admission control SHOULD be controlled by autonomic certificates, as described below.
[I-D.pritikin-bootstrapping-keyinfrastructures] explains the architecture for use of 802.1AR certificates in a bootstrap process. In that document a number of terms of introduced, and in this section those terms are mapped to 6tisch entities and processes. Section 2 of [I-D.pritikin-bootstrapping-keyinfrastructures] defines:
This section explains how the process detailed in [I-D.pritikin-bootstrapping-keyinfrastructures] is to be implemented in the 6tisch case. To recap, the process looks like:
The Proxy Discovery step may occur via one of two mechanisms, which are further described in section Section 3. One method involves using an EAP-TLS (or rather, EAP-EST, as imagined by [I-D.pritikin-bootstrapping-keyinfrastructures]), over either 1X or PANA. A nearby node provides a PANA Authentication Agent (PAA) ([RFC5191]), or 802.1X Authenticator. A well-known L2-JOIN key is used during bootstrap. A second method involves using leveraging the ARO ND messages that 6LOWPAN mandates be exchanged.
In either case, a (D)TLS channel is created from the New Entity/6LN to the Registrar/Authorization Server
In forming the TLS channel, two certificate chains are validated. The Registrar validates a certificate (possibly chain) presented by the New Entity. This certificate chain would be communicated using the TLS Client Certificate message. The Registrar sends a certificate chain in the TLS Server Certificate message which the New Entity must be able to validate.
As the Registar will in general perform enrollment for all 6LN on a network, it will have multiple identities, and should send only the certificate chain relevant to each New Entity.
The New Entity must also send some TBD extension to the server to indicate who it is. This has to be done before the server sends it's Server Certificate message. This is a variation of the problem the TLS 1.2 SNI extension was designed to solve.
The certificate chain that the Registrar returns may not exist until the New Entity attempts to join. It may be retrieved/created through a number of different mechanisms which are out of scope of this document, but may include:
An important aspect to note is that it may be some minutes to days between the time the New Entity initiates the join operation, and when the Registrar is able to respond properly: some kind of error code and back-off process may be appropriate.
The two certificate chains described in the previous section are critical for permitting the zero-touch operation of the 6LN New Entity. This section describes the contents of the Server Certificate that the 6LN expects to verify. For the purposes of this explanation, assume the 6LN has a deviceID of 3145191, and is manufactured by Example Corp, that it was distributed by Example Logistics, and it is being installed at ACME Widgets.
The certificate chain will be rooted with the 6LN's manufacturer certificate: Example Corp.
This chain permits the 6LN to verify that ACME Widgets is in fact it's rightful owner. The certificate chain MAY have a validity permit, or MAY be valid indefinitely. Given that it is unlikely that the 6LN will have a reliable real-time clock, or access to a secure network time source, validation of validity permits may be useless.
The certificate chain that the New Entity presents to the Registrar would look like:
1While a longer certificate chain could be embedded in the device, it is not advised. Any part of the manufacturing chain that can do such a thing should simply put it's own identity there, and provide a new certificate chain path to the Registrar.
In addition to authorization a node to join the network, the node agree to provide authorization to a PCE in order for the 6top protocol to run. This protocol, described in section X of 6tisch architecture (this) document and in [6top], permits the PCE to program a timeslot schedule into the node.
So, the second part of the 6tisch security requirements is to establish the identities of the the node and the PCE, and to establish an authorization that permits the new node to be programmed by the PCE.
As explained in [I-D.behringer-autonomic-network-framework] the layer-2 identity of the node will be given by a certificate signed by the vendor of the node. The vendor's certificate authority is loaded into the (PANA) Authorization Server, and permits the AS to authenticate the node.
The vendor provides a certificate (chain) to the (PANA) Authorization Server (PAS) attesting to that the PAS is the rightful owner/controller of the node. This permits the node to validate that the network it is joining is the correct network. This process permits the bootstrap of one of the layer-2 security mechanism(s) describe in sections below.
The same set of trust relationships can then permit the PAS to act as an Authorization Server (now, in the context of [I-D.gerdes-core-dcaf-authorize]). The PCE and it's Authorization Manager (AM, again from [I-D.gerdes-core-dcaf-authorize]) can now get a ticket to permit it to write the timeslot schedule. In option 2, below, it also permits updates to the security parameters.
This is an adaptation of the process described in [ZigBeeIP], section and expounded upon in section 6.3: "Network Discovery", 6.4: "Network Selection", and 6.5, "Node Joining". The process is abridged below.
The MAC beacon facility is used. A critical difference in 6tisch from ZigBee IP is that because nodes transmit and receive according to their own schedule, every node is in essence a coordinator. While nodes may sleep a lot, they will not in general be sleep Hosts, from a ZigBee IP point of view, and MLE is not necessary.
Each response to the Beacon is a potential network-joining-parent.
As an option, it may be desireable for this document to define a well known NetworkID.
The PANA payloads MUST be relayed by the chosen network-joining-parent. It is assumed that the PANA Authentication Agent is co-located with the PCE, if there is a PCE.
As per section 8.3.4 of [ZigBeeIP], the PANA process runs over UDP using link-layer addressing. The process is first the PANA initialization (PCI, PAR:S, PAN:S), followed by EAP initialization (EAP-Request, EAP-Response), which negotiates the identity, and then EAP-TLS starts, consisting of (TLS(Start), TLS(ClientHello), TLS(ServerHello), TLS(ServerKeyExchange), TLS(ClientKeyExchange), and TLS(ChangeCipherSpec)).
When the TLS is done, the EAP derives new network security material, and sends it encrypted using the Encr-Encap AVP described in [RFC6786].
QUESTION: can we find a way for the authorization protocol, such as described in draft-gerdes-core-dcaf-authorize-01, to run simultaenously with the authentication system if we assume that the dcaf AS is also the PANA Authentication Server/Agent
In the context of draft-selander-core-access-control, the new node that is joining is the resource server, and the origin client is the PCE.
Calculations show that with a contention-based medium, using slotted Aloha style, there will be only 1-3 cells available per slotframe, at most 36% of bandwidth. Typical slotframes repeat 10 times/second. Calculations show that it take about 10-15s for each node to join, or about 30 minutes for 10-hop deep, 100-node network. This assumes 300 bytes for a certificate.
JS: in WHART, all frames sent to centralized manager to set up tyransport session. Primary different is tha the number fo frame is very small (1 frame up, 1 frame down) to get transport session started.
JS: limitation is that you cannot cleanly separate joining flows from steady-state flws in the netowkr. You can take device from box, which will disrupt data traffic. In a typical HART network, amount of BW for joining is really low. Limitation, no external validation of the manager's ID, other than it posesses the right key.
This is an adaptation of the process described in [HART], section 6.6.3.
In this process, the new node joins using a well-known layer-2 "JOIN" key. It brings up the layer-3, using 6loWPAN Neighbour Discovery to learn of the 6lowpan contexts, and then uses RPL to join a well-known DODAG as a leaf node.
Nodes which have capacity for new joining nodes will respond to the RPL DIS messages. Once connected, the new node uses regular unicasted IP datagrams to contact an Authorization Manager (in the context of [I-D.gerdes-core-dcaf-authorize]). The negotiation with the Authorization Manager (AM) uses the autonomic certificates as described above to establish the trust relationship.
Once the relationship is up, the AM needs to signal the PCE that it has a new authorized node, and the PCE can now (acting as a [I-D.gerdes-core-dcaf-authorize] Client), get a Ticket to update the node.
The PCE then writes both a new timeslot schedule, and also writes new security parameters that permit the node to fully join the network. Appropriate layer-2 keys are updated, as well as any appropriate layer-3 RPL credentials. MLE may be used to establish pair-wise keying, as appropriate to the timeslot schedule.
| [I-D.behringer-autonomic-network-framework] | Behringer, M., Pritikin, M., Bjarnason, S. and A. Clemm, "A Framework for Autonomic Networking", Internet-Draft draft-behringer-autonomic-network-framework-01, October 2013. |
| [RFC5191] | Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. |
| [RFC5247] | Aboba, B., Simon, D. and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. |
| [RFC6869] | Salgueiro, G., Clarke, J. and P. Saint-Andre, "vCard KIND:device", RFC 6869, February 2013. |