[39276] in Kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Oct 25 16:35:28 2023
Date: Wed, 25 Oct 2023 15:33:54 -0500
From: Nico Williams <nico@cryptonector.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: kerberos@mit.edu
Message-ID: <ZTl7si0yfdU634sR@ubby21>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <202310251251.39PCpTqc026799@hedwig.cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Wed, Oct 25, 2023 at 08:51:29AM -0400, Ken Hornstein wrote:
> >While I'm on the subject of JWT, there are two reasons JWT is killing
> >Kerberos:
>
> Are you sure one of the most important reasons ISN'T that the GSSAPI is
> insanely complicted and people who look at it get confused and move to
> something else that is much simpler?
At $WORK that's definitely not the reason. It's the others I listed,
though the one about authz data is a flavor of the API complexity issue
only much worse: because not only is it insanely hard to get at authz
data when you can get at it, it's also often not possible at all. So
not just insanely complex, but often-not-even-possible.
And yet as simple as JWT is, it's also not:
- HTTP user-agents need to know how to fetch the rock that the server
asks them to fetch, and most of them don't know
(Which is basically why OIDC exists.)
This is fixable if anyone cares to bother, but then OIDC exists.
- HTTP user-agents that do know how to fetch the rock don't do rock
caching
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
