RFC 4121 & acceptor subkey use in MIC token generation

[Nico Williams]

On Thu, Oct 26, 2023 at 02:38:47PM -0400, Ken Hornstein via Kerberos wrote:
> [...]

Kerberos is becoming less relevant in general because for most apps
running over TLS and using bearer tokens over TLS is Good Enough and
also Much Easier Than Using Kerberos (whether directly or via GSS).
That means that GSS too is becoming less relevant.

On the other hand you still have Microsoft's Active Directory insisting
on Kerberos, and you still have a lack of support for SSHv2 w/ bearer
tokens, and you yourself might not even have a bearer token issuer
infrastructure you could use if SSHv2 could support it.

So what can you do?  Well, you could build an online kerberized CA that
vends short-lived OpenSSH-style certificates, then use that for SSH.

Perhaps you'll find that easier to do than to send a PR for hard-coding
mechanism OID->name mappings, and even if not, you may find it better
for the long term anyways because it's fewer patches to maintain.

Though credential delegation becomes hairy since all you can do then is
ssh-agent forwarding, and if you need Kerberos credentials on the target
end well, you won't get them unless you build yet another bridge where
you have your online kerberized CA vend certificates for use with PKINIT
so that you can kinit w/ PKINIT using a private key accessed over the
forwarded ssh-agent.

I'm a big proponent of authentication protocol bridging.  I've written
an online kerberized CA in Heimdal, though that one doesn't [yet] vend
OpenSSH-style certificates.  One site I'm familiar with has a kerberized
JWT, OIDC, and PKIX certificate issuer, and they support PKINIT, so they
can and do bridge all the tokens and all the Kerberos realms and all the
PKIX and soon OpenSSH CAs.

It's nice to not have to patch all the things and contribute patches
upstream.  Though because there's no open source universal authen.
credential issuer bridge available the price one pays for not patching
all the things is the cost of building and maintaining such a bridge.
(The cost of operating such a bridge need not be significantly different
from the cost of operating distinct JWT, OIDC, PKIX, and Kerberos
issuers.)

> >We accept PRs.
> 
> I am SO many levels down from the people that manage the licenses that
> figuring out how to file a PR upwards through the various levels of the
> DoD would probably take me a few days (I don't have to convince RedHat
> there's a problem, I have to convince those gatekeepers that there's
> a problem first, that's where things go sideways).  And those people are
> the kind of people that as soon as the hear "MD5" and "FIPS mode" in
> the same sentence, they're going to say, "THAT'S NOT ALLOWED".

I feel you.  I have had to deal with this sort of audit issue myself,
and it's always a pain to convince an auditor that some particular thing
that their book says is verboten is not security-relevant in this one
case and should be permitted.  I don't have the cycles to go do the
hard-coding you need to satisfy your auditors.  It's not that I don't
care about that problem -- after all, I might have it myself eventually
w.r.t. GSS-KEYEX.  It's that I only touch GSS-KEYEX code once per
biennium, and right now is not that time for me and I'm full up with
other things.  If now were that time I might add a table of OID->name
mappings and have a ./configure switch for enabling (or disabling) use
of MD5 for generating names for OIDs not included in that list.

Therefore I have no problem with you not using SSHv2 GSS-KEYEX.

Perhaps someone else wants to volunteer to solve your problem _now_
rather than later, but unfortunately it can't be me, not right now.

Nico
--