On 5/20/25 11:12 AM, Tom Beecher wrote:
Same difference: burying policy into an authentication token. What
is the point? A backend presented with an authenticated identity
can do the same thing far easier and far more scalable without any
of the downsides like mentioned. A backend server doesn't even
need a name/key binding borne by the client at all, let alone
bearing policy info as well.
Say I run a storage unit business. When you rent a unit, I give you a
code. I have decided (by my policy) that any user with a valid code
can access their unit 24/7/365.
You come to rent a unit from me. You ask that your code only works on
Sundays, because that is the only day you will ever come. You have
decided (by your policy) you want something more restrictive than
mine. I agree.
Someone shows up on Wednesday and tries to use your code. You told me
that would never be you, so I deny the entry, because *YOU* told me
not to allow it. Semantically, you could say it's 'you did not
authorize' , but really it's "I did not not authenticate the identity
of this user, based on verified instructions that person provided me".
This is really al EKU is. I'm not arguing it's perfect. But that's
what it is.
Unless you're willing to say that whatever is doing the authz/policy is
*offline* -- ie, can't look that policy up in real time -- this can all
be done using normal online mechanisms. That is, "server, can is this
identity allowed to do this or that?" in your example.
I'm not arguing that it doesn't work as stated. I'm arguing that they
bring a tremendous amount of cert baggage -- business models,
enrollment, revocation, etc, etc -- that is really hard to justify under
any normal circumstance. Asymmetric keying unfortunately involves way
too many people thinking that once they are involved, certs are
necessary. It need not be, and in fact the vast majority of cases would
greatly simplified to just get rid of certs entirely, even the basic
name/identity binding they provide.
Mike
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/IBZ4NUKDUTVIGGENR72GRQ6SYKJ5H4XA/
