On 7/28/21 5:06 AM, Alan DeKok wrote:
On Jul 27, 2021, at 1:50 PM, Alan DeKok <[email protected]> wrote:
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 novel bit in the EAP-DPP draft, yes.
My leaning is more and more towards just using EAP for authentication, and
doing provisioning via standard networking protocols.
For example, the Wi-Fi Alliance Passpoint R3 defines unauthenticated EAP.
It's essentially EAP-TLS, but using the extended EAP types with the Wifi
Alliance enterprise number. This requirement means that all supplicants and
servers have to be updated to support this method.
Multiple that by more standards bodies, vendors, IETF working groups, and we
end up with a massive amount of EAP types. All trying to get similar things
done. This is already happening.
Or, we define unauthenticated EAP as using "[email protected]". The supplicants
need to be updated once to support that. Different use-cases can just request different
methods via changing the username portion. And once they have network access, run
separate utilities to do their magic provisioning.
Mashing everything into EAP seems just... wrong.
Assuming everything can be assigned a username and a password is what
is wrong.
If you're concerned about *standard* EAP methods being used in
*standard* ways
then think about what we're proposing:
1. No change to RFC 7170
2. No change to RFC 8773
3. No change to RFC 7250
4. a new name assignment from a name registry created by an I-D (soon
to be RFC)
So what we're proposing is using an EAP method in a way in it was
defined and using
TLS to authenticate it using tools which were defined to authenticate
TLS. We're just
proposing to use those tools in a new way.
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
