EMU @ IETF119

Notes: Janfred Rieckers

Administrative

Agenda remains unbashed.

WG Items

EAP-AKA-FS

Jari Arkko: There are some technical reasons for lifting the document
status to Internet Standard, which should be fine.

Bootstrapped TLS

Going with the downref for RFC 8773 as the timeline to making RFC 8773
(bis) a Proposed Standard within the TLS WG is unclear.

Charter Update

Porposed update posted on Github, to incorporate new work done, namely
FIDO and EDHOC.
Looking to add some deliverables in the charter.

EDHOC -> Authentication for IoT/constrained environments

EAP-FIDO -> Authentication using FIDO2

eap.arpa -> Add a .arpa domain to support EAP methods. Should we add it
to the charter?

Future WG Items

eap.arpa

Alan DeKok presenting.

EAP-NOOB specified eap-noob@arpa as username for provisioning.
The .arpa domain is a special domain, not routable, under IAB control.
Existing implementations just deal with it as if it was any other
domain.

.arpa is under IAB control, so we could register eap.arpa with them
and then use an IANA registry for usernames (left of @), with a common
space (for things like dpp@eap.arpa or portal@eap.arpa) and a vendor
specific space.

EAP-EDHOC

Göran presenting.

There was an addoption call between IETF 118 and now, committed to get
reviews from EAP and EDHOC view.

Waiting for the revised charter to finally adopt this.

There is implementation effort and interest from the industry.

There is an Hackathon in Paris in May (invitation open to everybody)
https://parishackathon.lakewg.org/

EAP-FIDO

Janfred Rieckers presenting.

One string to rule them all: "anonymous@\" This is the
answer to Tim\'s earlier question. If not configured to use discoverable
credentials, then the user would need to provide a \'username\'.

Janfred happy to have collaborators who are familiar with FIDO. Would
ideally like to ensure the user doesn't have to keep pressing the FIDO
button all the time.

Carsten's student, so would like to use CBOR, but EAP uses TLVs; not a
fan, (rather use CBOR maps) but can adjust if necessary. Still working
with Carsten on the right CBOR model.

Would be good to have link/liaison to the FIDO alliance.

Chair: We did reach out to John Bradley as far as someone with FIDO
experience to look at the document; he said yes, but hasn't happened
yet.

Alan: The operators have been complaining that the TLS provisioning is
really painful. This stuff doesn't work cross platform. It would be good
to get this.

Tim: There isn't a web identity available to the EAP supplicant. You
can't connect the identities to the FIDO system. I have lots of
experience with FIDO, this can't connect and work.
Janfred: [missed the comment]
Tim: Platforms themselves don't use CTAP2; the tokens cannot be used
silently.

Alan: Similar problems with PTP and resumption; too much load on
campuses, resolved by resumption; same thing might apply with passkeys;
if you could reuse credentials from a passkey that's been authenticated,
that would be really helpful to places such as campuses.

Tim: the problem is about bootstraping; that's a challenge; connecting a
web-tied credential to EAP.

Janfred: Silent authentication is in the CTAP2 standard, so why doesn't
that work?
Tim: Passkeys are defined in WebAuthn; there's some unfamiliarity with
the division between WebAuthn and CTAP2, with WebAuthn handling the Web
stuff, but CTAP2 handling everything else; passkey requires human
interaction to use per its standard.

Alexander Clouter: The problem with interactive vs non-interactive is
that we could bring back the PAC as a token or extend the session token.
You can enroll temporarily using passkey to get a long-lived session
token. TEAP did this with PAC.

Heikki: [missed the question] (something about splitting the protocol)

Janfred: This wouldn't work well [didn't fully grok the answer because
I missed the question]

Alan: sounds like the hardest part of this is getting access to the
credentials. TLS-???? does this and users mangle all sorts of stuff into
the supplicant to get it to work.

Chair: Would like to understand what the constraints are to know how
well this has the potential to work

Tim: biggest fear this ends up a wpa_supplicant only implementation on
Linux. What would this even look like on Linux which doesn't even have a
FIDO2/WebAuthn platform authenticator? So how would this work?

Janfred: This is valuable feedback; have a lot of material to go through
for the next revision. If you or someone else would be available to
discuss, that would be helpful.

Non-WG Items

EAP-AKA-PQC

Aritra Banerjee presenting

Jari: thanks for this, we need something like this. Happy to help on
this. Not all the details are clear.
AB: need to do updates to get to -01 draft and replace with PQ
algorithms

Chair: since this stuff is new, it would be good to get some formal
analysis of this done; the new integration of algorithms and the hybrid
design. Not necessarily a requirement, but would be helpful.
AB: Absolutely

Multiple Pre-Shared Keys (EAP-MPSK)

Speaker is Lei Yan.

Chair: Has the draft been posted to the list?
Yan: Yes, it has.
Chair: We should see if there is interest on the list; doesn't seem like
a lot of interest at this point.
Chair: Please try to follow up on the list to find more interest in this
work.