-
Administrivia (chairs, 5 mins)
-
Status of EDHOC (Goran Selander, 10 mins)
-
EDHOC rekeying (Rafa Marin-Lopez & John Preuß Mattsson, 15 mins)
- RML and JPM presenting
- RML: We're defining an EAP method using EDHOC for
authentication. There we need resumption capabilities, trying to
avoid asymmetric operations. If EDHOC has a rekeying mechanism,
that could be useful to use in the EAP method.
- RML: We discussed four options on the mailing list: 1) re-run
EDHOC; 2) PSK with ECDHE; 3) PSK with random values but no
ECDHE; 4) new PSK derivation without new randomness. We don't
want (4).
- JPM: (2) and (3) eliminate all external things. (2) provides
better security than (3), which might though be fine for a short
time. An EDHOC method for rekeying can be specified as similar
to TLS resumption. Does PSK-based authentication make sense in
EDHOC other than for key update?
- JPM: It feels better if a method for rekeying with EDHOC is
defined in LAKE. This can start by registering alternative (2)
above as a new EDHOC Method 4, together with labels for deriving
the new keyign material.
-
Guidelines for EDHOC implementations (Marco Tiloca, 15 mins)
- MT presenting, was covered in London before briefly
- Idea is guidelines for implementers would be useful
- slide 3: guidance on when EDHOC sessions or derived application
keying material become invalid, and what to do then in terms of
update
- slide 4: handling new authentication credentials, guidance on
various "trust models"
- slide 5: guidance on implementation structures, considering that
the processing of an incoming EDHOC message has to temporarily
"give control" to the application in order to process
authentication credentials and consume/produce EAD items.
-
The proposal is to consider an Informational draft with such
guidance.
-
GS: wondering about TOFU bullet on slide 4, upshot is it'd be
clarified if this work goes ahead.
- MT: You still need to validate the credential under that trust
model, but if it is valid (and it can specifically mean many
things) you always trust it.
-
EDHOC EAD items (Mališa Vučinić, 5 mins)
-
MV: Clarifying about this topic raised at IETF 115.
- MV: Some applications are using EAD items. One is in LAKE about
third-party authorization for a device to join a network, based on
BRSKI concepts.
- MV: Other examples are remote attestation, and OCSP stapling done
through EAD items.
- MV: If we recharter, I'd propose a sentence mentioning work on new
EAD items.
- GS: On the stapling case, Youssef plans a draft before the cut-off.
- SF: If we enter into working on EAD items, when would we be
finished?
- MV: We can be very specific and mention in the new charter only the
three EAD items that we already have in mind today.
- GS: We can say that these are items we believe are important and
only work on them for now.
-
SF: We just can't be too open-ended.
-
Open discussion on rechartering (chairs, 10 mins)
- MCR (on chat): I support these charter changes.
- MV: Shall we move the discussion to IEF 116?
- SF: Or we have the discussion on the list.
- MV: Should we prepare a first version of the new charter?
- SF: Who is interested in working out the new proposed charter?
I'm assuming today's presenters are supportive?
- MT (on chat): Assumption confirmed :-) I support and will help
- RML (on chat): same here
- SF: We can request the slot for IETF 116. To go ahead with the
rechartering we need to see people invested in it.
-
AOB