On Thu, Oct 26, 2023 at 02:38:47PM -0400, Ken Hornstein via Kerberos wrote: > [...]
Kerberos is becoming less relevant in general because for most apps running over TLS and using bearer tokens over TLS is Good Enough and also Much Easier Than Using Kerberos (whether directly or via GSS). That means that GSS too is becoming less relevant. On the other hand you still have Microsoft's Active Directory insisting on Kerberos, and you still have a lack of support for SSHv2 w/ bearer tokens, and you yourself might not even have a bearer token issuer infrastructure you could use if SSHv2 could support it. 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. 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. 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. It's nice to not have to patch all the things and contribute patches upstream. Though because there's no open source universal authen. credential issuer bridge available the price one pays for not patching all the things is the cost of building and maintaining such a bridge. (The cost of operating such a bridge need not be significantly different from the cost of operating distinct JWT, OIDC, PKIX, and Kerberos issuers.) > >We accept PRs. > > I am SO many levels down from the people that manage the licenses that > figuring out how to file a PR upwards through the various levels of the > DoD would probably take me a few days (I don't have to convince RedHat > there's a problem, I have to convince those gatekeepers that there's > a problem first, that's where things go sideways). And those people are > the kind of people that as soon as the hear "MD5" and "FIPS mode" in > the same sentence, they're going to say, "THAT'S NOT ALLOWED". I feel you. I have had to deal with this sort of audit issue myself, and it's always a pain to convince an auditor that some particular thing that their book says is verboten is not security-relevant in this one case and should be permitted. I don't have the cycles to go do the hard-coding you need to satisfy your auditors. It's not that I don't care about that problem -- after all, I might have it myself eventually w.r.t. GSS-KEYEX. It's that I only touch GSS-KEYEX code once per biennium, and right now is not that time for me and I'm full up with other things. If now were that time I might add a table of OID->name mappings and have a ./configure switch for enabling (or disabling) use of MD5 for generating names for OIDs not included in that list. Therefore I have no problem with you not using SSHv2 GSS-KEYEX. Perhaps someone else wants to volunteer to solve your problem _now_ rather than later, but unfortunately it can't be me, not right now. Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
