Requirements for a Lightweight AKE for OSCORE
draft-selander-lake-reqs-03

Network Working Group                                         M. Vucinic
Internet-Draft                                                     INRIA
Intended status: Informational                               G. Selander
Expires: May 7, 2020                                         J. Mattsson
                                                             Ericsson AB
                                                               D. Garcia
                                                     Odin Solutions S.L.
                                                       November 04, 2019

             Requirements for a Lightweight AKE for OSCORE
                      draft-selander-lake-reqs-03

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 May 7, 2020.

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

Vucinic, et al.            Expires May 7, 2020                  [Page 1]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem description . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  AKE for OSCORE  . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Credentials . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Identity Protection . . . . . . . . . . . . . . . . . . .   5
     2.4.  Crypto Agility and Security Properties  . . . . . . . . .   5
     2.5.  Mutual Authentication . . . . . . . . . . . . . . . . . .   6
     2.6.  Lightweight . . . . . . . . . . . . . . . . . . . . . . .   6
     2.7.  Application Data  . . . . . . . . . . . . . . . . . . . .  13
   3.  Requirements Summary  . . . . . . . . . . . . . . . . . . . .  14
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   OSCORE [RFC8613] is a lightweight communication security protocol
   providing end-to-end security on application layer for constrained
   IoT settings (cf.  [RFC7228]).  OSCORE lacks a matching authenticated
   key exchange protocol (AKE).

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

Vucinic, et al.            Expires May 7, 2020                  [Page 2]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 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.

   This document compiles the requirements for the AKE for OSCORE.  It
   summarizes the security requirements that are expected from such an
   AKE, as well as the main characteristics of the environments where
   the solution is envisioned to be deployed.  The solution will
   presumably be useful in other scenarios as well since a low security
   overhead improves the overall performance.

2.  Problem description

2.1.  AKE for OSCORE

   The rationale for designing this protocol is that OSCORE is lacking a
   matching AKE.  OSCORE was designed for lightweight RESTful operations
   for example by minimizing the overhead, and applying the protection
   to the application layer, thereby limiting the data being encrypted
   and integrity protected for the other endpoint.  Moreover, OSCORE was
   tailored for use with lightweight primitives that are likely to be
   implemented in the device, specifically CoAP, CBOR and COSE.  The
   same properties must apply to the AKE.

   In order to be suitable for OSCORE, at the end of the AKE protocol
   run the two parties must agree on (see Section 3.2 of [RFC8613]):

   o  a shared secret (OSCORE Master Secret) with PFS and a good amount
      of randomness.  (The term "good amount of randomness" is borrowed
      from [HKDF] to signify not necessarily uniformly distributed
      randomness.)

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

Vucinic, et al.            Expires May 7, 2020                  [Page 3]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   o  COSE algorithms to use with OSCORE

   Moreover, the AKE must support the same transport as OSCORE, in
   particular any protocol where CoAP can be transported.  Since the AKE
   messages most commonly will be encapsulated in CoAP, the AKE must not
   duplicate functionality provided by CoAP.  It is therefore assumed
   that the AKE is being transported in a protocol that provides
   reliable transport, that can preserve packet ordering and handle
   message duplication, that can perform fragmentation and protect
   against denial of service attacks.

   The AKE may be transported over other transport than CoAP.  In this
   case the underlying layers must handle message loss, reordering,
   message duplication, fragmentation, and denial of service protection.

2.2.  Credentials

   IoT deployments differ in terms of what credentials can be supported.
   Currently many systems use pre-shared keys (PSKs) provisioned out of
   band, for various reasons.  PSKs are often used in a first deployment
   because of their perceived simplicity.  The use of PSKs allows for
   protection of communication without major additional security
   processing, and also enables the use of symmetric crypto algorithms
   only, reducing the implementation and computational effort in the
   endpoints.

   However, PSK-based provisioning has inherent weaknesses.  There has
   been reports of massive breaches of PSK provisioning systems, and as
   many systems use PSKs 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.

   Shared keys can alternatively be established in the endpoints using
   an AKE protocol authenticated with asymmetric public keys instead of
   symmetric secret keys.  Raw public keys (RPK) can be provisioned with
   the same scheme as PSKs, which allows for a more relaxed trust model
   since RPKs need not be secret.

   As a third option, by using a public key infrastructure and running
   an asymmetric key AKE with public key certificates instead of RPKs,
   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 security bootstrapping and
   provisioning schemes where each step improves the overall security

Vucinic, et al.            Expires May 7, 2020                  [Page 4]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   and/or simplicity of deployment of the IoT system, although not all
   steps are necessarily feasible for the most constrained settings.

   In order to allow for these different schemes, the AKE must support
   PSK (shared between two nodes), RPK and certificate-based
   authentication.

   Bandwidth is a scarce resource in constrained-node networks.  To
   minimize the bandwidth consumption it is therefore desirable to
   support transporting the certificates by reference rather than by
   value.  Considering the wide variety of deployments the AKE must
   support different schemes for transporting and identifying
   credentials, see Section 2 of [I-D.ietf-cose-x509].

   The common lack of a user interface in constrained devices leads to
   various credential provisioning schemes.  The use of RPKs may be
   appropriate for the authentication of the AKE initiator but not for
   the AKE responder.  The AKE must support different credentials for
   authentication in different directions of the AKE run, e.g.
   certificate-based authentication for the initiating endpoint and RPK-
   based authentication for the responding endpoint.

2.3.  Identity Protection

   Transporting identities as part of the AKE run is a necessity in
   order to provide strong mutual authentication.  In the case of
   constrained devices, the identity may contain sensitive information
   on the manufacturer of the device, the batch, default firmware
   version, etc.  Protecting the identities from passive and active
   attacks is important from the privacy point of view.

   The AKE is required to support identity protection against active
   attackers of one of the peers and protection against passive
   attackers of the other peer in the case of public key identities, or
   the protection of the PSK identifier in the case of PSK-based
   authentication.  The AKE should allow the most sentive idenity to
   recieve the strongest protection.  Note that encryption of the PSK
   identifier is first possible in the third AKE message, which implies
   that at least four protocol messages are required for authentication
   of responder in case of symmetric key authentication (see
   Section 2.5).

2.4.  Crypto Agility and Security Properties

   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 should support negotiation of the all COSE

Vucinic, et al.            Expires May 7, 2020                  [Page 5]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   algorithms that OSCORE supports.  The AKE negotiation must be
   protected against downgrade attacks.

   Compromise of the long-term keys shall not enable an attacker to
   compromise past session keys (Perfect Forward Secrecy) and shall not
   enable an passive attacker to compromise future session keys.  This
   two properties can be achieved with a ephemeral Diffie-Hellman key
   exchange.  The AKE shall provide Key Compromise Impersonation (KCI)
   resistance.

   The AKE shall protect against misbinding attacks and reflection
   attacks such as the recently published Selfie attack on TLS 1.3.

2.5.  Mutual Authentication

   The AKE must provide mutual authentication (injective agreement)
   during the protocol run.

   The AKE cannot rely on messages being exchanged in both directions
   after the AKE has completed, because CoAP/OSCORE requests may not
   have a response [RFC7967].  Furthermore, there is no assumption of
   dependence between CoAP client/server and AKE initiator/responder
   roles, and an OSCORE context may be used with CoAP client and server
   roles interchanged as is done e.g. in [LwM2M].

2.6.  Lightweight

   We target an AKE which is efficiently deployable in 6TiSCH multi-hop
   networks, LoRaWAN 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 and number of round trips to complete, or power consumption

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

   These properties need to be considered in the context of the use of
   an existing CoAP/OSCORE stack in the targeted networks and
   technologies.  Some properties are difficult to evaluate for a given
   protocol, for example, because they depend on the radio conditions or
   other simultaneous network traffic.  Additionally, these properties
   are not independent.  Therefore the properties listed here should be
   taken as input for identifying plausible protocol metrics that can be
   more easily measured and compared between protocols.

Vucinic, et al.            Expires May 7, 2020                  [Page 6]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   Per 'bytes on the wire', it is desirable for the 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
   uncongested exchange and when multiple exchanges are running in an
   interleaved fashion, like e.g. in a "network formation" setting when
   multiple devices connect for the first time.  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 'round-trips', it is desirable that the number of completed
   request/response message exchanges required before the initiating
   endpoint can start sending protected traffic data is as small as
   possible, since this reduces completion time.  See Section 2.6.4 for
   a discussion about the tradeoff between message size and number of
   messages.

   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.

Vucinic, et al.            Expires May 7, 2020                  [Page 7]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

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

   LoRaWAN employs unlicensed radio frequency bands in the 868 MHz ISM
   band.  As a case in point, we focus here on deployment in Europe,
   where this is 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 as an indicator to calculate energy
   consumption.  LoRaWAN is legally required to use a duty cycle with
   values such as 0.1%, 1% and 10% depending on the sub-band that is
   being used, leading to a payload split into fragments interleaved
   with back-off times.  For Europe, the duty cycle is 1% (or smaller).
   Although there are exceptions from the use of duty cycle, the use of
   an AKE for providing end-to-end security on application layer needs
   to comply with the duty cycle.

2.6.1.1.  Bytes on the wire

   LoRaWAN has a variable MTU depending on the Spreading Factor (SF).
   The higher the spreading factor, the higher distances can be achieved
   and/or better reception.  LoRaWAN has a header size of 13 bytes, to
   which we have to add the maximum recommended payload depending on the
   SF used.  If the coverage and distance allows it, with SF7 -
   corresponding to higher data rates - the maximum payload is 222
   bytes.  For a SF12 - and low data rates - the maximum payload is 51
   bytes.

   The benchmark used here is Data Rates 0-2 corresponding to a packet
   size of 51 bytes [LoRaWAN].  The use of larger frame size depend on
   good radio conditions which are not always present.  Some libraries/
   providers only support 51-bytes packet size.

2.6.1.2.  Time

   The time it takes to send a message over the air in LoRaWAN can be
   calculated as a function of the different parameters of the
   communication.  These are the Spreading Factor (SF), the message
   size, the channel, bandwidth, coding rate, etc.  An important feature
   of LoRaWAN is the duty cycle limitation due to the use of the ISM
   band.  A duty cycle of 1% implies that the time to complete a
   fragmentation of the payload increases by at least 10,000%. This
   limitation determines how long time the device will have to wait for

Vucinic, et al.            Expires May 7, 2020                  [Page 8]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   next use, which encourages the reduction of the message size as much
   as possible.

2.6.1.3.  Round trips and number of messages

   Considering the duty cycle of LoRaWAN and associated back-off times,
   the round trips and number of messages needs to be reduced as much as
   possible.

2.6.1.4.  Power

   The calculation of the power consumption in LoRaWAN is dependent on
   several factors, such as the spreading factor used and the length of
   the message sent, both having a clear dependency with the time it
   takes to transmit the message.  The communication model (inherent to
   the different LoRaWAN classes of devices) also has an impact on the
   energy consumption, but overall the Time-on-Air is an important
   indication of the performance.

2.6.2.  6TiSCH

   6TiSCH operates in the 2.4 GHz unlicensed frequency band and uses
   hybrid Time Division/Frequency Division multiple access (TDMA/FDMA).
   Nodes in a 6TiSCH network form a mesh.  The basic unit of
   communication, a cell, is uniquely defined by its time and frequency
   offset in the communication schedule matrix.  Cells can be assigned
   for communication to a pair of nodes in the mesh and so be collision-
   free, or shared by multiple nodes, for example during network
   formation.  In case of shared cells, some collision-resolution scheme
   such as slotted-Aloha is employed.  Nodes exchange frames which are
   at most 127-bytes long, including the link-layer headers.  To
   preserve energy, the schedule is typically computed in such a way
   that nodes switch on their radio below 1% of the time ("radio duty
   cycle").  A 6TiSCH mesh can be several hops deep.  In typical use
   cases considered by the 6TiSCH working group, a network that is 2-4
   hops deep is commonplace; a network which is more than 8 hops deep is
   not common.

2.6.2.1.  Bytes on the wire

   Increasing the number of bytes on the wire in a protocol message has
   an important effect on the 6TiSCH network in case the fragmentation
   is triggered.  More fragments contribute to congestion of shared
   cells (and concomitant error rates) in a non-linear way.

   The available size for key exchange messages depends on the topology
   of the network, whether the message is traveling uplink or downlink,
   and other stack parameters.  A key performance indicator for a 6TiSCH

Vucinic, et al.            Expires May 7, 2020                  [Page 9]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   network is "network formation", i.e. the time it takes from switching
   on all devices, until the last device has executed the AKE and
   securely joined.  As an example, given the size limit on the frames
   and taking into account the different headers (including link-layer
   security), if a 6TiSCH network is 5 hops deep, the maximum CoAP
   payload size to avoid fragmentation is 47/45 bytes (uplink/downlink)
   [AKE-for-6TiSCH].

2.6.2.2.  Time

   Given the slotted nature of 6TiSCH, the number of bytes in a frame
   has insignificant impact on latency, but the number of frames has.
   The relevant metric for studying AKE is the network formation time,
   which implies parallel AKE runs among nodes that are attempting to
   join the network.  Network formation time directly affects the time
   installers need to spend on site at deployment time.

2.6.2.3.  Round trips and number of messages

   Given the mesh nature of the 6TiSCH network, and given that each
   message may travel several hops before reaching its destination, it
   is highly desirable to minimize the number of round trips to reduce
   latency.

2.6.2.4.  Power

   From the power consumption point of view, it is more favorable to
   send a small number of large frames than a larger number of short
   frames.

2.6.3.  NB-IoT

   3GPP has specified Narrow-Band IoT (NB-IoT) for support of infrequent
   data transmission via user plane and via control plane.  NB-IoT is
   built on cellular licensed spectrum at low data rates for the purpose
   of supporting:

   o  operations in extreme coverage conditions,

   o  device battery life of 10 years or more,

   o  low device complexity and cost, and

   o  a high system capacity of millions of connected devices per square
      kilometer.

   NB-IoT achieves these design objectives by:

Vucinic, et al.            Expires May 7, 2020                 [Page 10]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   o  Reduced baseband processing, memory and RF enabling low complexity
      device implementation.

   o  A lightweight setup minimizing control signaling overhead to
      optimize power consumption.

   o  In-band, guard-band, and stand-alone deployment enabling efficient
      use of spectrum and network infrastructure.

2.6.3.1.  Bytes on the wire

   The number of bytes on the wire in a protocol message has a direct
   effect on the performance for NB-IoT.  In contrast to LoRaWAN and
   6TiSCH, the NB-IoT radio bearers are not characterized by a fixed
   sized PDU.  Concatenation, segmentation and reassembly are part of
   the service provided by the NB-IoT radio layer.  As a consequence,
   the byte count has a measurable impact on time and energy consumption
   for running the AKE.

2.6.3.2.  Time

   Coverage significantly impacts the available bit rate and thereby the
   time for transmitting a message, and there is also a difference
   between downlink and uplink transmissions (see Section 2.6.3.4).  The
   transmission time for the message is essentially proportional to the
   number of bytes.

   Since NB-IoT is operating in licensed spectrum, in contrast to e.g.
   LoRaWAN, the packets on the radio interface can be transmitted back-
   to-back, so the time before sending OSCORE protected data is limited
   by the number of round trips/messages of the AKE and not by a duty
   cycle.

2.6.3.3.  Round trips and number of messages

   As indicated in Section 2.6.3.2, the number of messages and round-
   trips is one limiting factor for protocol completion time.

2.6.3.4.  Power

   Since NB-IoT is operating in licensed spectrum, the device is allowed
   to transmit at a relatively high power, which has a large impact on
   the energy consumption.

   The benchmark for NB-IoT energy consumption is based on the same
   computational model as was used by 3GPP in the design of this radio
   layer [NB-IoT-battery-life-evaluation].  The device power consumption
   is assumed to be 500mW for transmission and 80mW for reception.

Vucinic, et al.            Expires May 7, 2020                 [Page 11]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   Power consumption for "light sleep" (~ 3mW) and "deep sleep" (~
   0.015mW) are negligible in comparison.  The bitrates (uplink/
   downlink) are assumed to be 28/170 kbps for good coverage and
   0,37/2,5 kbps for bad coverage.

   The results [AKE-for-NB-IoT] show a high per-byte energy consumption
   for uplink transmissions, in particular in bad coverage.  Given that
   the application decides about the device being initiator or responder
   in the AKE, the protocol cannot be tailored for a particular message
   being uplink or downlink.  To perform well in both kind of
   applications the overall number of bytes of the protocol needs to be
   as low as possible.

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

   The difference between uplink and downlink performance should not be
   engineered into the protocol since it cannot be assumed that a
   particular protocol message will be sent uplink or downlink.

2.6.5.  AKE frequency

   One question that has been asked in the context of lightweightness
   is: - How often is the AKE executed?  While it may be impossible to
   give a precise answer there are other perspectives to this question.

Vucinic, et al.            Expires May 7, 2020                 [Page 12]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   1.  For some use cases, already one execution of the AKE is too
       heavy, for example, because

       *  there are a number of parallel executions of the AKE in a
          network formation setting which loads down the network, or

       *  the duty cycle makes the completion time too long for even one
          run of the protocol.

   2.  If a device reboots it may not be able to recover the security
       context, e.g. due to lack of persistent storage, and is required
       to establish a new security context for which an AKE is
       preferred.  Reboot frequency may be difficult to predict in
       general.

   3.  To limit the impact of a key compromise, BSI, NIST and ANSSI and
       other organizations recommend in other contexts frequent renewal
       of keys by means of Diffie-Hellman key exchange.

   To summarize, even if it we are unable to give precise numbers for
   AKE frequency, a lightweight AKE * reduces the time for network
   formation and AKE runs in challenging radio technologies, * allows
   devices to quickly re-establish security in case of reboots, and *
   enables support for recommendations of frequent key renewal

2.7.  Application Data

   In order to reduce round trips and number of messages, and in some
   cases also streamline processing, certain applications may want to
   transport application data within the AKE.

   One example is the transport of third-party signed authorization
   information such as an access token or a voucher from initiator to
   responder or vice versa.  Such a scheme could enable the party
   receiving the authorization information to make a decision about
   whether the party being authenticated is also authorized before the
   protocol is completed, and if not discontinue the protocol before it
   is complete, thereby saving time and message processing.

   Another example is the embedding of certificate enrolment request or
   a newly issued certificate.

   There are several considerations to make which needs to be addressed
   in the specification of the AKE.  For example: The available
   protection of the application data in the AKE depend, among other
   things, on which protocol message the application data is carried in.
   Authorization information may reveal privacy sensitive information.

Vucinic, et al.            Expires May 7, 2020                 [Page 13]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   The AKE must support the transport of application data within the
   protocol message and provide the necessary instructions for how to
   use this mechanism and its security and privacy properties.

3.  Requirements Summary

   o  The AKE must support PSK, RPK and certificate based authentication
      and crypto agility, be 3-pass and support the same transport as
      OSCORE.  It is desirable to support different schemes for
      transporting and identifying credentials.

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

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

   o  The messages must 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.

   The AKE must provide the security properties expected of IETF
   protocols, e.g., providing confidentiality protection, integrity
   protection, and authentication with strong work factor.

5.  IANA Considerations

   None.

Acknowledgments

   The authors want to thank Karthik Bhargavan, Michael Richardson and
   Claes Tidestav for providing valuable input.

7.  Informative References

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

Vucinic, et al.            Expires May 7, 2020                 [Page 14]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

   [AKE-for-NB-IoT]
              "AKE for NB-IoT", March 2019,
              <https://github.com/EricssonResearch/EDHOC/blob/master/
              docs/NB%20IoT%20power%20consumption.xlsx>.

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

   [HKDF]     Krawczyk, H., "Cryptographic Extraction and Key
              Derivation: The HKDF Scheme", May 2010,
              <https://eprint.iacr.org/2010/264.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-13 (work in progress), October
              2019.

   [I-D.ietf-cose-x509]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Headers for carrying and referencing X.509 certificates",
              draft-ietf-cose-x509-04 (work in progress), September
              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-11 (work in progress),
              October 2019.

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

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

   [NB-IoT-battery-life-evaluation]
              "On mMTC, NB-IoT and eMTC battery life evaluation",
              January 2017,
              <http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/
              NR_AH_1701/Docs//R1-1701044.zip>.

Vucinic, et al.            Expires May 7, 2020                 [Page 15]
Internet-Draft            Reqs-LAKE-for-OSCORE             November 2019

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

   [RFC7967]  Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
              Bose, "Constrained Application Protocol (CoAP) Option for
              No Server Response", RFC 7967, DOI 10.17487/RFC7967,
              August 2016, <https://www.rfc-editor.org/info/rfc7967>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

Authors' Addresses

   Malisa Vucinic
   INRIA

   Email: malisa.vucinic@inria.fr

   Goeran Selander
   Ericsson AB

   Email: goran.selander@ericsson.com

   John Preuss Mattsson
   Ericsson AB

   Email: john.mattsson@ericsson.com

   Dan Garcia-Carrillo
   Odin Solutions S.L.

   Email: dgarcia@odins.es

Vucinic, et al.            Expires May 7, 2020                 [Page 16]