Thanks Michael. Ok, we can look at a relay out and consider moving some of the EAP motivations in section 3 earlier in the document.
And agree, I think we can do a better job of linking the use of draft-ietf-tls-external-psk-importer to identify BSKs with the EAP handshake! We can fix that up in the next draft too. Inline for more. -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Michael Richardson Sent: Tuesday 13 September 2022 12:13 To: Peter Yee <pe...@akayla.com>; emu@ietf.org Subject: Re: [Emu] Adoption call for EAP-DPP 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. [ofriel] the draft-ietf-tls-external-psk-importer external_identity is HKDF derived from the BSK public key as outlined in https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp-05#section-2.1. This is included in the ImportedIdentity struct which is serialized into PskIdentity.identity in the PSK extension, all as per draft-ietf-tls-external-psk-importer. Only a server that knows the raw/cleartext BSK public key can complete the TLS PSK handshake. Does the device get any indication that it has been plugged into the correct network? Is there any authenticatin of the Authentication Server? [ofriel] The device and server are afforded the same levels of identity guarantees and authentication as Wi-Fi DPP. The network gets a guarantee that the device connecting knows the BKS private key. The device gets a guarantee that the network knows its BSK public key. Similar to Wi-Fi Easy Connect / DPP, proof of knowledge of the BSK public key is proof of ownership of the device. 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 =- _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
