# EMU @ IETF118   {#emu--ietf118}

Notes: Janfred, MCR

# Administrivia (5 min)   {#administrivia-5-min}

# Working Group Documents (5 min)   {#working-group-documents-5-min}

## Tunnel Extensible Authentication Protocol (TEAP) Version 1 (2 min)   {#tunnel-extensible-authentication-protocol-teap-version-1-2-min}

Waiting for write-up by Paul Wouters (relevant Security AD)

## [Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)][1] (3 min)   {#forward-secrecy-for-the-extensible-authentication-protocol-method-for-authentication-and-key-agreement-eap-aka-fs-3-min}

It's in the hand of the authors, there are two things:  
One nit from IANA reviewers, promised to review things from previous
meetings.

# Non-Working group Items (50 min)   {#non-working-group-items-50-min}

## [EAP-EDHOC][2] (5 min)   {#eap-edhoc-5-min}

There was discussion about adoption in Yokohama, not much support.  
Hasn't gone anywhere.

This is a new EAP method for EDHOC. EDHOC itself was just approved and
is currently in the RFC Editor queue.

EAP-EDHOC is basically mimicking EAP-TLS. Draft is still WIP.

Asked about support, some of the supporters are in the CBOR WG right
now, there is support from people who are not present.  
Interest in automotive industry, 3GPP, ...

Chairs: We need to see support from the WG, have not seen statements of
support from the people working in this WG.

Renzo Navas: EDHOC fits nicely for EAP with IoT use cases.

Margaret Cullen: With remote participation, I want to hear from people
why they need this and why current EAP methods don't fit their needs.

Alexander: Worked on EAP over LoRaWAN, really regret that it was not the
EAP-based standard that was chosen. LoRaWAN is one case, but there are a
lot of low-power solutions popping off, important to work on this.

Göran Selander: What we are trying to do is reduce the message overhead,
which has a big impact on usability and lifetime of devices.

Chairs: Will do a Call for Adoption on the Mailing List.

## [EAP over IP][3]   {#eap-over-ip}

Hooman Bigdoli presenting. This is really MKA (MACsec Key Agreement
protocol) over IP, as the slides are actually titled.

Joe Salowey: While this WG has EAP in the name, EAPOL is part of IEEE
802.1. This WG probably won't deal with this, since we deal with
authentication. We could give it to secdispatch or we could recharter.  
Paul (AD): Initial thought was this might not be the best WG, maybe
routing dispatch, it sounds a bit like routing.  
Paul (AD hat off) You talk about "Quantum safe", but that depends on the
key agreement. Just using PSK is quantum safe, but the problem is
distributing the PSK.

Dan Harkins: Why not PANA ([RFC 5191][4])? This is EAP over UDP, should
solve your problem.

MCR: There are already several protocols that solve the problem.

MCR asks what the point of this is, and the answer was that this is to
key MPLS and some other L2.5 protocols such that they can use the MACsec
line speed hardware to encrypt these other L2 protocols, but for many of
these, they need to be able to do keying between IP/UDP end-points. Thus
MKA over UDP would make sense.

Deb Cooley: Just because you're using PSK doesn't mean you're (Quantum)
safe

## [The eap.arpa domain and EAP provisioning][5] (15 min)   {#the-eaparpa-domain-and-eap-provisioning-15-min}

Alan DeKok presenting.

Define a non-routable domain for provisioning EAP.

We need to have a domain under IETF control, that is not routable.

Suggestion: Add eap.arpa. to the arpa registry. This is fail-safe.  
Then add a new registry under eap.arpa, maybe with a designated name
space for vendor-specific

Paul Wouters (no hats): Recently we got .alt for TLS, which is
guaranteed not routable.  
Alan: Possible, but we want to have a reliable, interoperable way (with
a registry, and a pointer to RFCs).

Eliot Lear: There are a couple of differences between .arpa and .alt.
This is not so much alternate name resolution, it is a signal for a
mechanism for IETF-related protocols. It needs to have specifications,
to know what to do if you observe this domain. This is specifically for
the NAI.

Alan: Example: If the device uses dpp@eap.arpa, the server knows to
start DPP.

This draft defines the eap.arpa domain and the related registry.  
Idea: Every spec would define an identifier and what to do when you see
that identifier.

## [EAP-FIDO][6] (20 min)   {#eap-fido-20-min}

Focused on Bring-Your-Own-Device, and user can be expected to do a web
transaction to enroll their FIDO token.  
?- will DNS people accept something like
eap-fido-authentication.example.  
?- does the device have DNS access to be able to do this lookup.

Eliot: "FIDO" is vague, please be clearer about which thing you are
using.   
Alan: Historical issue is how to configure it, too difficult, so it's
good that you are simplifying things. Passkey looks way better than
passwords. A key thing is that the end-user should be able to configure
without getting it wrong.  
Margaret: Generally supportive, a previous presentation wanted to make
some changes to EAP-TLS to make this work, and maybe we need to do this,
and then use it for FIDO.  
Decided to make a new method that was EAP-TLS baked in, but as a new
method, rather than an inner EAP method.  
Haiguang Wang: what kind of credential are you using?   
Janfred: Completely dependent upon what the authenticator wants to do?  
Haiguang: Do you need to see end-user data on the server side?  
Janfred: On the server we need to have PKID access, like WebAUTHN.

MCR: Eliot, did you want it to say EAP-BANANA? Or just EAP-FIDO-XXXX?   
Eliot: EAP-FIDO-XXXX, which is the subtype of FIDO usage.

Joe: Can I use the same token with multiple services?  
Janfred: The intent is to use the same token as for multiple uses, with
some concern about cross-system systems.

Janfred: Should EMU work on this?  
Eliot: When we do these sorts of cross-organizational things, what is
important is the experts that work on FIDO authenticators are involved
in testing and writing. We need to let FIDO know about this. Are there
people to who want to join this party? We just need to make sure that
the work will be completed, and that it will get used.  
Janfred: I received some feedback from the WebAuthn WG, and they sent
some comments directly.  
Eliot: And they are on the EMU list, and they will review it?  
Deb: Do you care about revocation?  
MCR: Isn't that EAP-DIE?  
Janfred: As with passwords, you just delete the account.  
Stefan Winter: These tokens are always scoped to the specific domain, so
when you delete one, it is only for a specific usage.  
Janfred: For discoverable credentials, then deleting locally has an
issue, but for non-discoverable credentials the server is secured
storage.

Eliot: There are a suite of FIDO standards that can be used for
authentication (github, vs. ?) Are these the same standards, or?  
Stefan: The CTAPv2 wraps up this various options. "It's the banana".

ACTION: Chairs will take action to talk to FIDO.

<!-- Cursor parking spot: [] [] [] [] -->



[1]: https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
[2]: https://datatracker.ietf.org/doc/draft-ingles-eap-edhoc/
[3]: https://datatracker.ietf.org/doc/draft-hb-emu-eap-over-ip/
[4]: https://www.rfc-editor.org/rfc/rfc5191
[5]: https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa
[6]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido