EMU WG @ IETF 109

Administrivia

• slides = https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-chair-slides-00

Chairs and document authors provided status.

TLS Proof of Knowledge

• Owen Friel, Dan Harkins
• https://tools.ietf.org/html/draft-friel-tls-eap-dpp-01

• slides = https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-eap-dpp-00

• Salowey: draft-jhoyla-tls-extended-key-schedule is not adopted by TLS WG yet

• Q: Salowey: do you see use of this outside of DPP and EAP?
• Friel: on-boarding to wired networks too
• Lear: extensions shouldn't excluded other than EMU
• Friel: this design could influence how these drafts are written
• Kaduk: could threshold crypto be used instead of a standard public/private key pair?
• Friel: we haven't looked at threshold crypto, since we are looking at the DPP key
• Harkins: not sure if threshold crypto would work, but it might be interesting
• Harkins: if Hoyland draft is not adopted in TLS WG, the TLS WG will adopt something that will allow injection of additional material in the key schedule
• Friel: also looked at draft-ietf-tls-hybrid-design-01 as an alternative, but Hoyland draft looked simplier
• McDonald (via chat): suggest keeping TLS extensions in TLS WG to ensure review by SMEs
• Rieckers (Via chat): will the server authenticate against the client?
• Friel: DPP does allow mutual, but this draft only does it one way
• Hannes: can you not use the raw public key out of the box?
• Friel: limitations from DPP
• Salowey (WG chair): To post to list to get discussion on the draft
• Poll: Is this topic something EMU should work on?
• 29 participants; 11 in favour; 3 against
• no one against came to the mic

Use Identity as Raw Public Key in EAP-TLS (EAP-TLS-IBS)

• Meiling Chen
• https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/
• slides = https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-eap-tls-ibs-00
• Salowey: no modifications to way TLS flows, is that true? Any new extensions?
• Chen: extension is in RFC 6507. Something is also submitted in TLS WG
• Hannes: what is your deployment environment?
• Chen: long-lived passive IoT devices
• Housley (via chat): is this leveraging draft-huang-tls-ibe?
• Chen: I only use IBS, not IBE
• Hannes (via chat): is there running code?
• Chen: yes, in our internal EAP-TLS 1.2 code
• Mohit: To have more discussion on the mailing list

TEAP Errata

• Salowey
• https://github.com/emu-wg/teap-errata/pulls
• slides = https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-chair-slides/
• Errata 5765
• Mohit: is this optional because doc says all outer TLVs are optional?
• Salowey: correct
• Mohit & Vergara agree with optional
• Errata 5767
• Mohit: what is an EAP-Identity method?
• Salowey: contains an NAI for routing
• Mohit: "EAP method" means EAP authentication method. Might make sense to change EAP-Identity method
• Salowey: in general, people know what this means. Not necessary to fix this in other places--not in scope for errata.
• Errata 5767
• Salowey: editorial, so only address if not in many places
• Mohit: makes sense. Will look into it.
• Errata 5775 (GitHub #11)
• Salowey: to make the crypto binding more clear
• Salowey: Oleg Pekar has reviewed the changes
• Vergara (via chat): I reviewed the changes, no additional comments.
• Pekar: it was decided not to introduce the flag to indicate zero-key is present? No way to use 0-MSK. 0-MSK follows from specification of inner message. Perhaps explicitly make this clear to implementers.
• Salowey: please add such a sentence (Section 5.2?).
• Salowey: intension is that if a method generates an MSK, then it should be used.
• Errata 5844 (GitHub #19, #22)
• Salowey: straightforward. Errors in the specification.
• Pekar: looks clear
• Salowey: one open issue to wrap up
• Vergara: sent a message to list on 5768. Compatibility concerns based on the 20 octet length. Requires increase in version of TLV
• Salowey: increasing version of CryptoBinding TLV requires document update. Let's make sure what implementations are doing.
• Lear: thanks to Joe, Jorge and Oleg. We should now unstick the TEEP update.
• Salowey: implementation is key to avoiding issues
• Danyliw (AD): no more needed. GitHub use is great.

EAP-NOOB update

• Mohit Sethi
• https://tools.ietf.org/html/draft-ietf-emu-eap-noob-02
• slides = https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-eap-noob-00
• authors believe it is ready for WG last call
• Salowey (WG Chair): any objections to keeping everything in JSON vs switching to CBOR?
• no objections

EAP-EDHOC

• Eduardo Ingles
• https://datatracker.ietf.org/doc/draft-ingles-eap-edhoc/
• slides = https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-eap-edhoc-00
• Mohit: EDHOC is a three message protocol, but we have a fourth message.
• Ingles: The EAP server can be the Responder but the encrypted data would have to be sent from the fourth EAP Response message
• John Mattsson: there are privacy implications with who sends what. Reducing to three messages here changes this.
• Mohit: current flow may be better then, to protect the privacy of the peer
• Mohit (WG chair): might be too early to adopt given the status of EDHOC
• Mattsson: I support this draft, but it might be too early. EDHOC is adopted by LAKE, but we would have to wait until LAKE publishes it.
• WG Chairs: revisit at next IETF