| Network Working Group | G. Selander |
| Internet-Draft | Ericsson AB |
| Intended status: Informational | April 12, 2019 |
| Expires: October 14, 2019 |
Requirements for a Lightweight AKE for OSCORE.
draft-selander-lake-reqs-00
This document contains the requirements for a lightweight authenticated key exchange protocol for OSCORE.
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 https://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 14, 2019.
Copyright (c) 2019 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 (https://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.
OSCORE [I-D.ietf-core-object-security] is a lightweight communication security protocol providing end-to-end security for constrained IoT settings (cf. [RFC7228]). It is expected to be deployed by standards and platforms using CoAP such as 6TiSCH, LPWAN, OMA Specworks LwM2M, Fairhair Alliance and Open Connectivity Foundation. OSCORE lacks a matching authenticated key exchange protocol (AKE). This document lists the requirements for such an AKE.
IoT deployments differ in terms of what credentials that can be supported. Currently many systems use pre-shared keys (PSK) provisioned out of band. There has been reports of massive breaches of PSK provisioning systems, and as many systems use PSK without perfect forward secrecy (PFS), they are vulnerable to passive pervasive monitoring. The security of these systems can be improved by adding PFS through an AKE authenticated by the provisioned PSK. Furthermore, reusing the provisioning scheme for raw public keys (RPK) instead of PSK, together with an AKE authenticated with the RPKs provides a more relaxed trust model since the RPK needs not be secret. By reusing the asymmetric key AKE but authenticate with public key certificates instead of RPK, key provisioning can be omitted leading to a more automated bootstrapping procedure. This provides an example of a migration path in limited scoped steps from simple to more robust provisioning schemes where each step improves the overall security and/or simplicity of deployment of the IoT system, although not all steps are necessarily feasible for the most constrained settings. With this in mind the AKE should support PSK, RPK and certificate based authentication.
Due to for example long deployment lifetimes, the AKE is required to support crypto agility, including modularity of COSE crypto algorithms and negotiation of preferred crypto algorithms for the AKE as well as OSCORE. The AKE negotiation should be protected against downgrade attacks.
The large variety of settings and capabilities of the devices and networks makes it challenging to produce general schemes so we need to specialize further in order to get a tractable problem. The problem statement can be broken down into two pieces, “AKE for OSCORE” (Section 4.1) and “Lightweight” (Section 4.2) followed by a discussion in Section 4.3.
In order to be suitable for OSCORE, at the end of the AKE the two parties should have agreed on:
The AKE should support the same transport as OSCORE (CoAP over foo). To ensure that the AKE is efficient for the expected applications of OSCORE, we list the available public specifications where OSCORE is intended to be used:
We target an AKE which is efficiently deployable in 6TiSCH multi-hop networks, LoRaWAN 1.0 networks and NB-IoT networks. In this space there is likely going to be other networks and future systems needs but these are not targeted. The targeted properties are in particular:
The properties needs to be evaluated in the context of the use of an existing CoAP/OSCORE stack in the targeted networks.
Latency includes single protocol runs as well as multi-node protocol runs in parallel, e.g. during network formation or power failures of central nodes with many peers. This may involve messages from different protocol runs competing on the same radio resources and disturbing each other leading to bit errors and retransmissions. As these are relatively low data rate networks, the latency contribution due to computation is in general not expected to be dominant.
The memory and code complexity added by the AKE needs to be evaluated in the context of existing support, in particular of algorithms and encodings. Hardware support for crypto is expected to be available in selected low-end chipsets. In a typical OSCORE implementation COSE encrypt and signature structures will be available, as will support for COSE algorithms relevant for IoT enabling the same algorithms as is used for OSCORE (COSE algorithm no. 10 = CCM* used by 6TiSCH). The use of those, or CBOR or CoAP, would not add to the footprint.
Power consumption is a complex subject with several components, but a large contribution is expected from wireless communication. Much engineering is already in place also for low-end radio devices to reduce power consumptions in the form of time slots, DRX, etc. In addition to these efforts to reduce energy consumption due to how it is sent, the security protocol can contribute by reduce what is being sent.
While the exact values of the target properties depend on many conditions, there are some key benchmarks that are tractable for security protocol engineering and which have a significant impact.
LoRaWAN employs unlicensed radio frequency bands in the 868MHz ISM band, in Europe regulated by ETSI EN 300 220. For LoRaWAN the most relevant metric is the Time-on-Air, which determines the back-off times and can be used an indicator to calculate energy consumption. For each packet sent there is a Duty Cycle, in Europe 1%, meaning that the sender has to wait 99 times the transmit time before sending the next packet. One relevant benchmark is performance in low coverage with Data Rates 0-2 correspond to a packet size of 51 bytes. While larger frame sizes are also defined, their use depend on good radio conditions. Some libraries/providers only support 51 bytes packet size.
For 6TiSCH latency and power consumption are dependent on the number of L2 frames being sent. The available size for key exchange messages depends the topology of the network and other parameters. One benchmark which is relevant for studying AKE is the network formation setting. For a 6TiSCH production network 5 hops deep in a network formation setting, the available CoAP overhead to avoid fragmentation is uplink/downlink 47/45 bytes [AKE-for-6TiSCH].
In terms of code size and memory, 6TiSCH is expected to be used on devices with memory of 10s of kB of memory and 100s of kB of flash containing at least the network stack, CoAP, OSCORE and the AKE.
For NB-IoT, in contrast to the other two technologies below, the radio bearers are not characterized by a fixed sized PDU. Concatenation, segmentation and reassembly are part of the service provided by the radio layer. Furthermore, since NB-IoT is operating in licensed spectrum, the packets on the radio interface can be transmitted back-to-back. Therefore the largest impact for latency is the number of messages/round trips needed to complete the protocol. An AKE providing challenge-response based mutual authentication requires at least 3 messages. NB-IoT has a high per byte energy consumption component for uplink transfers, implying that those messages should be as small as possible.
While “as small protocol messages as possible” does not lend itself to a sharp boundary threshold, “as few protocol messages as possible” does and is relevant in all settings above.
The penalty is high for not fitting into the frame sizes of 6TiSCH and LoRaWAN networks. Fragmentation is not defined within these technologies so requires fragmentation scheme on a higher layer in the stack. With fragmentation increases the number of frames per message, each with its associated overhead in terms of power consumption and latency. Additionally the probability for errors increase exponentially, which leads to retransmissions of frames or entire messages that in turn increases the power consumption and latency.
There are trade-offs between “few messages” and “few frames”; if overhead is spread out over more messages such that each message fits into a particular frame this may reduce the overall power consumption. While it may be possible to engineer such a solution for a particular radio technology and signature algorithm, the general benefits in terms of fewer messages/round trips are considered more important than optimizing for a specific scenario. Hence an optimal AKE protocol has 3 messages and each message fits into as few frames as possible, ideally 1 frame per message.
The entire draft is about requirements for a security protocol.
None.
| [AKE-for-6TiSCH] | "AKE for 6TiSCH", n.d.. |
| [Fairhair] | "Security Architecture for the Internet of Things (IoT) in Commercial Buildings, Fairhair Alliance white paper, March 2018", n.d.. |
| [I-D.ietf-6tisch-minimal-security] | Vucinic, M., Simon, J., Pister, K. and M. Richardson, "Minimal Security Framework for 6TiSCH", Internet-Draft draft-ietf-6tisch-minimal-security-10, April 2019. |
| [I-D.ietf-core-object-security] | Selander, G., Mattsson, J., Palombini, F. and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", Internet-Draft draft-ietf-core-object-security-16, March 2019. |
| [LwM2M] | "OMA SpecWorks LwM2M", n.d.. |
| [RFC7228] | Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014. |