From: Dan Harkins <dhark...@lounge.org> Sent: Sunday, October 6, 2024 4:17 PM To: Owen Friel (ofriel) <ofr...@cisco.com>; Heikki Vatiainen <h...@radiatorsoftware.com>; EMU WG <emu@ietf.org> Subject: Re: [Emu] draft-ietf-emu-bootstrapped-tls-06 notes
Hello, On 10/5/24 10:21 AM, Owen Friel (ofriel) wrote: From: Heikki Vatiainen <h...@radiatorsoftware.com><mailto:h...@radiatorsoftware.com> Sent: Friday, September 27, 2024 10:33 PM To: EMU WG <emu@ietf.org><mailto:emu@ietf.org> Subject: [Emu] draft-ietf-emu-bootstrapped-tls-06 notes draft-ietf-emu-bootstrapped-tls-06 is clearly written. I've mainly worked on EAP server side implementations and I think the document describes the TLS-POK handshake, and how to prepare for it, clearly enough. A couple of notes follow: TLS based EAP methods +++++++++++++++++++ My understanding is that the document applies to any TLS based EAP method. Instead of using a method's usual TLS 1.3 handshake, the TLS-POK handshake is used. It's not explicitly said, but I presume all outer TLVs, etc. are unchanged. TEAP seems to be the main target of the draft. Are there any TLS based EAP methods that shouldn't be used? [ofriel] That is a good question. TEAP was the only method we had been thinking about. Dan – are there any EAP TLS methods we shouldn’t use or what explicit statements should we make here e.g. TLS1.3 EAP method and not say RFC5216 ? Well, this is for bootstrapping only. The implication is that there will be some provisioning step that will enable network connectivity being performed after successful bootstrapping. TEAP can do a PKCS10/PKCS7 exchange to provision a certificate on the device for subsequent connections and therefore it was the only one considered. I'm not aware of other EAP methods that can provision network credentials on a supplicant that would work with this method of bootstrapping. [ofriel] Ok, so I will add some text about provisioning steps, and TEAP currently being the only suitable EAP mechanism for this. Use with wireless networks +++++++++++++++++++++ The document recommends using TLS-POK with wired networks. Could the document be clearer about potential problems if used with wireless networks? For example, security considerations describes an adversary scanning QR codes and forcing connections from clients. Is this one of problems? For example, if the client would need to do round-robin, as described in the introduction, to find the provisioning network, it could be easy for an adversary to create such a WLAN. Should there be a clear upper case key word instead of lower case 'recommended'? [ofriel] The document recommends DPP for wireless, but the same security consideration exists for wireless using DPP too. If an adversary scans the QR, then the adversary can get the client to onboard against and trust their rogue network. Dan – what text do you suggest here for potential problems if used with wireless? The obvious reason is already stated in section 1 i.e. the “document does not address the problem of Wi-Fi network discovery”. Discovery on wi-fi is not an issue, DPP has solved that with chirping. Regarding the security considerations, this is addressed in the Resurrecting Duckling paper which we reference in the draft. [ofriel] Yep fully aware of that. So – Dan / Heikki – to clarify this do we just reiterate in the doc that it is not recommended for wireless as this draft does not address wi-fi discovery, hence is not a full solution for wi-fi? Or is it as simple as you suggest Heikki and change the two ‘recommended’ here in section 1 “Thus, the intention is that DPP is the recommended mechanism for bootstrapping against Wi-Fi networks, and TLS-POK is the recommended mechanism for bootstrapping against wired networks.” to ‘RECOMMENDED’ ? regards, Dan. Thinking from authentication server point of view; the auth server may not always be aware of client's connectivity (wireless vs wired). Therefore it seems the client must make the correct decision because it could be harder on the authentication server side. Use of EAP Identity +++++++++++++++ The document says "anonym...@tls-pok-dpp.eap.arpa<mailto:anonym...@tls-pok-dpp.eap.arpa>" SHOULD be used. Based on draft-ietf-emu-eap-arpa-02, I'd expect something like "tls-pok-...@teap.eap.arpa<mailto:tls-pok-...@teap.eap.arpa>" to match the example EAP exchange in section '4. Using TLS Bootstrapping in EAP'. draft-ietf-emu-eap-arpa-02 recommends against username 'anonymous' and mandates that the realm part uses an IANA registered EAP type name. Is this a conflict between the drafts? EAP method negotiation ++++++++++++++++++ Section '4. Using TLS Bootstrapping in EAP' says: This identifier MUST be included in the EAP Identity response in order to indicate to the Authenticator that an EAP method that supports TLS-POK SHOULD be started. This doesn't give any hint which EAP method the client wants. Is EAP method negotiation with EAP NAK supported? For example, is there a possibility that the client supports multiple EAP methods and it wants to get provisioned with method specific credentials? One option is to provision once for all methods, which would solve this. If the server supports multiple methods for EAP-POK, then it could choose a wrong one and the client would need a NAK to switch to its desired method. If provisioning requires use of multiple EAP methods, "anonym...@tls-pok-dpp.eap.arpa<mailto:anonym...@tls-pok-dpp.eap.arpa>" would require a NAK to walk through the different methods, whereas "tls-pok-...@teap.eap.arpa<mailto:tls-pok-...@teap.eap.arpa>" and "tls-pok-...@ttls.eap.arpa<mailto:tls-pok-...@ttls.eap.arpa>" would allow the server to immediately select the client's desired EAP method. [ofriel] Alan says he will have draft-ietf-emu-eap-arpa-03 out next week that will clarify the above. I will wait to review that and then update bootstrapped-tls accordingly. -- Heikki Vatiainen h...@radiatorsoftware.com<mailto:h...@radiatorsoftware.com> -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
