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

[Ryan Sleevi <[e-mail]>]

Hi Alan,

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.

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.

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

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

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. 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.
Reusing private key material across protocols and use cases does cause
issues, 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.

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

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.

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.

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.