* John Nemeth <jnemeth@victoria.tc.ca> [1116 21:16]:
> On Apr 17,  5:57pm, Dick Davies wrote:
> } * Tillman Hodgson <tillman@seekingfire.com> [1103 22:03]:
> } > On Thu, Nov 25, 2004 at 04:52:39PM -0500, Greg A. Woods wrote:
> } 
> } My understanding of PAM/Kerberos is sketchy, but I assume the client
> } just blindly sends its user/pass to the server (which then gets a ticket
> 
>      The client would have to send whatever the server wants, which
> would be dictated by the protocol being used.  With my understanding of
> Kerberos, the client would only send the username to the server.  The
> server would send back some information encrypted with the user's
> password.

Kerberos doesn't rely on shared secrets like that.
There's a good walkthrough of Kerberos at:

http://www.isi.edu/~brian/security/kerberos.html
 
> } on the users behalf to validate the passphrase?), since
> } PAM is fundamentally user/pass based. 
> 
>      PAM is not fundamentally user/pass based.  It is in fact not based
> on any particular authentication method.

No, but every PAM module I've seen relies on a 'username' and 'password'
if you think of 'password' as 'string of bytes used to authenticate user'.
This isn't a good fit to ticket-based authentication. 

> } server identification (there are no tickets coming back from the 
> } server to the client). You'd have to rely on SSL CRLs to 'untrust'
> 
>      If you use Kerberos, you would get the appropriate information
> back.  You'd just have to have a secure way of storing the TGT so that
> different applications could get to it.

In practice i believe each server ends up holding a TGT (or more sensibly 
a service ticket) for each client that has authenticated to it with pam_krb5.
The point i'm making is with this setup I have to give my principal and
passphrase to a remote machine which I can't be sure is who it says it is.

> } I gave up and went to ldap auth - it has its warts but load balancing
> } works well, and it feels like a better match to pam, plus it does 
> 
>      PAM is fully modular and thus can use any protocol you want.

I'm not sure what your point is. i'm saying pam_krb5 is more of a hack than
pam_ldap, since an ldap bind is a better fit to pams mechanisms than asking
a server to  obtain a service ticket on your behalf (which is the only way to 
map user/pass (or whatever you prefer to call it) based authentication to
ticket based auth.

> } But the single password feature is definitely a double-edged sword,
> } especially when keyloggers are so prevalent. You need to be careful about
> 
>      Keyloggers would record all passwords entered, so it doesn't
> matter how many passwords are used, unless you restrict the places from
> which they can be entered.

What I mean is that with a single password for everything, the potential value of
a stolen password is much greater. If I use subversion from windows and
a keylogger steals the password, the attacker only gains access to other things
that use .htaccess. If I'm using mod_auth_ldap, the attacker has my ssh/pgsql/etc etc
password.


-- 
If we can hit that bull's-eye, the rest of the dominoes will fall like a
house of cards... Checkmate! - Zapp. Brannigan
Rasputin :: Jack of All Trades - Master of Nuns