Subject: [Lake] LAKE background

From: Göran Selander <[email-masked]>
Date: Wed, 17 Jul 2019 13:50:08 +0000

As maybe not all people on the list are aware of the pre-history, I've compiled a small LAKE background in preparation for the BoF, complementing the information on the BoF Wiki [1]. If you have any questions, please use the mailing list so we can save time at the BoF.

1. LAKE is about specifying a lightweight authenticated key exchange protocol for OSCORE (RFC 8613).

The requirements are based on the conditions for deploying OSCORE in constrained environments (see 5. below). 

2. LAKE is not about designing a new AKE.

LAKE is about assessing which existing protocols comply with the requirements, and select one.

One key characteristic for comparing the performance of the protocol in constrained environments is protocol messages sizes. In order to make a fair comparison, all candidate proposals fulfilling the LAKE requirements need to use common assumptions (see Section 2 of [2]) when presenting message sizes (see Figure 5 of [2]). At least message sizes for PSK ECDHE and RPK ECHDE are needed for comparison.

3. A lightweight authenticated key exchange protocol for OSCORE is not a new subject in the IETF.

   * On the agenda for ACE WG F2F meetings at IETF 96, 97, 98, 99, 101, 102 and 103
   * Extensively discussed on SecDispatch mailing list Jan-June 2019, dedicated virtual interim March 5

If you have an active interest in this subject, please read up! The SecDispatch mailing list archive [3] contains answers to basic questions and pointers to the virtual interim material.

4. It is urgent to conclude on this issue.

   * There is no standard for deploying OSCORE with forward secrecy.
   * Dependent specifications have been stalled for a long time.

5. Summary of requirements.

The requirements for LAKE are summarized in Section 3 of [4]. To support the SecDispatch process, benchmarks were provided by people working with the relevant constrained network technologies where OSCORE will to be deployed: 6TiSCH, LoRaWAN and NB-IoT. One simple benchmark is the LoRaWAN 51 bytes packet size, see section 2.4.1. of [4].

Göran

[1] https://trac.tools.ietf.org/bof/trac/#LAKE
[2] https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-03
[3] https://mailarchive.ietf.org/arch/browse/secdispatch/
[4] https://tools.ietf.org/html/draft-selander-lake-reqs-01

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2019 15:09:52 +0100

Hiya,

Thanks for that background. However, I will quibble with
one part of your mail:

> requirements, and select one.
If a WG results from the BoF, then that WG might for example
adopt EDHOC as a starting point, take change control over
that and eventually turn it into an RFC. It'd be up to that
putative WG to decide what, if any, changes ought be made
along the way. That's all the usual IETF process of course,
and it'll not differ in this case.

IOW, this is about ending up with a new, standardised, AKE.
We're just not starting from a blank sheet.

Cheers,
S.

---

From: Göran Selander <[email-masked]>
Date: Wed, 17 Jul 2019 18:51:41 +0000

Hi Stephen,

On 2019-07-17, 16:10, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

Indeed, the IETF process applies, of course. Having focused for years on trying to get an AKE for OSCORE adopted, I've stopped thinking about the time after. 

Right, and the starting point is not just any non-blank sheet.

Göran

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jul 2019 17:43:11 -0400

Göran Selander <[email-masked]> wrote:
    > presenting message sizes (see Figure 5 of [2]). At least message sizes
    > for PSK ECDHE and RPK ECHDE are needed for comparison.

To add to requirements:
  I need assymmetric PKIX certificate (or reference to such, PHB's udf:
  mechanism is appealing) in one direction, and RPK in the other.

    >    * Dependent specifications have been stalled for a long time.

The only reason I will buy a LAKE that uses PSKs is because of a need for PFS.
I think, if you have pre-exchanged PSKs, that you are otherwise done.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jul 2019 15:30:25 -0700

> I think, if you have pre-exchanged PSKs, that you are otherwise done.

Hm.... Generally, you still need a protocol to do association setup,
anti-replay, etc.

-Ekr

> Lake mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lake
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jul 2019 21:28:15 -0400

Eric Rescorla <[email-masked]> wrote:
    >> The only reason I will buy a LAKE that uses PSKs is because of a need
    >> for PFS.  I think, if you have pre-exchanged PSKs, that you are
    >> otherwise done.
    >> 

    > Hm.... Generally, you still need a protocol to do association setup,

Given a session-key, OSCORE does this for us.

---

From: Göran Selander <[email-masked]>
Date: Thu, 18 Jul 2019 12:42:16 +0000

Hi Michael,

On 2019-07-17, 23:43, "Lake on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    To add to requirements:

[GS] Would you like to elaborate on the use case? How would you formulate that requirement?  "Mixed public key credentials"? 

[GS] Yes, PFS for PSK-based deployments is one reason for PSK ECDHE. Another reason which has been considered attractive is as an intermediate step in migration from PSK w/o PFS to public key based deployment (see section 2.1 of [4]).

Göran

---

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Jul 2019 22:11:11 -0400

>> for PSK ECDHE and RPK ECHDE are needed for comparison.
    
    mcr>     To add to requirements: I need assymmetric PKIX certificate (or
    mcr> reference to such, PHB's udf: mechanism is appealing) in one direction,
    mcr> and RPK in the other.

    > [GS] Would you like to elaborate on the use case? How would you
    > formulate that requirement?  "Mixed public key credentials"?

The use case is for constrained bootstrapping (BRSKI for 6tisch).
I would be happy to say a lot more, but essentially, I want RPK, and I want
certificates, and I want them together.

A way to "send" the certificate by reference, in a privacy preserving way is
sought.  Of course, this mechanism could be applied to other AKEs as well.
Using PHB's UDF https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/
would work.
        
-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [