RFC 4121 & acceptor subkey use in MIC token generation

[Nico Williams]

On Thu, Oct 26, 2023 at 03:58:57PM -0400, Jeffrey Hutzelman wrote:
> On Thu, Oct 26, 2023 at 3:41 PM Nico Williams <nico at cryptonector.com> wrote:
> > 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.
> 
> OpenSSH apparently does not support X.509 certificates because they believe
> there is too much complexity. This is roughly the same problem we had with
> getting GSS support into OpenSSH -- they are afraid of security technology
> they didn't invent.

For GSS-KEYEX they have a point: that the CNAME chasing behavior of
Kerberos libraries is problematic.  That said there is a simple fix:
use `gss_inquire_context()` to check that the name you got for the
target is the name you asked for, and else either disable credentials
forwarding and try again or refuse to use GSS-KEYEX.

OpenSSH-style certificates have several serious problems resulting from
NIH syndrome:

 - no certificate chaining, which therefore implies frequent updates of
   sshd_config and ssh_config files

 - authorization data is not encoded as an array of strings or blobs but
   as one string that uses commas to separate elements (!!) (!!!!)

 - it's all too specific to OpenSSH

 - there's no tooling to deal with short-lived user certificates on
   the client side

There are some good things about OpenSSH-style certificates, but the
above problems are serious missed opportunities.

> This is truly unfortunate, because we already have an onlike Kerberized CA
> that vends short-lived X.509 certificates

There's almost certainly lots of them.

> > 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.
> 
> The problem with this, of course, is that one must be careful not to permit
> credentials to be renewed indefinitely by simply having the KDC and KCA
> repeatedly issue new credentials. Fortunately, kx509 is careful not to
> issue certificates valid past the ticket lifetime, and I believe compliant
> PKINIT implementations don't issue tickets valid past the certificate "Not
> After" time.

Yes, it's absolutely essential to ensure that each credential issued is
limited in lifetime to the credential used to authenticate to the
bridge.  At least for client credentials.  It's not hard to get this
right, and it's not hard to test either.

Nico
--