On Thu, Oct 26, 2023 at 3:41 PM Nico Williams <n...@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. This is truly unfortunate, because we already have an onlike Kerberized CA that vends short-lived X.509 certificates > 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. > 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. -- Jeff ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos