RFC 4121 & acceptor subkey use in MIC token generation

[Ken Hornstein]

>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.

Unfortunately, ANOTHER one of the "fun" rules I live under is, "Thou
shall have no other PKI than the DoD PKI".  And as much as I can
legitimately argue for many of the unusual things that I do, I can't get
away with that one; we have to personally certify on all of our server
systems that we only accept DoD issued certificates.  The available DoD
certificate profiles are EXTREMELY limited and there's exactly zero
chance of me getting our own CA under the DoD PKI.  So I am aware of
kx509 and the like, but I can't use them.  Well, I technically COULD set
it up, I just couldn't trust a kx509 CA on any of our own systems so
the utility would be limited.

>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.

We _do_ do PKINIT with the DoD PKI today; that is relatively
straightforward with the exception of dealing with certificate
revocation (last time I checked the total size of the DOD CRL package
was approximately 8 million serial numbers, sigh).

>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.

We KIND do bridging, but it's at a higher level; since almost everyone
we deal with has an issued PKI client certificate on a smartcard we tend
to support a bunch of ways of working with that.  So you can use your
client certificate do a bunch of things like get a Kerberos ticket,
but we can't turn a Kerberos ticket into a DOD PKI client certificate.
There is an DoD program called "Purebred" to get DERIVED client PKI
credentials on things like iOS devices but that again has a very small
box it is designed to fit in and I doubt that the people who run it
would understand what I was asking, much less make it so I could put
those credentials in a kx509 server.  Sigh.

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

I mean, it seems like gssapi-with-mic is relatively widely supported
and works (with the previously-discussed exception of the broken-assed
Tenable client and Heimdal servers).

--Ken