On Wed, 11 Nov 1998, Elliot Lee wrote:

> On Wed, 11 Nov 1998, Robert Watson wrote:
> 
> > > 1) Is there any way to get Coda to do a clog upon login under Linux? 
> > > Perhaps this could be accomplished via PAM?
> > 
> > Due to the nature of the 'Coda Tokens', the auth server must know the
> > secret being used by the client (that is, their password) and be able to
> > associate it with the user account.  As I understand it, PAM does not have
> > an API call that goes: IHaveAUsernameGiveMeTheirSecret(), and in fact the
> > standard UNIX model of having one-way-hashed passwords prohibits this.
> 
> Correct me if I'm wrong, but what part of:
> 
> 	char *username, *password;
> 	pam_get_user(pamhandle, "Log in you bastard", &username);
> 	pam_get_item(pamhandle, PAM_AUTHTOK, &password);
> 	auth_server_authenticate(username, password);

So, it depends what database is backing the authentication system.  Coda
requires that it have a copy of the cleartext token in order to perform a
shared-secret based binding.  In the standard UNIX password file, the
password is irreversibly encrypted, and unless you have shadowing, the
encrypted password is publically available.  As such, the Auth server
cannot use a standard UNIX password file as a source of secrets.  

The clarify a little -- the RPC2 bind uses your shared secret as a key to
perform encryption.  The auth server uses its copy of the secret to
decrypt that message and verify the contents (this happens over the course
of four packets to prevent replay attacks, etc -- it is a variant of
Needham-Shroeder shared secret).  If PAM cannot provide you with the
secret, then you cannot decrypt the client's request.

On the other hand, as I believe Peter must be referring to, a PAM module
can be written that runs on the Coda *client* and uses the ability to
retrieve Coda tokens to authenticate the user to a local identity.  This
is a straight-forward process, and almost identical the the Kerberos PAM
module's procedure.  That is, if you can acquire tokens for the user using
their name and secret, and the secret can then decrypt the tokens, then
they must be legitimate, and can be allowed to log in, assuming local
policy permits that.


  Robert N Watson 

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/
robert@fledge.watson.org              http://www.watson.org/~robert/