[39020] in Kerberos
Re: 2FA with krb5
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Oct 8 11:48:51 2021
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, Dan Mahoney <danm@prime.gushi.org>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <57149257-8cdc-bd5f-8ce3-5457c6b25e59@mit.edu>
Date: Fri, 8 Oct 2021 11:45:51 -0400
MIME-Version: 1.0
In-Reply-To: <202110081145.198Bj6o0012853@hedwig.cmf.nrl.navy.mil>
Content-Language: en-US
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 10/8/21 7:45 AM, Ken Hornstein wrote:
>> I mean, this might be dumb, but why not have the kdc able to speak to
>> pam modules directly?
> Kerberos is "I am going to take your password which I already know,
> convert it into an encryption key, and use it to verify your Kerberos
> request". Kerberos needs to know the password/factor to make that
> happen, where the typical 2FA API only tells you "is this token good
> or not?".
I think Dan was assuming one of the cases where the KDC received a 2FA
value and needs an oracle, such as FAST OTP.
One concern is that PAM modules must operate synchronously (unless I'm
badly mistaken), so the KDC process would be blocked if the module has
to talk to a remote server. You can get away with that if your
population of 2FA users is small and the oracle is fast, but OTP oracles
are often deliberately slow to answer. We developed an async kdcpreauth
interface and async RADIUS code to address that problem for FAST OTP.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
