Skip to main content

Requirements for a Lightweight AKE for OSCORE.
draft-selander-lake-reqs-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Göran Selander
Last updated 2019-04-16
Replaced by draft-ietf-lake-reqs
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-selander-lake-reqs-01
Network Working Group                                        G. Selander
Internet-Draft                                               Ericsson AB
Intended status: Informational                            April 17, 2019
Expires: October 19, 2019

             Requirements for a Lightweight AKE for OSCORE.
                      draft-selander-lake-reqs-01

Abstract

   This document compiles the requirements for a lightweight
   authenticated key exchange protocol for OSCORE.

Status of This Memo

   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 19, 2019.

Copyright Notice

   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.

Selander                Expires October 19, 2019                [Page 1]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem description . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Credentials . . . . . . . . . . . . . . . . . . . . . . .   2
     2.2.  Crypto Agility  . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  AKE for OSCORE  . . . . . . . . . . . . . . . . . . . . .   3
     2.4.  Lightweight . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements Summary  . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   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 with
   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 compiles the requirements for such an AKE for the
   purpose of dispatching this work in the IETF.

2.  Problem description

2.1.  Credentials

   IoT deployments differ in terms of what credentials can be supported.
   Currently many systems use pre-shared keys (PSK) provisioned out of
   band.  PSK based provisioning has inherent weaknesses; 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.  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 RPKs need not be secret.  By running the
   asymmetric key AKE with public key certificates instead of RPK, key
   provisioning can be omitted leading to a more automated bootstrapping
   procedure.

   These steps provide 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

Selander                Expires October 19, 2019                [Page 2]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

   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.

2.2.  Crypto Agility

   Motivated by long deployment lifetimes, the AKE is required to
   support crypto agility, including modularity of COSE crypto
   algorithms and negotiation of preferred crypto algorithms for OSCORE
   and the AKE.  The AKE negotiation should be protected against
   downgrade attacks.

2.3.  AKE for OSCORE

   In order to be suitable for OSCORE, at the end of the AKE the two
   parties should have agreed on:

   o  a shared secret (OSCORE Master Secret) with PFS and a good amount
      of randomness

   o  identifiers providing a hint to the receiver of what security
      context it should use when decrypting the message (OSCORE Sender
      IDs of peer endpoints), arbitrarily short

   o  COSE algorithms to use with OSCORE

   Moreover, the AKE should support the same transport as OSCORE, in
   particular any protocol where CoAP can be transported.

   To ensure that the AKE is efficient for the expected applications of
   OSCORE, we list the relevant public specifications of technologies
   where OSCORE is included:

   o  The IETF 6TiSCH WG charter (-02) identifies the need to "secur[e]
      the join process and mak[e] that fit within the constraints of
      high latency, low throughput and small frame sizes that
      characterize IEEE802.15.4 TSCH".  OSCORE protects the join
      protocol as described in 6TiSCH Minimal Security
      [I-D.ietf-6tisch-minimal-security].

   o  The IETF LPWAN WG charter (-01) identifies the need to improve the
      transport capabilities of LPWA networks such as NB-IoT and LoRa
      whose "common traits include ... frame sizes ... [on] the order of
      tens of bytes transmitted a few times per day at ultra-low
      speeds".  The application of OSCORE is described in
      [I-D.ietf-lpwan-coap-static-context-hc].

Selander                Expires October 19, 2019                [Page 3]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

   o  OMA Specworks LwM2M version 1.1 [LwM2M] defines bindings to two
      challenging radio technologies where OSCORE will be deployed:
      LoRaWAN and NB-IoT.

   Other industry fora which plan to use OSCORE:

   o  Fairhair Alliance has defined an architecture [Fairhair] which
      adopts OSCORE for multicast, but it is not clear whether the
      architecture will support unicast OSCORE.

   o  Open Connectivity Foundation (OCF) has been actively involved in
      the OSCORE development for the purpose of deploying OSCORE, but no
      public reference is available since OCF only references RFCs.  We
      believe that these OSCORE consumers reflect similar levels of
      constraints on the devices and networks in question.

   The solution will presumably be useful in other scenarios as well
   since a low security overhead improves the overall performance, but
   we do not require the solution to necessarily be applicable anywhere
   else.

2.4.  Lightweight

   As motivated in Section 2.3 we target an AKE which is efficiently
   deployable in 6TiSCH multi-hop networks, LoRaWAN 1.0 networks and NB-
   IoT networks.  The desire is to optimize the AKE to be 'as
   lightweight as reasonably achievable' in these environments, where
   'lightweight' refers to:

   o  resource consumption, measured by bytes on the wire, wall-clock
      time to complete (i.e., the initial latency added to application
      protocols by the AKE), or power

   o  the amount of new code required on end systems which already have
      an OSCORE stack

   It may be necessary to evaluate options that make different trade-
   offs across these dimensions.  The properties needs to be evaluated
   in the context of the use of an existing CoAP/OSCORE stack in the
   targeted networks.

   Per 'bytes on the wire', it is desirable for these AKE messages to
   fit into the MTU size of these protocols; and if not possible, within
   as few frames as possible, since using multiple MTUs can have
   significant costs in terms of time and power.

   Per 'time', it is desirable for the AKE message exchange(s) to
   complete in a reasonable amount of time, both for a single

Selander                Expires October 19, 2019                [Page 4]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

   uncongested exchange and when multiple exchanges are running in an
   interleaved fashion.  This latency may not be a linear function
   depending on congestion and the specific radio technology used.  As
   these are relatively low data rate networks, the latency contribution
   due to computation is in general not expected to be dominant.

   Per 'power', it is desirable for the transmission of AKE messages and
   crypto to draw as little power as possible.  The best mechanism for
   doing so differs across radio technologies.  For example, NB-IoT uses
   licensed spectrum and thus can transmit at higher power to improve
   coverage, making the transmitted byte count relatively more important
   than for other radio technologies.  In other cases, the radio
   transmitter will be active for a full MTU frame regardless of how
   much of the frame is occupied by message content, which makes the
   byte count less sensitive for the power consumption.  Increased power
   consumption is unavoidable in poor network conditions, such as most
   wide-area settings including LoRaWAN.

   Per 'new code', it is desirable to introduce as little new code as
   possible onto OSCORE-enabled devices to support this new AKE.  These
   devices have on the order of 10s of kB of memory and 100 kB of
   storage on which an embedded OS; a COAP stack; CORE and AKE
   libraries; and target applications would run.  It is expected that
   the majority of this space is available for actual application logic,
   as opposed to the support libraries.  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 (e.g.  COSE
   algorithm no. 10 = CCM* used by 6TiSCH).  The use of those, or CBOR
   or CoAP, would not add to the footprint.

   While the large variety of settings and capabilities of the devices
   and networks makes it challenging to produce exact values of some
   these dimensions, there are some key benchmarks that are tractable
   for security protocol engineering and which have a significant
   impact.

2.4.1.  LoRaWAN

   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.
   LoRaWAN is legally required to use a 1% (or smaller) duty cycle, a
   payload split into two fragments instead of one increases the time to
   complete the sending of this payload by at least 10,000%. The use of
   an AKE for providing end-to-end security on application layer need to
   comply with the duty cycle.  One relevant benchmark is performance in

Selander                Expires October 19, 2019                [Page 5]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

   low coverage with Data Rates 0-2 corresponding to a packet size of 51
   bytes [LoRaWAN].  While larger frame sizes are also defined, their
   use depend on good radio conditions.  Some libraries/providers only
   support 51 bytes packet size.

2.4.2.  6TiSCH

   For 6TiSCH specifically, as a time-sliced network, bytes of the wire
   (or rather, the quantization into frame count) is particularly
   noteworthy, since more frames contribute to congestion for spectrum
   (and concomitant error rates) in a non-linear way, especially in
   scenarios when large numbers of independent nodes are attempting to
   execute an AKE to join a network.

   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 47/45 bytes
   (uplink/downlink) [AKE-for-6TiSCH].

2.4.3.  NB-IoT

   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, so the time before sending OSCORE protected
   data is dependent on the number of round trips/messages of the AKE.
   An AKE providing challenge-response based mutual authentication
   requires at least three messages/one round trip before it is possible
   to encrypt traffic data between peers meeting for the first time.
   NB-IoT has a high per byte energy consumption component for uplink
   transfers, implying that those messages should be as small as
   possible.

2.4.4.  Discussion

   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

Selander                Expires October 19, 2019                [Page 6]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

   consumption and latency.  Additionally the probability for errors
   increases, 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
   benefits in terms of fewer messages/round trips in general and for
   NB-IoT in particular (see Section 2.4.3) 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.

3.  Requirements Summary

   o  The AKE should support PSK, RPK and certificate based
      authentication and crypto agility, be 3-pass and support the same
      transport as OSCORE.

   o  After the AKE run, the peers should agree on a shared secret with
      PFS and good amount of randomness, peer identifiers (potentially
      short), and COSE algorithms to use.

   o  The AKE should reuse CBOR, CoAP and COSE primitives and algorithms
      for low code complexity of a combined OSCORE and AKE
      implementation.

   o  The messages should be as small as reasonably achievable and fit
      into as few LoRaWAN packets and 6TiSCH frames as possible,
      optimally 1 for each message.

4.  Security Considerations

   This document compiles the requirements for an AKE and provides some
   related security considerations to support the dispatch process.
   Further security considerations are out of scope of this document.

5.  IANA Considerations

   None.

6.  Informative References

   [AKE-for-6TiSCH]
              "AKE for 6TiSCH", n.d., <https://docs.google.com/document/
              d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k>.

Selander                Expires October 19, 2019                [Page 7]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

   [Fairhair]
              "Security Architecture for the Internet of Things (IoT) in
              Commercial Buildings, Fairhair Alliance white paper, March
              2018", n.d., <https://www.fairhair-
              alliance.org/data/downloadables/1/9/
              fairhair_security_wp_march-2018.pdf>.

   [I-D.ietf-6tisch-minimal-security]
              Vucinic, M., Simon, J., Pister, K., and M. Richardson,
              "Minimal Security Framework for 6TiSCH", draft-ietf-
              6tisch-minimal-security-10 (work in progress), April 2019.

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-16 (work in
              progress), March 2019.

   [I-D.ietf-lpwan-coap-static-context-hc]
              Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
              Context Header Compression (SCHC) for CoAP", draft-ietf-
              lpwan-coap-static-context-hc-06 (work in progress),
              February 2019.

   [LoRaWAN]  "LoRaWAN Regional Parameters v1.0.2rB", n.d.,
              <https://lora-alliance.org/resource-hub/
              lorawantm-regional-parameters-v102rb>.

   [LwM2M]    "OMA SpecWorks LwM2M", n.d.,
              <http://www.openmobilealliance.org/release/LightweightM2M/
              V1_1-20180710-A/
              OMA-TS-LightweightM2M_Transport-V1_1-20180710-A.pdf>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

Author's Address

   Goeran Selander
   Ericsson AB

   Email: goran.selander@ericsson.com

Selander                Expires October 19, 2019                [Page 8]