Hello,
On 10/5/24 10:21 AM, Owen Friel (ofriel) wrote:
*From:*Heikki Vatiainen <h...@radiatorsoftware.com>
*Sent:* Friday, September 27, 2024 10:33 PM
*To:* EMU WG <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.
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.
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" 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.
[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
--
"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
