Subject: Re: [Lake] 1 week 2nd WGLC on requirements and scoping text

From: "Eduardo Ingles (UM)" <[email-masked]>
Date: Mon, 1 Jun 2020 09:51:27 +0200

Hi Stephen,

I'm happy with this text.
I support the working group moving forward.

Regards,
Eduardo Inglés.

El 24/05/2020 a las 23:07, Stephen Farrell escribió:
> Hi all,
>
> First: my apologies for taking so long on this. (I got
> sidetracked by an unexpected project.)
>
> ISTM we have pretty good, if rough, consensus on enough of
> the text to proceed, but with one important part that needs
> checking. (See below.)
>
> I'd like to start a 1 week 2nd WGLC with the main focus
> being to establish whether we have rough consensus on the
> scoping text below. (Which can be see in context at [2].)
> That text was the main outcome of our virtual meeting last
> month.
>
> So, please send mail to the list saying if you are happy
> enough to proceed on this basis. If you are not, then I'd
> appreciate if you could suggest alternate text with as
> few changes as possible.
>
> This 2nd WGLC closes on June 1st. If I see rough
> consensus to proceed at that point, I'll plan to start a
> call for adoption for the edhoc draft. If not, we'll have
> to discuss how to proceed with our AD, as I think that
> would mean that the WG is very badly stuck.
>
> The scoping text added was:
>
>     As illustrated above, the setting is much more diverse
>     in terms of credentials and trust anchors than that of
>     the unconstrained web.  In order to deliver a timely
>     result, there is a need to initially focus on what is
>     considered most important at the time of writing: RPK
>     (by reference and value) and certificate by reference.
>     Information about validity of a certificate may be
>     omitted from the AKE if available over unconstrained
>     links.  The case of transporting certificate validation
>     information over the AKE may be specified in the initial
>     phase if there is a lightweight solution that matches
>     existing standards and tools.
>
>     A subsequent extension beyond the initial focus may be
>     inevitable to maintain a homogenous deployment without
>     having to implement a mix of AKE protocols, for example,
>     to support the migration path described above.  The AKE
>     needs to make clear the scope of cases analysed in the
>     initial phase, and that a new analysis is required for
>     additional cases.
>
> Thanks,
> Stephen.
>
> [1] https://tools.ietf.org/html/draft-ietf-lake-reqs-03
> [2] https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2.1
>
>
-- 
Eduardo Inglés Sánchez
[email-masked]

Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain

---

From: Ivaylo Petrov <[email-masked]>
Date: Mon, 1 Jun 2020 14:13:03 +0200

Hello Stephen,

I am also happy with this text and I support the working group moving
forward in the proposed way.

Best regards,
Ivaylo

On Mon, Jun 1, 2020 at 9:51 AM Eduardo Ingles (UM) <[email-masked]>
wrote:

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

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 1 Jun 2020 17:30:58 +0200

(chair hat off)

The scoping text fits the zero-touch network access use case we’ve been working on as a follow up work of the 6TiSCH protocol suite, documented at [1]. Therefore, I support it being adopted by LAKE.

Mališa

[1] https://datatracker.ietf.org/doc/draft-selander-ace-ake-authz/

> On 24 May 2020, at 23:07, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi all,
> 
> <0x5AB2FAF17B172BEA.asc>-- 
> Lake mailing list
> [email-masked]

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 1 Jun 2020 18:50:41 +0200

Hi Stephen,

I am also happy with this text. I support the WG moving forward.

Best,
/Marco

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Michael Richardson <[email-masked]>
Date: Mon, 1 Jun 2020 15:27:23 -0400

> sidetracked by an unexpected project.)

..

>     existing standards and tools.

Hi, RPK by value and certificate by reference are precisely this use 
case that comes from 6tisch/zerotouch constrained enrollment.
It is on the 802.15.4 links that the interop events I was part of in 
2019 experienced significant challenges with other AKEs.

---

From: Shahid Raza <[email-masked]>
Date: Mon, 1 Jun 2020 23:21:58 +0200

Hi Stephen,

I also support this requirement document go forward. I work on lightweight
PKI for IoT (enrollment, CBOR certs, and to-be-submitted revocation), and
plan to integrate our work with  the proposed LAKE solutions.

Best,
Shahid Raza
Head of Cybersecurity @ RISE
Associate Professor, Uppsala University

On Mon, 1 Jun 2020 at 14:13, Ivaylo Petrov <[email-masked]> wrote:

>> Eduardo Inglés Sánchezeduardo.ingles@um..es <[email-masked]>
>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Jun 2020 18:18:37 -0700

>    initial phase, and that a new analysis is required for

Stephen

It's not clear how to read this in the context of other parts of
the document, for instance:
https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2
which says:

   In order to allow for these different schemes, the AKE must support
   PSK- (shared between two nodes), RPK- and certificate-based
   authentication.  These are also the schemes for which CoAP is
   designed (see Section 9 of [RFC7252]
<https://tools.ietf.org/html/rfc7252#section-9>).

How is one supposed to interpret this text?

-Ekr

---

From: Göran Selander <[email-masked]>
Date: Tue, 2 Jun 2020 07:15:27 +0000

From: Lake <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Tuesday, 2 June 2020 at 03:19
To: Stephen Farrell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lake] 1 week 2nd WGLC on requirements and scoping text

On Sun, May 24, 2020 at 2:08 PM Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Stephen

It's not clear how to read this in the context of other parts of
the document, for instance: https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2
which says:

   designed (see Section 9 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-9>).

[GS] Since OSCORE is an extension to CoAP it is expected to support the schemes for which CoAP is designed. But in the discussion following the virtual IETF 107 LAKE WG meeting we restricted the initial focus, leading to the addition of section 2.2.1 and the following text in the paragraph after the one you quoted:

”In order to provide a clear initial effort, Section 2.2.1<https://www.ietf.org/id/draft-ietf-lake-reqs-03.html#initial-focus> lists a set of credential types of immediate relevance; the mechanism for selecting credential scheme is presumed to enable future extensibility if needed.”

The ability to extend beyond the initial focus is also repeated in the text from Section 2.2.1 which Stephen quoted in his mail:

”A subsequent extension beyond the initial focus may be inevitable to maintain a homogenous deployment without having to implement a mix of AKE protocols, for example, to support the migration path described above.”

It seems to me that the working group has a sufficient good understanding and support for where to start this work and to allow for extensibility, so I propose we do just that.

We may in parallel make clarifications to the requirements as needed. In fact, I expect we will revisit the requirements throughout the work as more insights are gained, potential inconsistencies discovered, etc., but that should not stop us from moving the work forward now.

Göran

-Ekr

Thanks,
Stephen.

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 Jun 2020 05:44:55 -0700

On Tue, Jun 2, 2020 at 12:15 AM Göran Selander <[email-masked]>
wrote:

>
>
>
>
> *From: *Lake <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> *Date: *Tuesday, 2 June 2020 at 03:19
> *To: *Stephen Farrell <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Lake] 1 week 2nd WGLC on requirements and scoping text
>
>
>
>
>
>
>
>    designed (see Section 9 of [RFC7252] <https://tools.ietf.org/html/rfc7252#section-9>).
>
> ”In order to provide a clear initial effort, Section 2.2.1
> <https://www.ietf.org/id/draft-ietf-lake-reqs-03.html#initial-focus>
> lists a set of credential types of immediate relevance; the mechanism for
> selecting credential scheme is presumed to enable future extensibility if
> needed.”
>
>
>
> The ability to extend beyond the initial focus is also repeated in the text
> from Section 2.2.1 which Stephen quoted in his mail:
>
>
>
> ”A subsequent extension beyond the initial focus may be inevitable to
> maintain a homogenous deployment without having to implement a mix of AKE
> protocols, for example, to support the migration path described above.”
>

Yes, my point is that these three paragraphs together contradict each
other. One says the AKE MUST support PSK and the other says it's not part
of the initial focus. Does that mean that the AKE as published will or will
not support PSK?

-Ekr