Re: RFC 4121 & acceptor subkey use in MIC token generation
>Uh... If someone was able to swing that then you should be able to >swing use of MD5 for non-cryptographic purposes where a 20 year old RFC >requires it. But, I know, I know, never mind. You are assuming someone is looking at all of the STIGs and they're all logically consistent with each other. I think the reality is that whomever does the AAA STIG doesn't really look at or care about any of the others. >IDEA: Patch ssh to support use of x.509 certificates. > >After all, you can't use OpenSSH certs because... that's not "the DoD >PKI", and you can't use GSS-KEYEX because of the foregoing MD5 >non-issue, so might as well do the one thing you are allowed to do: use >the DoD PKI! Well, I _am_ allowed to use gssapi-with-mic (there's no rule against it, e.g. the "Air Bud" loophole), and as you note everything seems to support that, and honestly it seems to work completely fine. I'm not sure what having OpenSSH use X.509 certificates directly would get us, other than a huge pile of code that wasn't compatible with anything else. >And you're using Heimdal, right? Geez, you missed that part? No, we are pretty much an MIT shop. And judging by what I've seen it seems like so most of the DoD (at least on the Unix side of things). --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Fri, Oct 27, 2023 at 02:01:05PM -0400, Ken Hornstein via Kerberos wrote: > >Aren't you supposed to use CAC or PIV cards? > > Well, I hate to use the "Air Bud" loophole, but the rules as I > understand them don't ACTUALLY say that for ssh, and in some contexts > they explictly say that plaintext passwords are fine as long as you're > doing something like using a RADIUS server to verify the password. Yes, > the RADIUS protocol is terrible and has MD5 baked into the protocol and > no one has ever explained to me why the STIGS say FIPS mode is manditory > but RADIUS is fine. Uh... If someone was able to swing that then you should be able to swing use of MD5 for non-cryptographic purposes where a 20 year old RFC requires it. But, I know, I know, never mind. > >You can definitely use openssh clients with PIV cards and avoid > >kerberos altogether. > > I have done that! But that is actually TERRIBLE IMHO from a security > perspective unless you write a whole pile of infrastructure code; maybe > some sites actually do that but the people I've seen with that setup do > not and then get surprised when they get a new CAC and that breaks. If > you funnel all that through PKINIT then things are much nicer. IDEA: Patch ssh to support use of x.509 certificates. After all, you can't use OpenSSH certs because... that's not "the DoD PKI", and you can't use GSS-KEYEX because of the foregoing MD5 non-issue, so might as well do the one thing you are allowed to do: use the DoD PKI! And you're using Heimdal, right? Well, Heimdal has a very frickin' nice ASN.1 compiler that already has everything you need to be able to decode x.509 certificates. It even has a fantastic libhx509, though the only thing it doesn't have is support for x25519/x448 (I've a branch with that stuff I need to finish). Though you'll want to update to the as-yet unreleased master branch for this because it's more awesome there. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>> 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. > >Aren't you supposed to use CAC or PIV cards? Well, I hate to use the "Air Bud" loophole, but the rules as I understand them don't ACTUALLY say that for ssh, and in some contexts they explictly say that plaintext passwords are fine as long as you're doing something like using a RADIUS server to verify the password. Yes, the RADIUS protocol is terrible and has MD5 baked into the protocol and no one has ever explained to me why the STIGS say FIPS mode is manditory but RADIUS is fine. >You can definitely use openssh clients with PIV cards and avoid >kerberos altogether. I have done that! But that is actually TERRIBLE IMHO from a security perspective unless you write a whole pile of infrastructure code; maybe some sites actually do that but the people I've seen with that setup do not and then get surprised when they get a new CAC and that breaks. If you funnel all that through PKINIT then things are much nicer. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, 2023-10-26 at 17:57 -0400, Ken Hornstein via Kerberos 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. Aren't you supposed to use CAC or PIV cards? You can definitely use openssh clients with PIV cards and avoid kerberos altogether. Simo. -- Simo Sorce, DE @ RHEL Crypto Team, Red Hat, Inc Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>On Thu, Oct 26, 2023 at 05:57:37PM -0400, Ken Hornstein via Kerberos wrote: >> 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". > >Have you considered the private sector? Ha! My memory is the private sector is not perfect by any means and has a DIFFERENT set of foibles. >More seriously, there must be an office that could evaluate the use of >online CAs that issue short-lived certificates using issuer keys stored >in HSMs (or software keys when the sub-CA has a very narrow >applicability, meaning very few systems will trust it). Such CAs would >be very useful, I'm sure, especially if you could dispense with >revocation checking at the relying party because a) the certificate will >be as short-lived as a Kerberos ticket, b) the online issuer will have >checked revocation for the longer-lived credential used to authenticate >to it. I am sure there is some kind of process, but it would probably be some kind of trial program or research project that we could officially get approved. The main issues I see there is getting funding for such a project because that's not a small amount of work (I know the code is written; it's writing the proposals in a way so that everyone involved could understand what I am doing, why it would be useful, the security implications, sitting around in meeting with the various people to move the proposal up the chain, all of that grunt work) and like everyone else here my plate is full so I'm not sure where that fits into the schedule. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 06:26:18PM -0400, Jeffrey Hutzelman wrote: > 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: > > [...] All true. But you forgot the other benefit: automatic re-delegation of credentials prior to expiration. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 05:57:37PM -0400, Ken Hornstein via Kerberos wrote: > 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". Have you considered the private sector? More seriously, there must be an office that could evaluate the use of online CAs that issue short-lived certificates using issuer keys stored in HSMs (or software keys when the sub-CA has a very narrow applicability, meaning very few systems will trust it). Such CAs would be very useful, I'm sure, especially if you could dispense with revocation checking at the relying party because a) the certificate will be as short-lived as a Kerberos ticket, b) the online issuer will have checked revocation for the longer-lived credential used to authenticate to it. > >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. But it is _a_ form of PKI, just not x.509/PKIX PKI, thus the smiley. > >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. Ah, so what you mean is that you have a CRL replication problem. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
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 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
Re: RFC 4121 & acceptor subkey use in MIC token generation
>> 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
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 05:10:39PM -0400, Ken Hornstein via Kerberos 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. I understand how the politics of this works, so I'm just going to say that I feel your pain. Presumably OpenSSH CAs are a different story because they're not x.509? :) > 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? See, that's the point of CAs that issue short-lived certificates: you don't have to worry about revocation any more than you do with Kerberos because tickets are short-lived. (Though one can easily issue 10 year tickets too. It's just that one should not. I'd like to say that I suspect that no one does, but I don't want to find out otherwise...) > We KIND do bridging, but it's at a higher level; since almost everyone > we deal with has an issued PKI client certificate on a smartcard we tend > to support a bunch of ways of working with that. So you can use your > client certificate do a bunch of things like get a Kerberos ticket, > but we can't turn a Kerberos ticket into a DOD PKI client certificate. Right, that makes sense. > I mean, it seems like gssapi-with-mic is relatively widely supported > and works (with the previously-discussed exception of the broken-assed > Tenable client and Heimdal servers). 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. We have used GSS-KEYEX to do "credential cascading", and it's not enough to support GSS-KEYEX for that: the client has to also schedule re-keys to refresh the credentials delegated to the server. We're starting to do something completely different: make it so the user just does not need to delegate credentials. Typically that is because they are not even using ssh anymore but a tightly controlled and audited system for accessing privileged accounts, or because they are accessing a personal virtual home server, and in the latter case we'll ensure that they have credentials there provided by an orchestration system -- in neither case is credential delegation necessary, and certainly not credential cascading. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>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. 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; we have to personally certify on all of our server systems that we only accept DoD issued certificates. The available DoD certificate profiles are EXTREMELY limited and there's exactly zero chance of me getting our own CA under the DoD PKI. So I am aware of kx509 and the like, but I can't use them. Well, I technically COULD set it up, I just couldn't trust a kx509 CA on any of our own systems so the utility would be limited. >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. 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). >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. We KIND do bridging, but it's at a higher level; since almost everyone we deal with has an issued PKI client certificate on a smartcard we tend to support a bunch of ways of working with that. So you can use your client certificate do a bunch of things like get a Kerberos ticket, but we can't turn a Kerberos ticket into a DOD PKI client certificate. There is an DoD program called "Purebred" to get DERIVED client PKI credentials on things like iOS devices but that again has a very small box it is designed to fit in and I doubt that the people who run it would understand what I was asking, much less make it so I could put those credentials in a kx509 server. Sigh. >Therefore I have no problem with you not using SSHv2 GSS-KEYEX. I mean, it seems like gssapi-with-mic is relatively widely supported and works (with the previously-discussed exception of the broken-assed Tenable client and Heimdal servers). --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>> As a side note, my impression is that gss-keyex has fallen out of favor, >> and at least for us part of the problem is the unfortunate decision >> to use MD5 in that protocol. You and I both know that the use of MD5 >> in there isn't security related, but if you live in a FIPS world >> then any use of MD5 is a "challenge". > >What MD5? It's used for generating a mechanism name, which has no >security implications. You can hardcode the OID->name mappings so you >don't invoke MD5. Ever hear the political adage, "If you're explaining yourself, you're losing"?. The same adage applies when talking to security people, especially the non-technical ones. The common gss-keyex code out there calls the OpenSSL MD5 function at runtime, and some of the distributions that do ship the gss-keyex code (RedHat) decided to simply disable gss-keyex code when FIPS is turned on. So yes, you CAN hardcode the OID->name mappings, but it seems that nobody actually does that. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 03:22:17PM -0500, Nico Williams wrote: > On Thu, Oct 26, 2023 at 03:58:57PM -0400, Jeffrey Hutzelman wrote: > > On Thu, Oct 26, 2023 at 3:41 PM Nico Williams 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. [...] Also, they can run GSS and PKI code privsep'ed, though they'd need a way to do that on the client side too (on OpenBSD they have pledge(2) for that, but that's not portable). For PKIX they could just have used Heimdal's ASN.1 compiler, and fuzz the crap out of it (we do), and that would probably have been better than building a new certificate system. Though ideally we should be using memory-safe languages for all of this and leave C in the dust. That's just a long, slow slog though. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 03:58:57PM -0400, Jeffrey Hutzelman wrote: > On Thu, Oct 26, 2023 at 3:41 PM Nico Williams 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
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 3:41 PM Nico Williams 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
Re: RFC 4121 & acceptor subkey use in MIC token generation
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 Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>> Ever hear the political adage, "If you're explaining yourself, you're >> losing"?. The same adage applies when talking to security people, >> especially the non-technical ones. The common gss-keyex code out there >> calls the OpenSSL MD5 function at runtime, and some of the distributions >> that do ship the gss-keyex code (RedHat) decided to simply disable >> gss-keyex code when FIPS is turned on. So yes, you CAN hardcode the >> OID->name mappings, but it seems that nobody actually does that. > >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". --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 02:27:56PM -0400, Ken Hornstein wrote: > Ever hear the political adage, "If you're explaining yourself, you're > losing"?. The same adage applies when talking to security people, > especially the non-technical ones. The common gss-keyex code out there > calls the OpenSSL MD5 function at runtime, and some of the distributions > that do ship the gss-keyex code (RedHat) decided to simply disable > gss-keyex code when FIPS is turned on. So yes, you CAN hardcode the > OID->name mappings, but it seems that nobody actually does that. We accept PRs. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Thu, Oct 26, 2023 at 01:41:42PM -0400, Ken Hornstein via Kerberos wrote: > >Yeah; IIRC that was to allow cases where the initiator would send the first > >context token in the same packet/message with early data, such as a MIC > >binding the exchange to some channel. In retrospect, perhaps it has caused > >more trouble than it was worth. We didn't use this in RFC 4462 userauth, > >which doesn't use mutual anyway. > > As a side note, my impression is that gss-keyex has fallen out of favor, > and at least for us part of the problem is the unfortunate decision > to use MD5 in that protocol. You and I both know that the use of MD5 > in there isn't security related, but if you live in a FIPS world > then any use of MD5 is a "challenge". What MD5? It's used for generating a mechanism name, which has no security implications. You can hardcode the OID->name mappings so you don't invoke MD5. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>Yeah; IIRC that was to allow cases where the initiator would send the first >context token in the same packet/message with early data, such as a MIC >binding the exchange to some channel. In retrospect, perhaps it has caused >more trouble than it was worth. We didn't use this in RFC 4462 userauth, >which doesn't use mutual anyway. As a side note, my impression is that gss-keyex has fallen out of favor, and at least for us part of the problem is the unfortunate decision to use MD5 in that protocol. You and I both know that the use of MD5 in there isn't security related, but if you live in a FIPS world then any use of MD5 is a "challenge". --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Wed, Oct 25, 2023 at 08:51:29AM -0400, Ken Hornstein wrote: > >While I'm on the subject of JWT, there are two reasons JWT is killing > >Kerberos: > > Are you sure one of the most important reasons ISN'T that the GSSAPI is > insanely complicted and people who look at it get confused and move to > something else that is much simpler? At $WORK that's definitely not the reason. It's the others I listed, though the one about authz data is a flavor of the API complexity issue only much worse: because not only is it insanely hard to get at authz data when you can get at it, it's also often not possible at all. So not just insanely complex, but often-not-even-possible. And yet as simple as JWT is, it's also not: - HTTP user-agents need to know how to fetch the rock that the server asks them to fetch, and most of them don't know (Which is basically why OIDC exists.) This is fixable if anyone cares to bother, but then OIDC exists. - HTTP user-agents that do know how to fetch the rock don't do rock caching Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Wed, Oct 25, 2023 at 12:16:15PM -0400, Jeffrey Hutzelman wrote: > In any case, I think the behavior Ken is seeing is that the initiator > doesn't even assert a subkey -- it always uses the ticket session key. That > seems... unfortunate. That is. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>Yeah; IIRC that was to allow cases where the initiator would send the first >context token in the same packet/message with early data, such as a MIC >binding the exchange to some channel. In retrospect, perhaps it has caused >more trouble than it was worth. We didn't use this in RFC 4462 userauth, >which doesn't use mutual anyway. I mean, fair enough; I understand what Nico was saying as to the intention; my point is just that it seems that (a) MIT Kerberos only sets the PROT_READY flag when GSS_S_COMPLETE is returned, and Heimdal sets it ... never? At least that's what the MacOS X version of Heimdal seems to do. So if there ARE apps that actually look at the PROT_READY flag, it seems like at least if they're using Kerberos mechanisms they never actually will see it which makes me wonder if anyone ever actually tested this, ever. No idea what the GSS code in Microsoft will do. >In any case, I think the behavior Ken is seeing is that the initiator >doesn't even assert a subkey -- it always uses the ticket session key. That >seems... unfortunate. It's worse: the initiator doesn't assert a subkey (which I can personally live with) but also ignores the subkey asserted in the AP-REP, at least for ssh authentication code (there are comments that say they do look at the subkey when doing tests that involve SMB). Like I said, this works with MIT Kerberos because they don't actually enforce the RFC's MUST, based on (what I argued was wrong) a 20 year old comment. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Wed, Oct 25, 2023, 11:59 Nico Williams wrote: > On Wed, Oct 25, 2023 at 08:51:29AM -0400, Ken Hornstein wrote: > > I think we've lost the thread here; I do not think that any krb5 > > mechanism today ever asserts PROT_READY before GSS_S_COMPLETE, but I > > would love to be proven wrong. > > That's the whole point of being able to use the initiator sub-session > key: to allow the Kerberos GSS mechanism to assert PROT_READY on the > first call to GSS_Init_sec_context() even when mutual auth is requested. > > Yes, RFC 4121 didn't say so, but it's the point. > Yeah; IIRC that was to allow cases where the initiator would send the first context token in the same packet/message with early data, such as a MIC binding the exchange to some channel. In retrospect, perhaps it has caused more trouble than it was worth. We didn't use this in RFC 4462 userauth, which doesn't use mutual anyway. In any case, I think the behavior Ken is seeing is that the initiator doesn't even assert a subkey -- it always uses the ticket session key. That seems... unfortunate. -- Jeff > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Wed, Oct 25, 2023 at 08:51:29AM -0400, Ken Hornstein wrote: > I think we've lost the thread here; I do not think that any krb5 > mechanism today ever asserts PROT_READY before GSS_S_COMPLETE, but I > would love to be proven wrong. That's the whole point of being able to use the initiator sub-session key: to allow the Kerberos GSS mechanism to assert PROT_READY on the first call to GSS_Init_sec_context() even when mutual auth is requested. Yes, RFC 4121 didn't say so, but it's the point. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>Until then you don't know because GSS doesn't know if some MIC/Wrap >token it's consuming was made in response to an earlier MIC/Wrap/AP-REP >token sent by the acceptor application to the initiator. Also, in >practice no app that makes use of PROT_READY before GSS_S_COMPLETE on >the initiator side will do so for more than one or maybe two per-message >tokens (one for the app itself, and one for SPNEGO), so maybe we could >have a hard cap[*] on the number of per-message tokens using the >initiator sub-session key when the initiator requested mutual auth. I think we've lost the thread here; I do not think that any krb5 mechanism today ever asserts PROT_READY before GSS_S_COMPLETE, but I would love to be proven wrong. >While I'm on the subject of JWT, there are two reasons JWT is killing >Kerberos: Are you sure one of the most important reasons ISN'T that the GSSAPI is insanely complicted and people who look at it get confused and move to something else that is much simpler? --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On Tue, Oct 24, 2023 at 08:09:20PM -0400, Greg Hudson wrote: > On 10/24/23 15:50, Ken Hornstein via Kerberos wrote: > [Disputing the following comment in k5sealv3.c:] > > First, we can't really enforce the use of the acceptor's subkey, > > if we're the acceptor; the initiator may have sent messages > > before getting the subkey. We could probably enforce it if > > we're the initiator. Once you've seen a MIC/Wrap token made with the acceptor subkey you know that all subsequent sequence numbers must use the acceptor subkey. Until then you don't know because GSS doesn't know if some MIC/Wrap token it's consuming was made in response to an earlier MIC/Wrap/AP-REP token sent by the acceptor application to the initiator. Also, in practice no app that makes use of PROT_READY before GSS_S_COMPLETE on the initiator side will do so for more than one or maybe two per-message tokens (one for the app itself, and one for SPNEGO), so maybe we could have a hard cap[*] on the number of per-message tokens using the initiator sub-session key when the initiator requested mutual auth. So, yes, enforcement is tricky. But in practice it's probably not a problem because few apps make use of PROT_READY before GSS_S_COMPLETE on the initiator side -- that's a pretty lame reason to say this is not a problem... [*] Apps that don't request mutual auth, however, should get to send an unlimited number of per-message tokens using the initiator sub-session key because what else could they do? > I believe mutual authentication is frequently omitted for HTTP negotiate, > but that's a minor point as in that case there's no acceptor subkey. Yes. > Whether the initiator can generate per-message tokens before receiving the > subkey depends on whether the mechanism returned the prot_ready state (RFC > 2743 section 1.2.7) to the caller after generating the initiator token. RFC > 4121 does not mention prot_ready; I couldn't say whether that's an implicit > contraindication on setting the bit. I'm not aware of any krb5 mechs > setting the bit at that point in the initiator, although I recall Nico > talking about maybe wanting to do so. I'll have to check what MIT and Heimdal do. But yes, it'd be nice to be able to make use of PROT_READY when GSS_S_CONTINUE_NEEDED. Though GSS loses appeal every day, so we might never get to do a variety of interesting things in GSS space. Then again I know someone who badly wants a JWT client library that does krb5-style caching for audience-constrained JWT tokens, and we could always revive something like Luke Howard's BrowserID (a key exchanging GSS mechanism based on JWT) so that JWT could be used in application protocols where today it can't, and that might be interesting. While I'm on the subject of JWT, there are two reasons JWT is killing Kerberos: - scaling (which we've solved in Heimdal) To provision a server with Kerberos acceptor credentials is traditionally a real pain because orchestrating them requires writing to a database (the KDB). For JWT there's no provisioning, just a periodic download of fresh JWKs. Heimdal has a scheme where you can also periodically download Kerberos acceptor credentials w/o having to write the the HDB (we call this a virtual host-based service principal namespace, where all possible host-based principals below the namespace "exist" with keys derived from the namespace's, the principal's keys, and current time chunked into epochs. - ease of access to authz data In GSS/Kerberos getting to authz-data is insanely hard. In JWT it's just JSON, and all you need is a convention for object key naming. We have a solution to the scaling problem in Heimdal, but for the latter problem we really need a GSS_Inquire_context_authz_data() that outputs JSON just like JWT. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
>Whether the initiator can generate per-message tokens before receiving >the subkey depends on whether the mechanism returned the prot_ready >state (RFC 2743 section 1.2.7) to the caller after generating the >initiator token. RFC 4121 does not mention prot_ready; I couldn't say >whether that's an implicit contraindication on setting the bit. I'm not >aware of any krb5 mechs setting the bit at that point in the initiator, >although I recall Nico talking about maybe wanting to do so. Fair enough; every time I think I might understand the GSSAPI, there is always something else in that mess. I don't think given subkey negotiation it would be possible for a krb5 mechanism to legitimately set prot_ready before authentication was complete, but it sure seems like this is a corner case. Certainly it seems like Heimdal always assumes that the other end will behave that way. >The comment was written twenty years ago by a developer no longer >working for MIT, and I don't recall having any conversations about it >before this one. NOW I feel old :-/ --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
On 10/24/23 15:50, Ken Hornstein via Kerberos wrote: [Disputing the following comment in k5sealv3.c:] First, we can't really enforce the use of the acceptor's subkey, if we're the acceptor; the initiator may have sent messages before getting the subkey. We could probably enforce it if we're the initiator. I was under the impression that when you're doing mutual authentication (which in my experience is pretty much all of the time) you can't send any other GSSAPI tokens until authentication is complete and if authentication is complete then you can definiteley be assured any subkeys have already been exchanged. Clearly Heimdal enforces this and other than this obviously wrong client code I am not aware of any operational issues. Am I wrong? I admit that is always a possibility! I believe mutual authentication is frequently omitted for HTTP negotiate, but that's a minor point as in that case there's no acceptor subkey. Whether the initiator can generate per-message tokens before receiving the subkey depends on whether the mechanism returned the prot_ready state (RFC 2743 section 1.2.7) to the caller after generating the initiator token. RFC 4121 does not mention prot_ready; I couldn't say whether that's an implicit contraindication on setting the bit. I'm not aware of any krb5 mechs setting the bit at that point in the initiator, although I recall Nico talking about maybe wanting to do so. The comment was written twenty years ago by a developer no longer working for MIT, and I don't recall having any conversations about it before this one. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
