>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
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
>> 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
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
> > >
>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
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
>
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
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
>> 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
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
>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
>> 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
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
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
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
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
>> 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
>>
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
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
>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
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
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.
>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
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.
>
>
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
>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
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
>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
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
To give some background, we are required to do security scanning of our
systems using Tenable's security scanner product (which is variously
known as Nessus, Tenable.sc, or ACAS if you're in the DoD; I'm aware
that these all aren't the same thing but in practice they all seemed to
be lumped
30 matches
Mail list logo
