[39294] in Kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Fri Oct 27 14:01:45 2023
Message-ID: <202310271801.39RI15Ud018075@hedwig.cmf.nrl.navy.mil>
To: Simo Sorce <simo@redhat.com>
cc: kerberos@mit.edu
In-Reply-To: <48daa6105af9bb8794a0003e75ad7cd3fdf3c9e4.camel@redhat.com>
MIME-Version: 1.0
Date: Fri, 27 Oct 2023 14:01:05 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>> 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
