EMU WG @ IETF 109
- slides = https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-chair-slides-00
Chairs and document authors provided status.
TLS Proof of Knowledge
Use Identity as Raw Public Key in EAP-TLS (EAP-TLS-IBS)
- Meiling Chen
- 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
- 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.
- Mohit Sethi
- 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?
- Eduardo Ingles
- 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