[39241] in Kerberos
Re: help with OTP
daemon@ATHENA.MIT.EDU (Charles Hedrick via Kerberos)
Mon May 1 16:34:39 2023
To: Russ Allbery <eagle@eyrie.org>,
Ken Hornstein via Kerberos
<kerberos@mit.edu>
CC: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Date: Mon, 1 May 2023 20:29:31 +0000
Message-ID: <PH0PR14MB549307B0C36B735AE3375F33AA6E9@PH0PR14MB5493.namprd14.prod.outlook.com>
In-Reply-To: <871qk61nfo.fsf@hope.eyrie.org>
Content-Language: en-US
MIME-Version: 1.0
From: Charles Hedrick via Kerberos <kerberos@mit.edu>
Reply-To: Charles Hedrick <hedrick@rutgers.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Anonymous PKINIT works fine but requires certs to be distributed. Unless you're prepared to update every machine in the world every year, you pretty much have to use a cert that goes back to a commercial CA. But in that case you probably have to use the obscurely documented
pkinit_eku_checking = kpServerAuth
pkinit_kdc_hostname = kdc1.x.y
pkinit_kdc_hostname = kdc2.x.y
I can understand that a newcomer would find OTP pretty much impossible to set up in practice.
Furthermore, your applications have to be written for it. They can't use the normal krb5 API calls for getting a credential from a password. I actually wrote a LD_PRELOAD wrapper to make a normal application work.
________________________________
From: Kerberos <kerberos-bounces@mit.edu> on behalf of Russ Allbery <eagle@eyrie.org>
Sent: Wednesday, April 26, 2023 2:57 PM
To: Ken Hornstein via Kerberos <kerberos@mit.edu>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Subject: Re: help with OTP
Ken Hornstein via Kerberos <kerberos@mit.edu> writes:
> Well, dang, that's one for the toolbox! I was able to confirm that
> works just fine (but note I already had an existing PKINIT
> infrastructure to leverage). I will note that the existing
> documentation implies you could authenticate to WELLKNOWN/ANONYMOUS
> using your password, but maybe that isn't true? I'm specifically
> referring to the documentation for the '-n' option for kinit, the
> "second form" of anonymous tickets. There is a note that this isn't
> supported, but it mentions MIT Kerberos 1.8 so one could believe that
> note is out of date.
> This is kind of the giant mystery surrounding FAST. If you're not
> familiar with the gory details of the FAST protocol you're kind of left
> stumbling around to figure out what exactly you need to do. I realize
> this is probably because it's hard to write documentation for beginners
> (certainly I am guilty of this also); I'm only making this as a general
> observation.
I worked through a bunch of this for pam-krb5 back in the day and made it
support a set of reasonable things, including anonymous PKINIT to
establish the FAST armor. People who are working in this area may find
its source code useful to look at, although I think there have been
improvements since then and what it does may no longer be best practice.
https://github.com/rra/pam-krb5/blob/main/module/fast.c
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
________________________________________________
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
