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
