+1 to all of this. I'll add some notes to the eap.arpa document to raise issues brought up here:
* EAP type selection can be done by examining the provisioning NAI * NAKs should be handled specially for provisioning NAIs * There is no method to NAK a particular kind of provisioning. e.g. if the supplicant asks for f...@teap.eap.arpa, there is no way for the peer to reply with "no, but I do support b...@teap.eap.arpa" Perhaps the best approach there is to simply require that each EAP method provide for in-band signalling of errors. For example, TEAP could provide a TLV which gives a list of supported provisioning methods. > On Sep 27, 2024, at 5:32 PM, Heikki Vatiainen <h...@radiatorsoftware.com> > wrote: > > 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? > > 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'? > > 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" SHOULD be used. Based on > draft-ietf-emu-eap-arpa-02, I'd expect something like > "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" would require a NAK to walk through the > different methods, whereas "tls-pok-...@teap.eap.arpa" and > "tls-pok-...@ttls.eap.arpa" would allow the server to immediately select the > client's desired EAP method. > > -- > Heikki Vatiainen > h...@radiatorsoftware.com > _______________________________________________ > Emu mailing list -- emu@ietf.org > To unsubscribe send an email to emu-le...@ietf.org _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
