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

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Sun, 15 Dec 2019 20:53:01 +0000

Hi,

At ACME meeting at IETF106, the last discussion of the week was around EMU looking for recommendations for EAP client/peer/supplicant cert verification logic when the client is verifying the cert that the EAP server presents. Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/  The recommendation was to ask lamps. This was also discussed on EMU mailer recently.

Quoting some additional background that Alan gave on EMU mailer:

"Background:

a) the current practice in TLS-based EAP methods is to use certificates with "id-kp-serverAuth" OID set for Extended Key Usage.

b) many supplicants check for this OID, and refuse to perform authentication if it is missing

c) supplicants do not check DNS names or any other field in the certificates

d) as a result of this lack of verification, supplicants ship with all known CAs disabled for TLS-based EAP methods"

The key consideration is that RFCs that recommend cert fields for EAP servers that clients should check for are not currently issued by public CAs, and in some instances (e.g. SSID) ownership can often not be proven by CAs.

For example:

https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU

https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID

https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm

If an EAP server operator wants to use a public CA identity cert on their EAP server, what recommendations should we give to EAP clients so that the supplicant code can handle public or private CA issued EAP server identity in a secure a fashion as possible?

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?

The ideal experience would be along these lines for a client with real user interactions:
- client connects to an EAP server
- client prompts user for userId + realm and password
- client verifies server cert has id-kp-eapOverLAN set
- NAIRealm in cert matches user's realm
- verify the cert signing chain

The reality today is that if the server cert is issued by a public CA, then all that client can really check is:
- id-kp-serverAuth is set
- dNSName in cert matches user's realm
- verify the cert signing chain

We would like to document some recommendations for EAP clients and EAP operators so that public CAs could be used, and recommend checks for public vs. private CA issued EAP server certs.

It seems like logic should be something like:

- recommend EAP operators with private CA issued certs on their EAP servers set id-kp-eapOverLAN and NAIRealm set
- recommend EAP operators using public CAs get EAP server certs with id-kp-serverAuth and dNSName set
- recommend clients enable trust in public CAs
- recommend clients implement different cert verification logic depending on whether the EAP server cert is issued by a public CA or private CA
- for public CA certs, client checks that id-kp-serverAuth is set *and* dNSName matches user realm. If either check fails, reject.
- for private CA certs, client checks that id-kp-serverAuth or id-kp-eapOverLAN is set *and* NAIRealm matches user realm. If either check fails, reject.

- as a longer term goal see if public CAs will issue id-kp-eapOverLAN and NAIRealm. Although of course if some were to start doing this, then there is a migration challenge, and clients cannot make a hard check for these values against all public CAs. This doesn't really seem practical in the near term at all.

Note that for an IoT device, there is some work to do to define how to e.g. extend the RFC8366 so that it can specify the dNSName that devices should check for when verifying EAP identity where they EAP server uses a public CA. Some related options are outlined in https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01.

Comments/thoughts?

Regards,
Owen

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 15 Dec 2019 18:43:24 -0500

On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) <[email-masked]>
wrote:

> Hi,
>
>
>
> At ACME meeting at IETF106, the last discussion of the week was around EMU
> looking for recommendations for EAP client/peer/supplicant cert
> verification logic when the client is verifying the cert that the EAP
> server presents. Minutes here:
> https://datatracker.ietf.org/doc/minutes-106-acme/  The recommendation
> was to ask lamps. This was also discussed on EMU mailer recently.
>
>
>
> “Background:
> a) the current practice in TLS-based EAP methods is to use certificates
> with "id-kp-serverAuth" OID set for Extended Key Usage.
>
> d) as a result of this lack of verification, supplicants ship with all
> known CAs disabled for TLS-based EAP methods”
>
>
>
> The key consideration is that RFCs that recommend cert fields for EAP
> servers that clients should check for are not currently issued by public
> CAs, and in some instances (e.g. SSID) ownership can often not be proven by
> CAs.
>
>
>
> For example:
>
>
>
> If an EAP server operator wants to use a public CA identity cert on their
> EAP server, what recommendations should we give to EAP clients so that the
> supplicant code can handle public or private CA issued EAP server identity
> in a secure a fashion as possible?
>

Define “public CA” first, and it’ll be clearer that the question is really
supplicant-specific.

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.

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?
>

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. The case of the latter is already available from said organizations as
part of “managed CA” or “private CA” offerings, which are operated by that
public CA organization, but that’s effectively greenfield because you
aren’t having to interoperate with any extant keys or certificate profiles.

The ideal experience would be along these lines for a client with real user
> interactions:

What assurance is this to provide?

- 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.

>
>
>
> The reality today is that if the server cert is issued by a public CA,
> then all that client can really check is:
>
> - dNSName in cert matches user’s realm
>
> We would like to document some recommendations for EAP clients and EAP
> operators so that public CAs could be used, and recommend checks for public
> vs. private CA issued EAP server certs.
>

If you mean the same set of CAs and keys used for TLS by common operating
systems and browsers, it bears highlighting again: industry is moving away
from that. Which is to say that contracts and requirements for PKIs used
“by default” by browsers and operating systems are being explicit about the
need to segment purpose and use case and not use such certificates for such
purposes.

Already, TLS and e-mail, the two dominant uses of PKI in such systems, are
required to be distinguished at their intermediate level. Browsers are
looking to explicitly only trust the TLS-Web side of the PKI, and making
sure that the TLS-Web PKI side is highly agile. Other cases, such as
restricted use server to server PKI or industry bespoke cases (such as
financial services or system networking) are being restricted to PKIs that
aren’t federated-by-default.

For example, X9 recently revived their PKI WG, to define PKI requirements
appropriate for financial services customers (like ATM to bank), because
financial services struggle to move at the same speed as modern software,
for understandable reasons. The use of domain/purpose-specific PKIs is
something we can and should be embracing more of.

It seems like logic should be something like:
>
>
>
> - recommend EAP operators with private CA issued certs on their EAP
> servers set id-kp-eapOverLAN and NAIRealm set
>

This is why I started with trying to define what “public CAs” are. If you
mean the extant CAs trusted by browsers and operating systems, both this
recommendation and the one proceeding it may not be good recommendations or
long-term viable practices.

That’s not to say you couldn’t, but it means your EAP services and servers
need to be prepared to be as agile as the Web ecosystem is and modern
operating systems are converging on. The ability to support or be beholden
to “legacy” - whether algorithms, profiles, or trust in particular
organizations - is something that industry is recognizing does not align
with user needs. This means adopting practices like automation, being able
to quantify compatibility risks, and being able to move quickly as
expectations change, in response to ecosystem challenges.

Maybe that’s fine for EAP, but I’m willing to suspect that it because
updates may involve physically replacing client hardware or physically
installing firmware, you really don’t want EAP needing to be beholden to
those agility needs of the Web and OSes. And, again, that’s perfectly OK,
it just means defining a PKI and set of procedures that is appropriate for
that use case, and convincing industry to adopt it as an “out of the box”
configuration. Or, alternatively, embracing private PKI.

- recommend clients implement different cert verification logic depending
> on whether the EAP server cert is issued by a public CA or private CA
>

Why is this good?

To the extent browsers or OSes make this distinction, it’s largely based on
simply phasing rollouts of new requirements, with the goal to eventually
require consistent and uniform treatment to ensure simpler code with
consistent and uniform security properties. Having a long-term segmentation
of requirements, or even encouraging them without a clear vision back to
harmonization, is definitely an anti-pattern here.

- for public CA certs, client checks that id-kp-serverAuth is set **and**
> dNSName matches user realm. If either check fails, reject.
>
> - for private CA certs, client checks that id-kp-serverAuth or
> id-kp-eapOverLAN is set **and** NAIRealm matches user realm.. If either
> check fails, reject.
>
>
>
> - as a longer term goal see if public CAs will issue id-kp-eapOverLAN and
> NAIRealm. Although of course if some were to start doing this, then there
> is a migration challenge, and clients cannot make a hard check for these
> values against all public CAs. This doesn’t really seem practical in the
> near term at all.
>

The effect of the separate EKU, which is actually quite desirable, is that
it functionally makes it difficult for CAs to issue these certificates from
intermediated that lack this EKU or any EKU. Further,  CAs subject to
browser/OS vendor oversight are consistently required to segment out their
EKUs at the intermediate level, and required to always specify EKUs.

The end result is that, to achieve this long term goal, you’ve effectively
required the establishment of a new PKI - just at the intermediate level
rather than the root. And as many of the public CAs can tell you, having
recently encountered challenges regarding non-TLS intermediates from roots
that are subject to browser/OS oversight, it’s often easier to use separate
roots as well.

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.

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”

>
> Note that for an IoT device, there is some work to do to define how to
> e.g. extend the RFC8366 so that it can specify the dNSName that devices
> should check for when verifying EAP identity where they EAP server uses a
> public CA. Some related options are outlined in
> https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01.
>
>
>
> Comments/thoughts?
>
>
>
> Regards,
>
> Owen
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Alan DeKok <[email-masked]>
Date: Sun, 15 Dec 2019 19:50:52 -0500

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

  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.

> 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.

> 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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Dec 2019 13:51:09 -0500

> a) the current practice in TLS-based EAP methods is to use certificates with
    > "id-kp-serverAuth" OID set for Extended Key Usage.

    > d) as a result of this lack of verification, supplicants ship with all known
    > CAs disabled for TLS-based EAP methods”

    > The key consideration is that RFCs that recommend cert fields for EAP servers
    > that clients should check for are not currently issued by public CAs, and in
    > some instances (e.g. SSID) ownership can often not be proven by CAs.

    > If an EAP server operator wants to use a public CA identity cert on their EAP
    > server, what recommendations should we give to EAP clients so that the
    > supplicant code can handle public or private CA issued EAP server identity in
    > a secure a fashion as possible?

    > 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?

I think that this is a really big if.
So, I want to change the question, which I think can make this problem a lot
easier to get traction on.

} If at some point in the future, there is one or more well-known trust
} anchors that (IoT?) devices can build in, and these CAs are willing to issue
} certs with some or all of the above fields, can we design a transition
} process from one-touch provisioned private CAs to a common DN+extension
} based common anchor?

    > The ideal experience would be along these lines for a client with real user

    1> - client connects to an EAP server
    2> - client prompts user for userId + realm and password
    3> - client verifies server cert has id-kp-eapOverLAN set
    4> - NAIRealm in cert matches user’s realm
    5> - verify the cert signing chain

<2> and <3> seem in the wrong order.
If the certificate has NAIRealm, why would we need to ask the user for the
realm?  Wouldn't we instead ask them: "What is your userID in REALM FOO"

    > all that client can really check is:

    1> - id-kp-serverAuth is set
    2> - dNSName in cert matches user’s realm
    3> - verify the cert signing chain

I think that <3> happens first, and the connection is dropped if it does not
validate.  Maybe you aren't expressing an order here at all.

    > - recommend clients implement different cert verification logic depending on
    > whether the EAP server cert is issued by a public CA or private CA

Would setting dNSNAME on private CA issued certs reduce complexity?

    > NAIRealm. Although of course if some were to start doing this, then there is
    > a migration challenge, and clients cannot make a hard check for these values
    > against all public CAs. This doesn’t really seem practical in the near term
    > at all.

Trust NAIRealm extension only if id-kp-eapOverLAN is set.
having implemented the dNSNAME code path, it seems like there is no point in
implementing the other path.

    > Note that for an IoT device, there is some work to do to define how to e.g.
    > extend the RFC8366 so that it can specify the dNSName that devices should
    > check for when verifying EAP identity where they EAP server uses a public CA.
    > Some related options are outlined in

Owen and I have wrangled about the topic of how exactly the pinning is done.
The above document does not really outline the problem space in my opinion,
focusing on other dimensions of the process.

The requirements that Owen has expressed to me are:
  1) 8366bis must be able to pin CA + DN/SAN, such that the operator can rotate their
     public key without invalidating the voucher. (possibly including
     changing public key algorithm)

  2) 8366bis must be able to pin (?-public key), such that the operator can
     switch (public) CAs without invalidating the voucher.

There might be a (3) that I can't think of right now.

But, if these two requirements seem to contradict each other, then high-five
to you, you were paying attention :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alan DeKok <[email-masked]>
Date: Tue, 17 Dec 2019 14:07:15 -0500

> } process from one-touch provisioned private CAs to a common DN+extension

  I hope so.

  My $0.02 is that configuration belongs in a machine-readable format, not in fields in a GUI.  i.e. fields in a cert.

  Once we have a machine-readable format, transition plans become simpler, because we have a better handle on what systems are doing.

> realm?  Wouldn't we instead ask them: "What is your userID in REALM FOO"

  The server certificate is presented before the user credentials are sent (PEAP / TTLS).  So the client can automatically derive the NAIRealm.

  The issue is that users are slow.  It's bad to have the EAP session hang while the user enters "name / password" in a GUI.  That's the only real reason why name / password is requested before the EAP session starts.

> validate.  Maybe you aren't expressing an order here at all.

  The only reason to order these checks is cost.  i.e. simple checks should run first, before complex checks.

> Would setting dNSNAME on private CA issued certs reduce complexity?

  No.  The DNS names at at least the realm names (example.com), but they could be more (radius.example.com).

  There's no good way to automatically derive the NAIrealm from a DNS name.  Given both, you can check if they're compatible.  But that's it.

> implementing the other path.

  The NAIRealm tells you exactly which Realm you're using.  The DNSName path doesn't.

  The NAIRealm can be used to skip the step where the user is prompted for the realm.

  Alan DeKok.