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

[Alan DeKok <[e-mail]>]

On Jan 7, 2020, at 4:34 PM, Ryan Sleevi <[e-mail]> wrote:
> 
> I've snipped your message, because I think we've gotten to a place where we're clearly talking past each other, as you claim I've said several things which I've most definitely not said, or expressed the opposite view. I'm hoping a reset here might help us find a more productive path forward, as well as figure out where the confusion started.

  OK, that sounds good..

> I think it's useful to go back to the original message from Owen, at https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM . Perhaps there are other messages and context I've missed, since this was cross-posted across two WGs, but that's the starting point.

  I agree.  It would help to have a draft.

> In that, I think we've got a path forward for interoperable EAP implementations: NAIRealm with id-kpid--eapOverLAN asserted as an EKU. That gives a minimal sort of certificate profile to begin discussing.

  My only $0.02 there is that RFC 4334 defines id-kp-eapOverLAN, but seems to imply that it is intended for *client* certificates.  That would need clarification for this use-case.

> The question posed in that original message is what to do with extant certificates and extant practices, such as going to CAs used for TLS and asking for an id-kp-serverAuth cert, or supplicants looking for id-kp-serverAuth, and whether to specify that. My answer to that is categorically "no, don't do that".

  The use of id-kp-serverAuth is suggested in RFC 5216 Section 5.3:

   In the case of the EAP-TLS peer, this involves ensuring that the
   certificate presented by the EAP-TLS server was intended to be used
   as a server certificate.  Implementations SHOULD use the Extended Key
   Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that
   at least one of the following is true:

   1) The certificate issuer included no Extended Key Usage identifiers
      in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier in the
      certificate (see Section 4.2.1.13 of [RFC3280]).
   3) The issuer included the id-kp-serverAuth identifier in the
      certificate (see Section 4.2.1.13 [RFC3280]).

  Realistically, we can't change these recommendations in an "update EAP for TLS 1.3" document.

> This is not specific to EAP, but part of the general problem of repurposing different trust hierarchies and different implementations, without addressing or mitigating the ecosystem considerations.

  There are many OIDs assigned to extended key purpose:

https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.2

  On quick inspection, most of those don't define their own PKI hierarchy.  So it would seem that most have the same problem.

> For example, the use of such certificates outside of TLS can and will lead to them being revoked, because one of the requirements for such certificates is that they be used in TLS, otherwise they're revoked.

  Based on personal knowledge, such revocation will take down a number of banks world-wide.  And many other enterprises.  Which to me, means it's not going to happen.

  And how the heck is the CA going to find out?  They don't have armies of people trolling SSIDs for "mis-use" of certificates.

  Any user of such a certificate could point to RFC 5216, and rightly claim that this use-case is explicitly allowed.

  Further, RFC 2549 defines id-kp-serverAuth as being for "TLS Web server authentication".  But it doesn't mandate that certificates get revoked if they're used for another purpose.

  TBH, I'd like to see a pointer to an official CA policy saying that such revocation is required.

> Also, the changes to how PKI libraries validate TLS certificates, and the expectations for the issuance and management of such certificates, are at odds with the goals and objectives of interoperability being discussed.

  I'm not sure why.

  Having spent too much time banging my head against the OpenSSL API, I have some depressing familiarity with it.  Their certificate validation API doesn't care about extended key usage.  Those checks have to be added by the application.

  So... if we upgrade EAP implementations to use id-kp-eapOverLAN, then only the EAP applications have to be updated.  The common PKI libraries don't change.

> Reusing private key material across protocols and use cases does cause issues,

  Such as?

> just like reusing root certificates across trust purposes does cause issues. So using the TLS PKI is and always will be fraught with peril, and the maintainers of those TLS PKIs will disregard "your" concerns (the equipment, software, and users), because "your" use case is explicitly not supported and not supportable.

  I disagree rather fundamentally.  For one, it's not "my" use-case.  It's the use-case of literally billions of devices, and of the largest companies on the planet. 

  You're suggesting here that the root CAs will tell those people to "get stuffed" with no repercussions.  I don't see that happening.  Ever.

   If the root CAs try something so stupid, it will be international news, and they will get told in no uncertain terms to stop it.  And they will.

> These concerns aren't unique to EAP, by any means. But they're reasons why using id-kp-serverAuth is going down a route of trouble, and just because it's been done by some vendors doesn't mean it's good.

  Not "some vendors".   All vendors.  BILLIONS of devices.  TRILLION DOLLAR companies.

  In a fight between you and them, I'll bet on them.  I understand where you're coming from, but describing this practice as "done by some vendors" is drastically minimizing the situation.

> A transition plan is always challenging, and the IETF is generally a poor venue for figuring out those logistics, because they're often rarely technical. For example, RFC 7585 exists: implementations "just" need to adopt it. Or, if the desire is to have an RFC describe what the end state should be, it should focus on that: describing the end-state. I don't think it should specify the intermediate states, because those are going to vary on a host of concerns, and worse, encourage folks to stop at the intermediate state as being 'good enough'. One such example of an intermediate state is using id-kp-serverAuth certificates, or trying to make a public/private CA demarcation. Those are bad steps to take.

   Again, this isn't an "intermediate state".  This is decades-long existing practice, and existing standards.

  I think part of the disconnect here is that you're not clear on just how entrenched this use-case is.  You keep saying "some vendors" or describe it as an "intermediate state".  It's simply not true, and that false description is leading you to false conclusions.

> I'm not as optimistic as you are for suggesting 'all' EAP clients/supplicants are behaving and enforcing those extended key usages, so that doesn't seem too unreasonable. For example, wpa_supplicant doesn't seem to do so, in the versions used by ChromeOS, Android, or the current tip of tree (using either the internal or the OpenSSL implementation), and that seems like it probably covers quite a few devices/clients.

  Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth.  wpa_supplicant checks for it, too.  See src/tls/tlsv1_client_read.c.  The requirements of RFC 5216 Section 5.3 are followed.

  Yes, this means that it's theoretically possible for a site to use *only* wpa_supplicant, and therefore not include id-kp-serverAuth in it's EAP server certificate.  But in a multi-vendor environment, the EAP server certificate MUST include id-kp-serverAuth, otherwise many devices will not be able to connect.

  I'll bet that the only EAPoL deployments which don't include id-kp-serverAuth are (a) tests / toys, or (b) controlled environments used only by a tiny number of devices.

  So id-kp-serverAuth is *entrenched*.  It's not used sometimes by some vendors.  It's baked into existing standards and implementations.  Everyone uses it all of the time.  Everywhere.  Always.

> In the TLS PKI, there's lots of industry experience on how to make changes. These changes often involve significant risk of breakage, and yet have become somewhat the norm, and with minimal practical impact. These can involve setting flag days, often starting as per-vendor flag days, such as was done with SHA-1. They can start with changes in major releases, such as new behaviours introduced in a major OS release or a major supplicant release to align closer to the specification or end-state. They may involve some of the intermediate steps mentioned, but only to the extent those are intermediate accomodations; for example, Chrome often has Enterprise flags that allow disabling standards-compliant behaviour when rolling out new versions, but only for a limited time and under limited situations. These aren't, I think, good things to specify, but they're certainly good things to share information about. I don't know if the IETF is the best place for that, but that's neither here nor there. However, an important part of those experiences is that things don't move until vendors break things. Yes, there needs to be a better path, but until you're willing to remove support for the old, or provide incentives for the new, your users don't and won't move.

  I believe a good incentive to deploy the new behaviour has been discussed here: ease of configuration of the end-user devices.

  Other SDOs like the Wi-Fi alliance are moving ahead with their own requirements on certificates.  CAs will support those requirements for the simple reason that it makes them money.

> Hopefully that's easier to understand. I'm not sure how we ended up on such different pages, but I think the assertions and requests from your last message were a good indicator that we weren't even in the same postal code, let alone the same page, as far as discussions go.

  I agree.  I think some of the disconnect may be addressed here.

  Alan DeKok.