RFC 4121 & acceptor subkey use in MIC token generation

[Nico Williams]

On Thu, Oct 26, 2023 at 05:10:39PM -0400, Ken Hornstein via Kerberos wrote:
> 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; [...]

A CA that issues short-lived certificates (for keys that might be
software keys) is morally equivalent to a Kerberos KDC.  You ought to be
able to deploy such online CAs that issue only short-lived certs.

I understand how the politics of this works, so I'm just going to say
that I feel your pain.

Presumably OpenSSH CAs are a different story because they're not x.509?  :)

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

Don't you have OCSP responders?

See, that's the point of CAs that issue short-lived certificates: you
don't have to worry about revocation any more than you do with Kerberos
because tickets are short-lived.

(Though one can easily issue 10 year tickets too.  It's just that one
should not.  I'd like to say that I suspect that no one does, but I
don't want to find out otherwise...)

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

Right, that makes sense.

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

One of the problems I'm finding is that SSHv2 client implementations are
proliferating, and IDEs nowadays tend to come with one, and not one of
them supports GSS-KEYEX, though most of them support gssapi-with-mic, so
it makes you want to give up on GSS-KEYEX.

We have used GSS-KEYEX to do "credential cascading", and it's not enough
to support GSS-KEYEX for that: the client has to also schedule re-keys
to refresh the credentials delegated to the server.

We're starting to do something completely different: make it so the user
just does not need to delegate credentials.  Typically that is because
they are not even using ssh anymore but a tightly controlled and audited
system for accessing privileged accounts, or because they are accessing
a personal virtual home server, and in the latter case we'll ensure that
they have credentials there provided by an orchestration system -- in
neither case is credential delegation necessary, and certainly not
credential cascading.

Nico
--