I have read draft-friel-tls-eap-dpp-05. I have no objection to the WG working on such a thing, but I think that there is actually quite a lot of work left to do.
I think that the section 3, which explains the EAP connection (and the motivation for the work) should probably come before the extension and the cryptographic explanation! I find the document quite weak even in section 3. I think that the EAP server (Authentication Server) is meant to use the OOB public key to authenticate the new device. I'm rather vague as to how the Authentication Server knows what identity to use to look the public key up, and how the privacy of this identity is preserved. Does the device get any indication that it has been plugged into the correct network? Is there any authenticatin of the Authentication Server? While I acknowledge you are not trying to implement BRSKI (RFC8995) or SZTP (RFC8572), it would be good if your Security Considerations addressed some of the same issues that those documents deal with. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
