[39234] in Kerberos
Re: help with OTP
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Wed Apr 26 11:33:47 2023
Message-ID: <202304261528.33QFSGrc012160@hedwig.cmf.nrl.navy.mil>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <7586f99f-1c5e-f8c9-e128-eb457508556b@mit.edu>
MIME-Version: 1.0
Date: Wed, 26 Apr 2023 11:28:16 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>On 4/25/23 20:01, Ken Hornstein via Kerberos wrote:
>> First, there's about 500x ways for PKINIT to go wrong, and when it does
>> go wrong 99% of the time you fall back to a password so it's hard to
>> figure out exactly what failed.
>
>Assuming the kadmin client and KDC are running 1.12 or later, you can
>create WELLKNOWN/ANONYMOUS with the -nokey option (instead of -randkey)
>to disable the password fallback. Or you can "kadmin.local purgekeys
>-all WELLKNOWN/ANONYMOUS" to remove the principal's long-term keys once
>it already exists. If this is done you should get PKINIT error messages
>from kinit -n if the KDC offered PKINIT and the client couldn't make it
>work, like this:
>[...]
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.
As a side note, it does occur to me that perhaps the simplest way to
integrate third-party OTP solutions into MIT Kerberos is to simply write
a bare-bones RADIUS server that does all of the magic you need to do
and point the existing OTP implementation at it; the RADIUS protocol is
relatively straightforward. It looks like writing your own OTP plugin
is in practice very difficult due to the dependency on calling the ASN.1
routines to encode and decode the OTP preauth data.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
