Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

[Alan DeKok <[e-mail]>]

On Dec 15, 2019, at 6:43 PM, Ryan Sleevi <[e-mail]> 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.