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 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.
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!
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.
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.
While I'm on the subject of JWT, there are two reasons JWT is killing >Kerberos:
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.
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.
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.
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?
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.
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".
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.
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.
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.
[...]
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".
On Thu, Oct 26, 2023 at 3:41 PM Nico Williams <nico@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.
This is truly unfortunate, because we already have an onlike Kerberized CA that vends short-lived X.509 certificates
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.
On Thu, Oct 26, 2023 at 03:58:57PM -0400, Jeffrey Hutzelman wrote:
On Thu, Oct 26, 2023 at 3:41 PM Nico Williams <nico@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. [...]
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.
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.
Therefore I have no problem with you not using SSHv2 GSS-KEYEX.
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 _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).
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.
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).
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.
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?
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.
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
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.
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.
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:
[...]
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.
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.
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.
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.
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.
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 45:20:25 |
| Calls: | 6,910 |
| Files: | 12,377 |
| Messages: | 5,429,445 |