On Thu, Oct 26, 2023 at 03:58:57PM -0400, Jeffrey Hutzelman wrote: > 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.
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 -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos