Lightweight Authenticated Key Exchange (LAKE) - IETF 115

Time

Administrivia
-- chairs, 5 mins
draft-ietf-lake-edhoc-17 WGLC comments
-- John Preuß Mattsson & Göran Selander, 15 mins
draft-ietf-lake-traces and Hackathon report
-- Marco Tiloca, 10 mins
draft-selander-lake-authz-00
-- Göran Selander, 10 mins
OCSP stapling for EDHOC
-- Yousef AbdElKhalek, 10 mins
Guidelines for EDHOC implementations
-- Marco Tiloca, 10 mins
AOB

(Meeting starts at 16:33)

(GS presenting.)

GS (p3): v -16 made some changes that affected messages on the wire;
v -17 had some more minor changes due to the security analysis.
GS (p4): v -15 --> v -16, with details on what changed affecting
messages on the wire.
GS (p5): v -16 --> v -17, adopted feedback from security analysis;
moved key update to appendix; appendix on processing large
PLAINTEXT_2
GS (p9): summary of received WGLC comments.
GS (p10-): going through detailed issues.

On p14 (issues #347, #354)

MT, DN, JPM and MV prefer to go for the first option, i.e., remove
the ambiguous text on TH_2 and TH_3, and thus keep the test
vectors as they are now.

On p15 (issue #354)

MV: I volunteer to provide a first sketch of state machine for an
appendix.
DN: Maybe too optimistic. If the state machine in the figure is not
perfectly aligned with the specification, this will create problem.
GS: Can we give it a try with a sketch in an appendix, before
deciding to keep it or not?
SF: Yes, and we can have a quick check on the mailing list about
keeping it.

on page 16 (#347)

MT: proposal makes sense but the general rule must be updated to
exclude from "any processing" the processing of EAD items happening
out of EDHOC.

On page 17 (issue #347)

On page 18 (issue #343, #350)

SF: Let's start by adding the references. We can add more content
later on if anyone provide it in the near future.
GS: Sounds good.

On page 19 (issue #355)
(Presented by JPM.)

(MT presenting)

MT (p4): Hackathon report. Successful interop between MV and MT
implementations.
MT (p5): First time test of swapped roles. Success.
MT (p6): More tests will come outside of Hackathon as people as
progressing in their implementations.
The draft is ready for WGLC unless changes in edhoc lake with impact
on the on-the-wire content. In such case, we'll produce new test
vectors and submit a new version.
MV: Also need to validate the first trace.
MV: Time to publish?
SF: No need to rush on the publication, they're available to look at
anyway.

(GS presenting)

GS: This started in ACE, now moved here.
GS (p2-7): Explaining the whole solution. Authorized onboarding is
embedded within EDHOC key establishment. The device U to enroll is
the EDHOC initiator. The EDHOC responder V securely communicates
with an external authorization server W (e.g., over TLS). U and V
have no initial association.
GS (p8): Got a review from Marco to process; there are plans for
implementation.

(Yousef AbdElKhalek presenting.)

YA (p2-7): Explaining the whole solution. The EDHOC Initiator is a
constrained device, while the EDHOC Responder is not. The EDHOC
Initiator, when obtaining the authentication credential CRED_R of
the EDHOC Responder, wants to ensure that it is still valid. Through
an EAD item in EDHOC message_1, the EDHOC Initiator asks the EDHOC
Responder to come back with an OSCP staple. This will be specified
in an EAD item of EDHOC message_2, accompanying CRED_R. The actual
OSCP request-response occurs between the EDHOC Responder and an OSCP
Responder, on a non-constrained link.
YA (p8): Freshness is possible to achieve for the EDHOC Initiator by
circulating a nonce.
YA (p9-15): Showing workflow and example of the OSCP
request-response, and implementation/performance results.
MV: do you plan to submit as a draft?
YA: yes.

(MT presenting.)

P1: Potential new item for LAKE: considerations and guidelines for
implementors, about aspects that are out of scope for the EDHOC
specification but still practically to be considered.
P3-5: Three main areas: i) how to handle invalidation/purging of
authentication credentials and application keys; ii) different trust
models for authentication credentials; iii) detailing and guiding
the side-processing out of the core EDHOC processing (e.g.,
validation of authentication credentials and of EAD items, that can
play a role on the former).
p6: Plan for an Informational Internet Draft for LAKE. Just wanted
to bring up the topic and check if in scope and appropriate.
MV: the state machine discussed for edhoc draft may be part of this.
MT: Yes, also since any state machine in the EDHOC specification
would be limited to what I called core EDHOC processing anyway.

SF: I propose an interim meeting in December, after we request
publication of EDHOC.
SF: Let's finish the current work. Then study new items.