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
