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

[Ryan Sleevi <[e-mail]>]

Hi Owen,

While I have responses inline below, I am concerned that if I'm disagreeing
so much with you, there might be some high-level impedance mismatches that
we should get sorted first.

At the high-level, I will say that using TLS (id-kp-serverAuth)
certificates, from the intersection of CAs that are commonly trusted by
operating systems and browsers, is bad. It will create security issues,
will create interoperability issues, and will not help users. Conceptually,
it's akin to suggesting a protocol violation, and the best thing to do with
those is be strict in what you accept and break those implementations as
early as possible, in the spirit of
https://tools.ietf.org/html/draft-iab-protocol-maintenance .

The set of CAs that are trusted for TLS on a given device, platform, or
application are intrinsically tied to purpose (TLS) and the library used to
implement that TLS and PKI behaviour. They are not separable, and trying to
do so is a problem, not a solution. This is perhaps most obvious as vendors
like Apple have tightly integrated PKI policy requirements (such as
Certificate Transparency) with the capability of their TLS libraries; for
several macOS/iOS releases, any application using a TLS library other than
Apple's CFNetwork would be unable to successfully verify a number of
certificates from CAs Apple trusted for TLS.

EAP is not TLS, and your use case here is not TLS (clearly), so don't mess
with TLS, or you will break, eventually. The best I can do is try to
explicitly break you sooner, than later, so that I can deal with the
fallout sooner than later, and not when there's a critical issue in the TLS
ecosystem needing rapid resolution.

At a high-level, you're still fundamentally proposing a new root store. I
realize that may not be obvious, given the suggestion of intermediates with
id-kp-eapOverLAN, but that's still fundamentally what's being suggested,
because you still need to define a certificate profile (such as the EKU),
expected policies such as how that information is validated, and a process
for ensuring that validation is performed. I think that's a laudable goal,
and perhaps worth pursuing, but it's important to stress that in defining a
new root store, there's no reason to reuse anything extant. The fact that
operating systems may trust some organizations for other purposes (TLS or
S/MIME) should by no means be dispositive towards whatever you're doing.
Where to best propose certificate profiles or certificate policies for that
root store, I don't know, and that clearly requires a lot more implementor
experience and consensus to end up with something like the CA/Browser Forum
that is useful for TLS.

On Tue, Jan 7, 2020 at 7:31 AM Owen Friel (ofriel) <[e-mail]> wrote:

> Thanks for the detailed reply Ryan. See line.
>
>
>
> *From:* Ryan Sleevi <[e-mail]>
> *Sent:* 15 December 2019 23:43
> *To:* Owen Friel (ofriel) <[e-mail]>
> *Cc:* EMU WG <[e-mail]>; [e-mail]
> *Subject:* Re: [lamps] EAP/EMU recommendations for client cert validation
> logic
>
>
>
>
>
>
>
> On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) <[e-mail]>
> 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.
>
>
>
> 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?
>
>
>
> 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.
>
>
>
> [ofriel] That’s pretty much it. For supplicants running on standard OSes
> (Windows, MacOS, iOS, Android), they could use logic similar to Chromium
> (which you must be familiar with seeing as you helped write it:
> https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b647bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e
> ) to ask the OS if a presented EAP cert is one issued by a public CA. This
> does mean that the supplicant is asking about Web TLS certs that Browsers
> trust. However, there are ample examples and support cases opened by
> operators who are trying to do exactly that – get a web PKI cert from a
> public TLS/Browser CA and deploy it on an EAP server. Is this recommended?
> Not really. Is it using a Web/TLS cert for a purpose its not strictly
> intended for? Yes. Does this happen in real deployments? Absolutely. How
> prevalent is it? I do not have that data.
>

I'm not really sure what you're trying to suggest here, and I'm not really
sure why you mentioned the code in relation to the question.

The problem still remains: you haven't defined public CAs in any
interoperable sense, and I think that's relevant to the discussion in the
IETF, if you want to get interoperable implementations.

I also think it's misguided and misunderstands the code you referenced.
That code is to explicitly reject things that might otherwise be valid, so
that it fails early and isn't accepted, even if there might be reasons to
allow it. If the suggestion is that EAP supplicants should explicitly
reject anything from common TLS-trusted CAs (including from any
intermediates they issue, regardless of key policies), I wholeheartedly
agree with that, but I'm under the impression you're suggesting the exact
opposite.


>
>
> 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.
>
>
>
> [ofriel] I think the supplicants running on the main OSes would be happy
> to delegate the question of whether a CA is a ‘public CA’ to the OS. For
> manufacturers of things/embedded devices/etc. then its currently very much
> at the manufacturers discretion, and consensus here would be unlikely.
>

I'm afraid this side-steps the question for the "main OSes" that everyone
would be happy with: they still need to make a decision, and so you're
still back to manufacturer's discretion, and thus back to a lack of
consensus without a clearly defined problem statement, and this answer has
solved and clarified nothing. Even if you 'want' to handwave to the OS, the
OS vendor still has to make a decision, just like the embedded devices do.
And for that, it needs a clear problem statement.


>
>
> 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.
>
>
>
> [ofriel] And by this you mean that a root CA will have e.g. one
> intermediate with EKUs of id-kp-serverAuth/id-kp-clientAuth, and a
> different intermediate with an EKU for id-kp-emailProtection, right? The
> logical extension here for EAP is yet another intermediate with an EKU for
> id-kp-eapOverLAN.
>

In a sense, yes, but I don't think it goes far enough, and I think it
misses the problem I was trying to highlight, which is that this means
separate _roots_ for id-kp-eapOverLAN.

Separating at the intermediate is happening, but equally, separating at the
root is happening, and in fact more preferable. We've explicitly rejected
CA applications that use an intermediate level separation, because the
organizational and operational considerations are too great for folks to
effectively manage. We're not the only vendor working through problems like
this - https://wiki.mozilla.org/CA/Audit_Letter_Validation is an entire
system developed jointly with Mozilla and Microsoft trying to work through
these issues, where CAs 'intended' to separate out the intermediates but
failed to do so correctly. It's a flawed design, a flawed system, and with
significantly more operational overhead than simply separating at the root.

We see this in new systems, which purpose-build root hierarchies, like
Passpoint or Wireless Power/Qi or "Made for Apple iPhone". The point is
that the *entire* hierarchy is separate, and not just branches, because
that's seemingly the only practically effective way to manage PKI at
Internet scale.


> 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.
>
>
>
> [ofriel] Right, but from a supplicant perspective (or in general for any
> client running on any OS e.g. Browser on Windows), there is zero difference
> between an operator who deploys and runs their own private CA, or takes a
> contract out with a public CA organization and gets them to run a
> managed/private CA on their behalf.
>

Perhaps you could rephrase this, because I think I disagree with about
every interpretation I can come to, but I don't want to waste your time if
I'm misunderstanding :)


> 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
>
>
>
> What assurance is this to provide?
>
>
>
> [ofriel] To assure that the cert is for the intended purpose – 802.1X/EAP
> server auth. Just like other TLS/Browser clients checks for
> id-kp-serverAuth.
>

That's a tautological definition though. The intended purpose is the
intended purpose.

This question is trying to pose "What is the information or policy that is
validated". As clarified later on, you've got at least the "NAI realm is
appropriately unique", which in this case means matches to DNS. "Intended
for 802.1X" doesn't seem correct, though, because that would similarly
imply that no extant TLS CA would issue certificates used in EAP, because
every CA would be verifying "intended for TLS server authentication", and
that's clearly not the case when used with EAP.


> 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.
>
>
>
> [ofriel] I agree that ideally  Web/TLS Browser certs should not really be
> used by operators as their EAP server identity certs, however, this does
> actually happen today. In an ideal world, it would be great if some of the
> large commercial (or free e.g. LetsEncrypt) public Web/TLS CAs had an
> intermediate signing CA with id-kp-eapOverLAN.
>

No, this would be bad.


> But today, and for the foreseeable future, what can we advise supplicants
> to do if we know that some operators will put Web/TLS identity certs from
> public CAs on their EAP servers?
>

If you know it's a TLS certificate, reject it.
If it has id-kp-serverAuth, reject it.
If it comes from a Root CA you know is or has been trusted for TLS, reject
it.
If it has not been explicitly configured by local policy to accept it,
reject it.

Are there existing certificates that will be rejected? Yes. Replace them.


> 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.
>
>
>
> [ofriel] Yes, I mean extant CAs trusted by Browsers and OSes. Yes the
> recommendations as written above would mean using a cert with a EKU for one
> purpose, for a different purpose, but that is the unfortunate reality. Do
> we ignore the problem and say ‘Don’t do this’ or do we try to document some
> compromise recommendations for both supplicants and CAs, with a roadmap of
> how to evolve?
>

Supplicants should break this case as soon as possible, because it _will_
break, and it's better to have it break within a maintenance cycle when
you're prepared for breakage and migrating than one day waking up and
finding it's all broken.

The least deliberate form of breakage is the status quo, which is to
require explicit configuration of the trust anchors and hand-wave the rest.
Somewhere in the middle you have things like vendor-flag-days (i.e. this
vendor requires id-kp-eapOverLan in it's new software for all certificates
issued after that supplicant's release date)
At the most deliberate, you have folks borrowing from that Chromium code /
maintaining a list of every CA that has been used for / trusted for TLS,
and explicitly rejecting/preventing certificates from them.

I doubt we'll find consensus on where the 'ideal' answer is, since every
vendor will have to weigh their own risks, but in no circumstances should
folks use TLS CAs.


> 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.
>
>
>
> [ofriel] I hope that this problem is easier to tackle for supplicants
> running on the major OSes. For things/embedded devices, this is a far
> harder problem to solve for sure.
>

Only to the extent the supplicant is integrated in the OS, much the way the
TLS library and PKI store are integrated. For anything else, such as 3P
supplicants, it remains an equally hard problem.


> [ofriel] Getting public CAs to manage a new PKI root (if that’s easier
> than just a new intermediate) with id-kp-eapOverLAN is a really really long
> road. And we know that some operators do use public Web/TLS certs as EAP
> identity certs. Which means that we cannot recommend supplicants enforce a
> check for id-kp-eapOverLAN.
>
>
>
> So it looks like there are three choices:
>
>    1. Completely ignore id-kp-eapOverLAN for ever.
>    2. Get supplicants to check id-kp-eapOverLAN if its not a public CA
>    (and use Chromium style public CA detection). Rollout of this would need to
>    be carefully managed too so that existing private CA operators who do not
>    set id-kp-eapOverLAN do not break.
>    3. Do nothing until  sufficient numbers of public CAs support
>    id-kp-eapOverLAN (in like 2035..?), then change supplicants to always check
>    for id-kp-eapOverLAN.
>
>
These are all bad options.

Look, any clients expecting id-kp-serverAuth are broken now. They just
don't realize it, they're walking timebombs, and the answer is to fix them.
Vendors can and should be more explicit in this, by checking
id-kp-eapOverLan, because they're going to eat the incompatibility at some
point. Better to pay for that pain now, rather than continue to defer it
and hope nothing goes wrong. I mentioned above, there's a spectrum of
options for how to phase that in.

To explicitly reiterate #2: The implementation in Chromium very
intentionally does not *grant* capabilities based on that list, it
*removes* capabilities and makes code *more* strict. That is the only
reasonable use for such a list, and even then, it's problematic (e.g. if
the list is out of date, newcomers have advantages over incumbents). That
list has a host of other caveats, and why Chromium is moving to explicitly
rid itself of that list and has been. I appreciate the shout-out, but this
is very much a situation of using the list exactly opposite as intended :)

>