RFC 4121 & acceptor subkey use in MIC token generation

[Nico Williams]

On Tue, Oct 24, 2023 at 08:09:20PM -0400, Greg Hudson wrote:
> On 10/24/23 15:50, Ken Hornstein via Kerberos wrote:
> [Disputing the following comment in k5sealv3.c:]
> >         First, we can't really enforce the use of the acceptor's subkey,
> >         if we're the acceptor; the initiator may have sent messages
> >         before getting the subkey.  We could probably enforce it if
> >         we're the initiator.

Once you've seen a MIC/Wrap token made with the acceptor subkey you know
that all subsequent sequence numbers must use the acceptor subkey.

Until then you don't know because GSS doesn't know if some MIC/Wrap
token it's consuming was made in response to an earlier MIC/Wrap/AP-REP
token sent by the acceptor application to the initiator.  Also, in
practice no app that makes use of PROT_READY before GSS_S_COMPLETE on
the initiator side will do so for more than one or maybe two per-message
tokens (one for the app itself, and one for SPNEGO), so maybe we could
have a hard cap[*] on the number of per-message tokens using the
initiator sub-session key when the initiator requested mutual auth.

So, yes, enforcement is tricky.  But in practice it's probably not a
problem because few apps make use of PROT_READY before GSS_S_COMPLETE on
the initiator side -- that's a pretty lame reason to say this is not a
problem...

[*] Apps that don't request mutual auth, however, should get to send an
    unlimited number of per-message tokens using the initiator
    sub-session key because what else could they do?

> I believe mutual authentication is frequently omitted for HTTP negotiate,
> but that's a minor point as in that case there's no acceptor subkey.

Yes.

> Whether the initiator can generate per-message tokens before receiving the
> subkey depends on whether the mechanism returned the prot_ready state (RFC
> 2743 section 1.2.7) to the caller after generating the initiator token.  RFC
> 4121 does not mention prot_ready; I couldn't say whether that's an implicit
> contraindication on setting the bit.  I'm not aware of any krb5 mechs
> setting the bit at that point in the initiator, although I recall Nico
> talking about maybe wanting to do so.

I'll have to check what MIT and Heimdal do.  But yes, it'd be nice to be
able to make use of PROT_READY when GSS_S_CONTINUE_NEEDED.

Though GSS loses appeal every day, so we might never get to do a variety
of interesting things in GSS space.

Then again I know someone who badly wants a JWT client library that does
krb5-style caching for audience-constrained JWT tokens, and we could
always revive something like Luke Howard's BrowserID (a key exchanging
GSS mechanism based on JWT) so that JWT could be used in application
protocols where today it can't, and that might be interesting.

While I'm on the subject of JWT, there are two reasons JWT is killing
Kerberos:

 - scaling (which we've solved in Heimdal)

   To provision a server with Kerberos acceptor credentials is
   traditionally a real pain because orchestrating them requires writing
   to a database (the KDB).  For JWT there's no provisioning, just a
   periodic download of fresh JWKs.  Heimdal has a scheme where you can
   also periodically download Kerberos acceptor credentials w/o having
   to write the the HDB (we call this a virtual host-based service
   principal namespace, where all possible host-based principals below
   the namespace "exist" with keys derived from the namespace's, the
   principal's keys, and current time chunked into epochs.

 - ease of access to authz data

   In GSS/Kerberos getting to authz-data is insanely hard.  In JWT it's
   just JSON, and all you need is a convention for object key naming.

We have a solution to the scaling problem in Heimdal, but for the latter
problem we really need a GSS_Inquire_context_authz_data() that outputs
JSON just like JWT.

Nico
--