# 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