IETF 114 -- EMU

Administrivia (5 Min)

• Mohit has stepped down as Chair, we thank Mohit for his work. Peter
  is the new Co-Chair of EMU

Working Group Documents (40 Min)

TLS-based EAP types and TLS 1.3 (20 Min)

https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/

• Document seems to be good to go. No known implementation issues.

  • Some questionably implementation choices for one major
    implementation, but not a blocker

• Bunch of reviews, all addressed in the latest version.

• Ready for a Last Call.
  • Joe: Probably no need for another WGLC.

EAP-AKA' FS (20 Min)

https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/

• Protocol has been ready for some time.
• Request for WGLC

• Discussion about the encoding of P-256

  • Same encoding is used in 3GPP 5G spec
  • Given this, want to keep it this way and move forward
  • No objections in the room

• Joe: We'll start the WGLC soon.

Non-Working group Items (40 Min)

EAP-DPP (15 Min)

https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/

• Idea: Reuse the DPP mechanism to onboard devices on wired networks

• Changes from IETF 113 -04

  • Use of tls-external-psk-importer instead of tls-extensible-psks

• DPP uses TEAP and after authentication use PKCS#10 to provision the
  credentials

• Running code existent, received reviews from tls wg
• request Consensus call for WG adoption

• John Mattson: Concerned about privacy. Are bootstrapping keys used
  only once?

  • Yes, after bootstrapping the bootstrapping keys are never used
    again.

• Hazel Smith: By 'not used again' do you mean "until it needs to
  re-pair to the network" or once ever?

  • May be after reset to factory defaults, but basically a one-time
    key.

• Ira: tls-external-psk-importer is already published as RFC 9258

• Joe: Should start adoption call after this IETF.

EAP-EDHOC (15 Min)

https://datatracker.ietf.org/doc/html/draft-ingles-eap-edhoc-01

• Reviews/Comments from ML have been addressed, no major changes
  expected.
• Request Call for adoption
• Joe: Want to see more discussion on the list, also need to evaluate
  if this falls into the charter, may need to amend the charter for
  the WG. Maybe see first if there is support/interest for this draft.

EAP onboarding(10 Min)

https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/

• Presented in anima on Monday. Question if this is for anima or emu,
  there is an overlap.
• Wants to solve problem of device onboarding for BRSKI.
• First do unauthenticated EAP-TLS handshake, join a captive portal
  network, then do BRSKI
• Avoids stuffing BRSKI in EAP, instead uses existing captive portal
  infrastructure
• Something like this already in use by Hotspot 2.0

• Paul: If based on Wi-Fi Alliance, maybe IPR concerns?

  • Alan: Don't know if Wi-Fi Alliance has IPRs, but given RFC 5216
    defines unauthenticated TLS, there should not be any IPRs

• Dan: for "CA root is good enough for browsing" maybe not good to
  show you're the correct owner for a network. CAs give out certs for
  web browsing, not for onbording. If you want to reuse a cert, maybe
  come up with a better reason

  • Alan: Additional bootstrapping problem: when authenticating to a
    network, it would be good to authenticate it. CAs don't issue
    certs for onboarding or EAP, CAB Forum only allows issuing for
    HTTPS; this is a general problem.

• Bernard: Uncomfortable with eap.arpa

  • Alan: eap.arpa is a signal from the supplicant that it wants a
    captive portal network. If not using this, there might be
    confusion. "eap.arpa" is to signal 'I don't know who I am', so
    the server knows the device wants to bootstrap.

• Dan: For choosing the network: Round-robin through all visible
  networks?

  • Alan: Perhaps, also an issue for BRSKI. IEEE 802.11u allows to
    broadcast domains. eap.arpa should be advertised. Other than
    that, there is no other choice then to do round-robin.
  • Hendrik B: BRSKI has methods build in to determine which network
    to connect to. MASA-Voucher-Connection provides means to
    authenticate the network.
  • Alan: This proposal is only to get connectivity, once you have
    connectivity you can do anything you want. You should not throw
    anything in EAP.

• Jari: Is there some means/need to corellate information about the
  server to the network? (e.g., SSID example, cert for bla.com)

  • Alan: It would be good to have a channel binding.
  • In terms of Web-PKI: This is what people do now.

• Joe: What is your intention?

  • Alan: Current draft is just a line in the sand. We'll address
    the issues raised. Question: since this is intended to support
    BRSKI: Should this go to anima or emu? This draft is more EAP
    and BRSKI is just the second step you can run after the
    connectivity is there, so probably more an item for emu.

• Dan: Coming back to BRSKI, BRSKI has a mechanism to determine if you
  are in the correct network, this should resolve the issues with
  choosing the correct network. The draft could just ignore the
  authentication of the network the device connects to, BRSKI will do
  the rest.

Future of EMU (15 Min)

• We are getting through with the Charter items.
• Had some discussions on EAP in general.
• We have to make a decision up to the next IETF on what to do in EMU
  next.

• Alan: Still have another EAP document on EAP configuration.
  Something similar in the Wi-Fi Alliance.

  • Theory: Based on DNS/Webserver lookups you can get your
    EAP-Configuration (e.g., EAP-Method, CA-Certs, ...)

• Dan: Any progress for password-based EAP-Methods? EAP-PWD has
  issues, maybe define a new EAP method that uses CPACE.

• John: Alan's drafts show there is a need for more guidance for usage
  of certificates.
• Joe: Maybe need for a recharter, give it some more thought and
  discuss on the ML.
• Janfred: Heads up, there will be a new version of EAP-UTE soon; I
  did not managed to get it in before IETF 114. Happy to receive
  feedback on this.