Kerberos OTP with FreeRadius

[Brennecke, Simon]

Hi again,


Aswering my own question:

https://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html


One has to add "anon_fast" to the line containing "pam_krb5.so" in /etc/pam.d/common-auth.


Thanks & regards

Simon

________________________________
From: Brennecke, Simon
Sent: Friday, July 14, 2017 10:32:03 AM
To: Benjamin Kaduk; Felix Weissbeck
Cc: kerberos at mit.edu
Subject: Re: Kerberos OTP with FreeRadius


Hi guys,


Thank you so much for your help!


I managed to get OTP running now.

Freeradius checks the password and the token against PAM.


The remeining problem is that it requires two steps:


kinit -c cache -n

kinit -p testuser1 -T cache


This does not work with my PAM setup on the client machines out-of-the-box.

I'm using "libpam-krb5" on Debian and openSuSE machines.

>From what I guess is that PAM only tries to do the second step without the FAST cache.


Any ideas?


Thanks & regards

Simon






________________________________
From: Benjamin Kaduk <kaduk at mit.edu>
Sent: Friday, July 7, 2017 2:07:34 PM
To: Felix Weissbeck
Cc: kerberos at mit.edu; Brennecke, Simon
Subject: Re: Kerberos OTP with FreeRadius

On Fri, Jul 07, 2017 at 11:04:47AM +0200, Felix Weissbeck wrote:
>
> The  "problem" hereby is, that you can now obtain a kerberos ticket with your
> second factor alone; so you could configure PAM to successfully authenticate
> with password+token.

Yes, the FAST/OTP preauthentication mechanism from RFC 6560 uses only
the OTP factor, which makes it a great solution if you already have
deployed OTP infrastructure and need to add a kerberos solution for
your site.  For using OTP as a second factor, it's not really an option.

The current thinking in this space is that the SPAKE preauth scheme
in https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/
will fill this void, allowing a second factor to be mixed in with a
PAKE password-based preauth, that does not expose anything encrypted
in password-based keys directly on the wire (so as to stymie brute-force
attacks).

-Ben