Hi Alan,
On 7/27/21 10:50 AM, Alan DeKok wrote:
On Jul 27, 2021, at 1:23 PM, Owen Friel (ofriel) <[email protected]> wrote:
[ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer
identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted Server
Root, PKCS#7 TLVs.
That presumes everyone uses TEAP, all of the time. This is likely to not be
the case for a while, if ever.
Well that's what we're trying to address. Making something more useful
is a goal and the fact that currently that thing isn't quite as useful as
it could/should be shouldn't be a reason not to make it more useful.
TEAP also has the issue of bootstrapping. RFC 7170 Section 3.8.3 described
an unauthenticated provisioning mode, but suggests that Phase 2 still has
mutual authentication. It's not clear how the parties can identify each other
in that case. The document appears to be silent on the topic.
I think you're reading a bit too much into "provisioning mode" here.
There
was never an intention in TEAP to allow for the PKCS10/PKCS7 exchange to be
done after an anonymous Phase 1. The anonymous Phase 1 was used to get a
tunnel up in order to facilitate an exchange would would make the TEAP
connection
be mutually authenticated. The text in 3.8.3 implies that Phase 2 always
follows
an unauthenticated Phase 1 and Phase 2 MUST be mutually authenticated.
An RA (which is what the server is acting as on behalf of a CA) needs to
authenticate the user before it passes the CSR off, that's (part of) the
service it's providing. Otherwise we'd end up with Kevin Mitnick getting
a certificate in the name of "[email protected]". That would not
be a trustworthy CA and it's certificates would be useless garbage.
So the "this topic" you're alluding to is not really what 3.8.3 was
talking
about.
This draft solves that issue, among others.
For example, what about the use-case of Eduroam? 10,000 students show up to a
university which uses a private CA. Assuming that all of the devices support TEAP,
they are still unable to perform "mutual authentication, and TEAP becomes ToFU.
Similarly, DPP may work, but that requires creation and distribution of new keys
In contrast, the user work flow here is "connect to Eduroam, log in with your
username and password". It really can't get simpler than that.
*That* use case can't get any simpler. The 10,000 students can enter
their
username/password on their 10,000 laptops. That's not what DPP or TLS-pok is
dealing with. It's 10,000 sensors with no practical user interface. Eduroam
doesn't work for 10,000 sensors with no practical user interface.
The first stage of this proposal requires no changes to existing
supplicants. A simple client-side utility can perform the requisite actions,
and configure the supplicant. Running code is available:
https://networkradius.github.io/automatic-eap/
The core of the work is a ~300 line Python script. OS vendors could ship
this today. Network administrators could add a few records to DNS/WWW.
Getting EAP connectivity then becomes trivial. It requires minimal
coordination, and minimal new software.
So when I go to that URL it has some requirements for simple deployment.
"All that's required is that the client system have... 3. a username...
4. a password".
Again, trying to put a username/password on 10,000 sensors that have no
user interface and assuring that the RADIUS server to which these 10,000
sensors will be authenticating using Eduroam have all the right info is the
pain-in-the-ass we're trying to address.
I don't think you're trying to solve the same problem we are.
We are trying to avoid wheel reinvention. The novel bit here is the mutual
authentication in the TLS stack based on the already defined Wi-Fi Alliance DPP
bootstrap key.
The spec doesn't require (or use) DPP bootstrapping.
It uses the key extracted from a DPP bootstrapping process so I think
you're doing a semantic exercise here-- a distinction with no difference.
This draft is different from a number of related issues in that it solves a
different problem, and in a different way:
* it leverages web PKI to bootstrap TLS-based EAP methods
* it does provisioning over standard internet protocols, instead of extending
the supplicant.
I think both of the above are useful. Using EAP as a generic transport
layer for provisioning seems like a poor choice.
Nowhere do we propose to use EAP as a generic transport layer for
provisioning.
Dan.
--
"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
[email protected]
https://www.ietf.org/mailman/listinfo/emu
