Re: [Secdispatch] my thoughts on the EDHOC interim

[Göran Selander <[e-mail]>]

Hi Ben,

With reference to the presentation at the interim meeting, here is one way to frame this subject with the standard BoF questions. Sorry for a long email.

    1. What is the problem we are faced with?
 
Finding a lightweight AKE for OSCORE.
 
OSCORE (draft-ietf-core-object-security) is a lightweight communication security protocol providing end-to-end security for constrained IoT settings (cf. RFC 7228). It is expected to be deployed by standards and platforms using CoAP such as IETF 6TiSCH, OMA Specworks LwM2M, Fairhair Alliance and Open Connectivity Foundation. OSCORE lacks a matching authenticated key exchange protocol.

IoT deployments differ in terms of what credentials that can be supported. Currently many systems use 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, they are vulnerable to passive pervasive monitoring. The security of these systems can be improved by adding an AKE with PFS authenticated by the provisioned PSK. Furthermore, reusing the provisioning scheme for RPK instead of PSK, together with an AKE authenticated with RPK 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 small 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. 

Furthermore crypto agility is needed due to, for example, long deployment lifetimes.
 

    2. Is the problem understood and narrowly scoped?

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" and "Lightweight", followed by discussion and summary.
 
2a. AKE for OSCORE                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

At the end of the AKE the two parties should have agreed on:
- a shared secret (OSCORE Master Secret) with PFS and a good amount of randomness
- 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
- 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:
 
- IETF 6TiSCH Minimal Security [1] presented in the interim meeting [0]. The 6TiSCH Zero-Touch Secure Join [2] uses Minimal Security.

- LwM2M version 1.1 [3]. LwM2M v1.1 defines bindings to two challenging radio technologies where OSCORE will be deployed: LoRaWAN and NB-IoT, both presented at the interim [0].
 
Other industry fora which plan to use OSCORE:
- Fairhair Alliance has defined an architecture [4] which adopts OSCORE for multicast, but it is not clear whether the architecture will support unicast OSCORE.

- 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.
 
 
2b. 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:
 
* Low latency
* Low memory and code complexity
* 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 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 components that are tractable for security protocol engineering and which have a large impact. 

* 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. NB-IoT has a high per byte energy consumption component for uplink transfers, implying that those messages should be as small as possible. 

* 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. For a common 6tisch network 4-5 hops deep in a network formation setting, messages exceeding the order of 50 bytes do not fit into one frame [0]. 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 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. Data Rates 0-2 handling low coverage for this setting correspond to a packet (frame) 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.

2c. 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. An AKE providing challenge-response based mutual authentication requires at least 3 messages.

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 engineer such a solution for a particular radio technology and signature algorithm (see [6] for an example), 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.

Based on the best current practice AKE protocols and security levels used in the Internet today, certain minimum number of protocol messages and minimum sizes of messages are expected. We estimate lower bounds on messages assuming SIGMA-I, since it is 3-pass and allows traffic data after 1 roundtrip, and since SIGMA is considered a foundation for state-of-the-art AKEs. Using ECC with a security level of 128 bits, the size of ephemeral key and signature are commonly at least 32 and 64 bytes, respectively. MACs used in the constrained setting have a lower bound of 8 bytes. Applying these basic estimates on the SIGMA-I construction for an AKE authenticated with RPK:
 
Message 1: >  32 bytes
Message 2: > 104 bytes
Message 3: >  72 bytes

The corresponding estimates for an AKE authenticated with PSK are:

Message 1: > 32 bytes
Message 2: > 40 bytes
Message 3: >  8 bytes

Considering that the maximum message size for avoiding fragmentation is of the order of 50 bytes, for an RPK based AKE it is not possible to send message 2 and 3 in one frame, and not even two frames may be enough for message 2. 

Taking LoRaWAN as a benchmark, for which available frame size is at most 51 bytes, the lowest number of frames per message to hope for given the assumptions above are for PSK (1,1,1) frames, and for RPK (1,3,2) frames. 
 
2d. Summary

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

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

- The AKE should reuse COSE encrypt, sign, algorithms and key derivation for low code complexity.

- The messages should fit into as few frames as possible, ideally for PSK (1,1,1) and for RPK (1,3,2) frames of 50 bytes.


Considering the variety of deployments, we believe this is sufficiently narrow scoped to provide a performant solution in the expected use cases.

    3. Do we believe it is possible to engineer a solution?
 
Yes.
 
* A SIGMA-I based AKE can support PSK, RPK and certificate based authentication.
* Reuse of OSCORE primitives such as COSE, CBOR and CoAP gives low code complexity 
* Use of COSE algorithms gives COSE algorithm identifiers which together with a simple cipher suite negotiation with downgrade protection gives crypto agility
* PSK/RPK authentication with PFS can be achieved with (1,1,1)/(1,3,2) frames of 50 bytes:

               PSK       RPK 
=============================
message_1       40        38
message_2       45       114
message_3       11        80

(Numbers from draft-selander-ace-cose-ecdhe-13.)
 
    4. (stretch objective) Is this particular proposal a good basis for working on?
 
Yes, EDHOC was specifically designed to be a lightweight AKE for OSCORE. It complies with the requirements, and is very efficient. The CFRG crypto panel has reviewed it and formal verification has been conducted with good results. To our knowledge there is no other proposal complying with the requirements and matching in performance.


[0] https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/session/secdispatch
[1] https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security
[2] https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join
[3] http://www.openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/OMA-TS-LightweightM2M_Transport-V1_1-20180710-A.pdf
[4] 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
[5] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-13#appendix-B.4
[6] https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ


Göran


On 2019-03-11, 19:24, "Secdispatch on behalf of Benjamin Kaduk" <[e-mail] on behalf of [e-mail]> wrote:

    Hi all,
    
    Thanks to everyone who attended the interim -- I know it was not a great
    time zone for many people, but you stuck to it.
    
    My sense coming out of the session was that it's pretty clear there are
    some wide areas of applicability where EDHOC is useful and a clear
    improvement over the pure-PSK methods currently in use.  It seems like,
    in broad terms, what we're currently stumbling over is just the process
    of bringing new work to the IETF. Among other things, we evaluate proposed
    work in a broad context that includes both the present state of deployment
    (if any) in the problem space and the present state of similar protocols.
    
    In particular, publishing as Proposed Standard in the IETF RFC stream
    means (in general; there can be exceptions) that:
    
    - the IETF has change control over the technology
    
    - there is IETF consensus to produce a solution in the problem space in
      question and on what the problem space in question is
    
    - there is IETF consensus that the technology in question is a good
      solution to the problem at hand.  It need not be the perfect solution
      if the value from publishing and implementing earlier outweights the
      costs of the delay to tweak it further; similarly, if an existing
      technology can be used to meet the need then there is a higher bar for
      introducing something completely new, depending on the degree of
      similarity and the nature of the protocol in question.
    
    I am seeing several people try to assess the "good solution to the
    problem at hand" portion and run into trouble because the "problem at
    hand" was not clear enough (to them) to produce a clear answer -- we had
    several alternate solutions proposed but no consensus on whether they
    actually solve the problem at hand, largely because the "problem at hand"
    has been hard to nail down in a way that can readily be assessed.  As such,
    it may even be premature to try to tackle the "good solution to the problm
    at hand" with the current definition, which is in some ways being described
    as a pure minimization function with no cutoff for "good enough" or
    "diminishing returns".  (From a mathematical sense, it's pretty clear that
    the function thusly described has no absolute minimum, so our search would
    never terminate.)
    
    Luckily, it seems that our discussion of frame sizes and power
    consumption can point us to a clear framing of *a* problem that does
    have clear and actionable success criteria.  This need not be a "fully
    general" space (if such a thing is even possible for constrained
    devices), but if the relevant deployed base is large, even a solution
    targeted to that space would have value.  (Presumably the solution would
    still be useful in adjacent problem spaces as well, even if they were
    not explictily targetted.)
    
    As Martin noted, the standard questions we look at in BoF sessions can
    also be used to assess proposed new work outside of a BoF, and it may be
    useful to consider this work in the context of those questions:
    
    1. What is the problem we are faced with?                                           
    2. Is the problem understood and narrowly scoped?                                   
    3. Do we believe it is possible to engineer a solution?                             
    4. (stretch objective) Is this particular proposal a good basis for working on?     
    
    Thanks to everyone for continuing to work through this topic in a
    thoughtful and methodical manner.
    
    -Ben
    
    _______________________________________________
    Secdispatch mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/secdispatch