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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Author Göran Selander 
Last updated 2019-04-12
Replaced by draft-ietf-lake-reqs
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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

Abstract

   This document contains 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 14, 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 14, 2019                [Page 1]
Internet-DrafRequirements for a Lightweight AKE for OSCORE.   April 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Credentials . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Crypto Agility  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Detailed Problem Description  . . . . . . . . . . . . . . . .   3
     4.1.  AKE for OSCORE  . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Lightweight . . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

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 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.

2.  Credentials

   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.

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

3.  Crypto Agility

   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.

4.  Detailed Problem Description

   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.

4.1.  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

   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:

   o  IETF 6TiSCH Minimal Security [I-D.ietf-6tisch-minimal-security]

   o  LwM2M version 1.1 [LwM2M].  LwM2M v1.1 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.

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

   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, a
      low security overhead improves the overall performance, but we do
      not require the solution to necessarily be applicable anywhere
      else.

4.2.  Lightweight

   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:

   o  Low latency

   o  Low memory and code complexity

   o  Low power consumption

   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

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

   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.

4.2.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.
   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.

4.2.2.  6TiSCH

   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.

4.2.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.  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

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

   byte energy consumption component for uplink transfers, implying that
   those messages should be as small as possible.

4.3.  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
   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.

5.  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 running AKE, 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 encrypt and sign
      primitives for low code complexity of a combined OSCORE and AKE
      implementation.

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

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

6.  Security Considerations

   The entire draft is about requirements for a security protocol.

7.  IANA Considerations

   None.

8.  Informative References

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

   [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.

   [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 14, 2019                [Page 7]