The gss-keyex userauth method is just an optimization; it prevents you having to actually run the GSSAPI exchange again after you've already used one of the GSSAPI-based keyex methods. The real win is in the GSSAPI-based keyex methods themselves, which are useful (and exist) because they avoid having to pick one of these:
1. Jump in blindly and hope there's no MITM on the first connection 2. Distribute copies of all the host public keys to all possible clients 3. Operate a PKI for identifying hosts Of course, lots of people do (1); ssh has encouraged that since its earliest days. And around the time I was first working on what became RFC4462, I was also building 2-3 generations of tooling for (2). On Thu, Oct 26, 2023 at 5:59 PM Ken Hornstein via Kerberos <kerberos@mit.edu> 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. > > You know that. I know that. But remember: "if you're explaining, > you're losing". When asked I can honestly say, "Kerberos is not > a PKI" and that's good enough, but I can't say with a straight > face, "This X.509 CA over here is not a PKI". > > >Presumably OpenSSH CAs are a different story because they're not x.509? > :) > > Strangely enough, I am not aware of anyone in the DoD that uses OpenSSH > CAs (there probably are, I just don't know them). I could see it being > argued both ways. The people I know who use OpenSSH are (a) using > gssapi-with-mic like us, (b) just using passwords, or (c) using their > client smartcart key as a key for RSA authentication and they call that > "DOD PKI authentication". Again, you know and I know that isn't really > using PKI certificates, but the people up the chain aren't really smart > enough to understand the distinction; they see that you're using the > smartcard and that's good enough for them. > > >> 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? > > We _do_, it's just a pain to find an OCSP responder that can handle that > many. If the official ones go offline that breaks our KDC so we run our > own locally. > > >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. > > Right, part of the problem there is that people want to "use Kerberos > with ssh", and they don't understand the difference between gssapi-with-mic > and gss-keyex. > > --Ken > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos