Reviewed NOTE WELL, Code of Conduct, and Meeting Tips.
https://datatracker.ietf.org/meeting/123/materials/slides-123-emu-eap-edhoc-00
Alan: TEAP has provisions for channel bindings too, but I do not think
they are ever used. No problem leaving them there.
Peter: Look forward to an updated draft.
https://datatracker.ietf.org/meeting/123/materials/slides-123-emu-eap-ppt-update-ietf123-00
Joe: Charter was updated to accommodate the document
Peter: Any implementations?
Bart: Yes
Heikki: Will hybrid algorithms be supported?
Aritra: No.
Heikki: Things are too big.
Aritra: Please look in the newer RFC.
Heikki: Can you make a reference implementation available?
Aritra: I will take a look. No promises.
https://datatracker.ietf.org/meeting/123/materials/slides-123-emu-teapv2-00
Dan: Don't you want to bind to the keys generated by inner EAP method?
Alan: Want to always do crypto binding.
Joe: Things that are just TLVs don't need to be bound.
Alan: Seems better to have binding associated with every round.
Russ: Exporter is not defined for all versions of TLS. Do you intend to
limit it here?
Alan: Yes. TLS 1.3 or later.
Uri: MSK and EMSK cannot both be zero. Just use them together.
Tiru: Any reason to use the TLS Exporter? That's used for TLS data
encryption. Here, it's basicallly just used like HMAC to derive keys.
Why bother with using the TLS Exporter?
Alan: If we don't use Exporter, we would have to define something
ourselves. Want to avoid that.
Tiru: TLS Exporter uses HKDF, which is commonly found in crypto
libraries. Just use that.
Michael: Have code for a long time. It will take a long time to get all
of that legacy code updated. Would like to document TEAPv1 to make it
clear what was done, and define TEAPv2 as the consensus version.
Alan: Yes, and TEAPv2 is limiting the inner methods.
Uri: Microsoft is the server everyone interoperates with. Document the
way that one works.
Alan: Other server implementations did different things for crypto
bindings.
Eliot: Need to ensure that the non-EAP method examples listed in the v2
for MSK derivation are noted as just examples and not an exhaustive
list. Perhaps discuss policy for how new TLVs should describe MSK
generation.
Dan: Not all inner rounds are EAP Methods. Use a different term.
Hannes: Not all EAP Methods get enough attention.
Valery: IKEv2 already has support for EAP authentication.
Uri: Yes. However, it is more efficient to use PQuAKE without the EAP
wrapper in the IKEv2 protocol.
Joe: How much overhead?
Uri: Want it available in as many protocols as possible.
Guilin: Question about authentication in PQuAKE.
Uri: Cannot arrive at same value unless the transcripts match, so
authentication is provided. Possession of the private key is
demonstrated.
Hannes: Need this to be defined at its own EAP Method (not part of
EDHOC).
Uri: Works with constrained devices, but if these small devices have a
lot of memory, it is possible to make improvements.
Hannes: EAP is not used in all radio environments.
Uri: Design is optimized for radio environments.
Eliot: Goal is to let the yet-to-be-enrolled device get connected to the
network to do enrollment.
Michael: Yes, that is right.
Eliot: Nervious about approach. Mixing L2 and L3. Can already be done
with MAC address bypass.
Michael: With randomized MAC addresses, MAC address bypass does not
work. Staging networks can be used.
Gaetan: Goal is to get you to an onboarding service.
Michael: Onboarding does not fit in EAP. This gives L2 encryption.
Gaetan: Want encryption too, but the onboarding service runs TLS.
Michael: Are there objections to this approach?
Gaetan: Call in anonymous encrypted access.
https://datatracker.ietf.org/meeting/123/materials/slides-123-emu-dhcp-options-for-teap-00
Gaetan: Does the local relay have the ability to override the
configuration?
Alan: No. The AAA Service would be able to tell that you are on a remote
network, not your usual home.
Joe: Complex. Can be conflicts in the remote and local policies.
Alan: Yes, this needs to be worked out.
Eliot: YANG model for DHCP options could be done to help sort this out,
but that's a lot of work. The binary doesn't require a data model.
Hannes: Some DHCP information is session specific or user specific, but
other DHCP information is more global.
Alan: Some sort of registry might be needed to indicate which DHCP
options should be used here.
Joe: How many people in the room have read the document?
Few people had read the document.
Uri: The concern is CAs supporting these algorithms in certificates.
Tiru: There is a big migration needed.
Hannes: Need this done sooner than later.
John: MTI belongs in the TLS WG.
Uri: Transitions take much longer than people expect.
Tiru: Need to get started.