Subject: [Secdispatch] FW: New Version Notification for draft-selander-lake-reqs-00.txt

From: Göran Selander <[email-masked]>
Date: Fri, 12 Apr 2019 16:20:28 +0000

On request I compiled the requirements for the lightweight AKE for OSCORE discussed on the list into a draft. This is not exactly the formulation by the security ADs but the main requirements should be there.

Göran

On 2019-04-12, 16:20, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-selander-lake-reqs-00.txt
    has been successfully submitted by Göran Selander and posted to the
    IETF repository.
    
    Name:		draft-selander-lake-reqs
    Revision:	00
    Title:		Requirements for a Lightweight AKE for OSCORE.
    Document date:	2019-04-12
    Group:		Individual Submission
    Pages:		7
    URL:            https://www.ietf.org/internet-drafts/draft-selander-lake-reqs-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-selander-lake-reqs/
    Htmlized:       https://tools.ietf.org/html/draft-selander-lake-reqs-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-selander-lake-reqs

    Abstract:
       This document contains the requirements for a lightweight
       authenticated key exchange protocol for OSCORE.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

---

From: Rene Struik <[email-masked]>
Date: Mon, 15 Apr 2019 14:38:33 -0400

Dear Goran:

Some brief remarks on draft-selander-lake-reqs:
a) duty cycle (see Section 4.2.1 - LoRaWaN):
Duty cycle depends on context (e.g., duty cycle during Tx of a single 
frame is always 100%). According to ETSI [1], Section 5.4.1, duty cycle 
is relative to observation time window (Tobs) of 1 hour, where 
conformance ([1], Section 5.4.2), is defined relative to normal use 
during operational lifetime, where "the representative period shall be 
the most active one in normal use of the device. As a guide "Normal use" 
is considered as representing the behaviour of the device during 
transmission of 99 % of transmissions generated during its operational 
lifetime", and where "Procedures such as setup, commissioning and 
maintenance are not considered part of normal operation". This does 
suggest that inter-frame spacing is not necessarily 99 frames for each 
frame sent, as this section seems to claim. In fact, if key agreement is 
only done as part of network formation, it falls outside the duty cycle 
regulatory requirement.
b) few messages/few frames (Section 4.2 - Discussion):
The suggestion that a 3-message protocol is a requirement seems to be 
more an opinion/preference by the author, since lacking detailed 
technical justification. {If sending an additional frame causes "the 
probability of errors [to] increase exponentially", the medium access 
control layer seems to be unfit for use. Or, do you mean that if error 
probability is p, one gets prob no error in t frames equals (1-p)^t? If 
so, with small p with viable networks and small t, one definitely has 
(1-p)^t ~ 1 - t*p (i.e., almost linear degradation rather than the more 
dramatically sounding exponential).}
c) conflicting requirements (Section 4.1 - AKE for OSCORE vs. Section 
4.2 - Lightweight):
There are trade-offs between communication overhead and security 
properties, which generally should be explored in more detail before 
imposing a requirement. As an example, a strict requirement for PFS may 
necessitate increased communication overhead, since, e.g., a 
communication failure during an AKC-scheme with strict PFS may preclude 
reusing this keying material with a retry mechanism.
d) security considerations (Section 6):
Contrary to what is suggested, the document is mostly about "size" 
arguments and does not offer a definition of desired algorithmic and 
operational security properties for sensor networks.
e) protocol flavors (Section 2):
The suggested protocol options include authenticated key agreement using 
symmetric-key, raw public keys, and certified public keys. Another 
option, which may be worth exploring (even if discarded based on sound 
rationale) is a key agreement scheme where authentication is based on a 
short secret authentication string (password) or a short public 
authentic, yet not secret string that is provided by a user (see, e.g., 
[3]).
f) COSE algorithms (Section 4.1):
The algorithms in the current COSE specification (RFC 8152) may not have 
a rich enough set of primitives to instantiate the sought after 
authenticated key agreement protocol. As an example, to my 
understanding, COSE only facilitates use of static-ephemeral co-factor 
Diffie-Hellman. Thus, some changes to the COSE specification may be 
required if one wishes to use a protocol that uses co-factor 
Diffie-Hellman based on ephemeral key shares. (Of course, this may be 
easily facilitated, esp. if the underlying core crypto primitive is 
already defined).

These comments illustrate that some requirements are less clear-cut than 
as suggested in draft-selander-lake-reqs-00 and, that, in fact, there 
may be more to this than just a "smaller is always better" argument.

Rene

Ref:
[1] ETSI EN 300 220-1 V3.1.1 (2017-02);
[2] ETSI EN 300 220-2 V3.1.1 (2017-02);
[3] Authenticated Key Agreement - Using Short Authenticated Strings 
(Serge Vaudenay, Crypto 2005)

On 4/12/2019 12:20 PM, Göran Selander wrote:
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Göran Selander <[email-masked]>
Date: Tue, 16 Apr 2019 13:08:12 +0000

Hi Rene,

Please find responses inline. 

On 2019-04-15, 20:39, "Rene Struik" <[email-masked]> wrote:

    Dear Goran:

Two applications of EDHOC in the context of LoRaWAN were mentioned at the interim meeting. One is for the rekeying of LoRaWAN  AppKey, the other is for end-to-end security on application layer between device and cloud service, where LoRaWAN is the last hop. In both cases the message sizes over the LoRaWAN link are relevant for the performance. While the first case may be exempted, the second is independent of network formation. I will make this more clear in -01.

For NB-IoT, the performance characteristics are not sensitive to the distribution of content into frames, but the time until encrypted traffic data can be sent is highly dependent on the number of roundtrips for completing the protocol. Therefore as few roundtrips as possible is important. The error probability is related to properties of slotted Aloha used by 6TiSCH, but is not critical for the argument so instead of going into details I will remove it in -01.

I didn't really understand this comment, in particular the last sentence. OSCORE is not required to be deployed with PFS, but there are applications were PFS is needed and the increased communication overhead of an AKE is acceptable.

I will reformulate the sentence of this section in -01.

Other credentials may be added later in the process, the ones currently listed are believed to be the most relevant.

From a COSE point the EDHOC use of DH is Static-Static, but, as you remark, this can easily be added to COSE should that assumption change. 

The intent with this draft was not to write a very detailed requirements specification that one day will become an RFC. Its purpose was to meet a request to compile discussion spread out over different emails, including some general metrics which are expected to have a positive impact on the performance in common settings. 

Göran

    Rene
    
    Ref: