[39243] in Kerberos
Re: help with OTP
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Mon May 1 20:42:30 2023
Message-ID: <202305020037.3420bPbb014207@hedwig.cmf.nrl.navy.mil>
To: <kerberos@mit.edu>
In-Reply-To: <PH0PR14MB549307B0C36B735AE3375F33AA6E9@PH0PR14MB5493.namprd14.prod.outlook.com>
MIME-Version: 1.0
Date: Mon, 01 May 2023 20:37:23 -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
>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.
At least for us, we already did that hard work and have PKINIT already
working within the DoD PKI so anonymous PKINIT is trivial. But even
with the kpServerAuth flag you still need an EKU that is not in "normal"
commercial certificates, at least in my limited experience. The
frustrating thing for me is that in theory you can have the DOD PKI
issue a KDC certificate with the right extensions so you wouldn't even
need the pkinit_kdc_hostname lines but unfortunately the ASN.1 encoding
for that ends up being incorrect (I tried to get them to fix it but
sadly was unsuccessful).
>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.
Right, that was the OTHER piece I didn't quite understand at first
glance; it seems like the actual implementation was 70% complete in
terms of actual usability. At least I didn't miss anything there!
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
