On 5/20/25 12:56 PM, brent saner via NANOG wrote:
On Tue, May 20, 2025 at 2:32 PM Michael Thomas via NANOG <
nanog@lists.nanog.org> wrote:
(SNIP)
Suffice it to say, I pretty much agree with Eliot's assessment of
"mismash" re: authn/authz.
This is likely due to X.509 (and various other parts of X.500 - which
surprisingly I think I've only seen one other person mention in this thread
so far) were historically designed to *be* AA, providing identities tied to
actual structured, registered entities/objects - not simply a verification
method for public keys.
Let's start with the obvious: X.509 is *old*. The assumptions it made
are either not true anymore or just not applicable to the modern world
for the most part.
X.500 was also designed with the expectation of federation -- or at the
least org-specific -- rather than centralization. Which is why a lot of
this stuff makes more sense if you approach X.509 as an org-managed thing
first and foremost, and wide-trust CAs being bolted on as kind of a kludgy
ad-hoc post-facto sort of thing rather than the other way around (if
private authorities are considered at all in your mental model).
At this point in time, what X.509 was or wasn't designed to do is sort
of irrelevant. It's main use -- by far -- is providing an identity to
key binding which browsers with embedded CA roots can verify against.
That's about it. All of the rest is pretty irrelevant in this day and
age and everybody should be extremely suspicious use of certs for
anything beyond that without going back to first principles of what is
trying to be achieved, rather than starting from the premise of "certs
are necessary, so how do we achieve XYZ with them?" Unfortunately that's
the way too many of us with too much gray in our beards were encultured
back in the day.
(That reminds me - Michael, Kerberos is still heavily used! Active
Directory - and I guess whatever "cloud"-y thing Microsoft has now..
"Entra"? -is basically just DNS, Kerberos, and LDAP wrapped up in a
clicky-clicky. FreeIPA and other F/OSS IdP/IdMs still *heavily* use
Kerberos as well. It hasn't gone anywhere, it's just usually abstracted
away and buried underneath a more C-level-friendly interface.)
Yes, I'm aware of that. It sort of proves my point though: Kerberos has
been sort of been relegated to a fairly "niche" slice of the identity
world where in the 80's it had a lot more traction especially in the
.edu world back then. These days it's almost all username/password over
TLS due to the web-like world we live in (and everything needs to
support).
Maybe webauthn will make some of the problems better, but it should be
noted that even webauthn doesn't use certs for clients -- enrolling
naked public to a given identity sitting in an online database is
completely adequate.
(I say this as somebody who likes Kerberos, but reality is still reality).
So a significant amount of KU/EKU is still kind of mired in the historical
roots of X.509 and has been shoehorned into other uses. (Though if I recall
correctly, id-kp-(client|server)Auth wasn't introduced until AFTER X.509
sort of branched into its own away from strict X.500 usage, but it's still
within the timeframe of "yes, these certificates are idents for actual
entities in an org-centric system". There's some overlap in the timeframes.)
Yeah, so let's not do that. There is an awful lot of X.509 hammers (and
their vendors, especially) laying around looking for anything resembling
an identity nail regardless of whether it makes any sense wrt
authn/authz/policy. I've seen plenty of times where people start with
the premise of "first we have an X.509 binding, and then what happens?"
which instantly falls into a very deep rathole that's hard to claw back
out of. The mistake is first positing the existence of an X.509 style
key/name binding first -- it should be the last choice, and only if
there is absolutely no other way to achieve the requirements, imo.
Mike
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VQBKEACVJPWVKWVJR53Z4I2ZB64RKUBL/
