On Dec 15, 2019, at 6:43 PM, Ryan Sleevi <[email protected]> wrote:
> That is, most definitions for “public CAs” come down to “I don’t want to
> think about / analyze the security or validation practices of the CA, I want
> my supplicant / software / hardware vendor to do it for me, against some
> criteria the vendor is responsible for, and hope it all works out”. To the
> extent TLS uses ‘public CAs’, it either boils down to the OS or browser
> vendors reaching rough (independent) consensus on who is worth trusting, or
> the vendor going along with everyone else’s decisions for cost (too expensive
> for the vendor to evaluate) or compatibility (everyone else trusts them and
> it’d break things if the vendor doesn’t) reasons.
It's also a way to move trust out of the individual machine, and into the
network. Given the complexity of supplicant configuration, I think that's a
good thing.
> Is the supplicant market likely to reach that consensus? It seems unlikely,
> unless and until you define the “thing everyone can and wants and needs to
> validate”, and that thing is either globally unique (like DNS) or
> sufficiently domain specific (e.g. Passpoint) that vendors can agree.
>
> > If at some point in the future, public CAs are willing to issue certs with
> > some or all of the above fields, then what is the migration plan, what do
> > we tell EAP clients to do now, and how to they migrate their verification
> > logic?
My goal is to answer that question. Which involves some discussion and
analysis.
> This statement similarly requires untangling. There are “public CAs” as “The
> set of keys/certificates used for authenticating particular services” and
> “public CAs” as the set of organizations that own/operate those keys.
>
> The case of the former is extremely unlikely, as the industry is actively
> moving away from that approach to PKI, by trying to ensure separate keys for
> separate use cases or authentication realms, of which EAP would surely be.
Yes.
> > - client verifies server cert has id-kp-eapOverLAN set
>
> What assurance is this to provide?
The use-case for the certificate matches the intended use-case.
Right now, I can use the same server certificate for HTTPS, EAP, or any other
TLS-based protocol. That seems wrong.
> - NAIRealm in cert matches user’s realm
>
> This only works iff the NAIs are globally unique (e.g. map to DNS), which
> imposes requirements on NAIs that aren’t present in RFC 7542, and seemingly
> intentionally, compared to 4282.
Huh? RFC 7542 explicitly calls out NAI Realms as mapping to DNS. See
Section 2.5:
---
In order to ensure a canonical representation, characters of the
realm portion in an NAI MUST match the ABNF in this specification as
well as the requirements specified in [RFC5891]. In practice, these
requirements consist of the following item:
* Realms MUST be of the form that can be registered as a Fully
Qualified Domain Name (FQDN) within the DNS.
This list is significantly shorter and simpler than the list in
Section 2.4 of [RFC4282].
---
The intention of RFC 7542 is that NAI Realms are *exactly* DNS names. This
is a change from 4282, where realms were, well, we don't know. That failure
motivated 7542.
> Again, I think that’s desirable, to define an entirely new PKI with zero
> overlap with the server auth/TLS PKI used by OSes/browsers, but that does
> change your recommendations and design a bit :) The short term recommendation
> becomes “don’t use public CAs”, and that seems easier to explain and easier
> to evolve the technical requirements, until the time that such a new,
> EAP-specific public PKI can be introduced.
The recommendation for EAP has generally been "don't use public CAs".
Originally it was in part because implementations didn't do certificate
pinning. i.e. once a root CA was trusted, a supplicant would accept any server
certificate signed by that root, and send credentials over.
Now, over a decade of practice has shown the private CAs for EAP allow for
greater flexibility and control. I've personally had CAs take my money for a
cert, and refuse to give me anything in return. No amount of complaining will
convince them that it's a problem. It's much simpler to just use a private CA.
> In my mind, this is no different from organizations that want TLS
> certificates for their servers named “webmail” (not globally unique) or
> “mail_01.company.example” (not preferred name form / LDH). The answer is “use
> private CAs, don’t use public CAs”
I agree.
Alan DeKok.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
