This is a very bad idea.  Even assuming Coda had sufficient crypto to
protect your user keying material, the ability to retrieve a Coda token
demonstrates nothing.  Recall that with kerberos PAM (which works on
similar shared secret principles), once you have retrieved a Kerberos
ticket, you still have to retrieve an authenticator for the local
rcmd/host key, and verify it against the local key.  Coda has no
equivilent to the local host key, so there is no way to verify that the
retrieved token is valid for anything :-).  You could spoof a Coda auth
server and the PAM module would have no way to tell that the spoofed token
retrieved did not come from a legitimate Coda auth server.  Coda
authentication is no intended to provide party-to-party authentication,
only client-to-coda-server authentication.

Encouraging your users to make use of the same keying material for local
access and their Coda access is a serious mistake.  Requiring it, and
suggesting others require it, is even worse.  I hope that no one is using
this module in any exposed network environment, and I suggest you mark it
as unsafe for use in any exposed network environment.  The unsafeness of
relying on Coda tokens for authentication to a service other than Coda
(i.e., the local machine) has been discussed previously on the mailing
list--you may want to go back and review these messages.

The current Kerberos extensions do allow safe use of keying material to
log in, and then acquire tickets, which can be used to acquire Coda
tokens without risking the original keying material, although it should be
observed that there are still the normal inherent security risks
associated with using Coda.  In a kerberos environment, with the kerberos
extensions to the Coda auth server in place, using kclog to retrieve Coda
tokens automatically is ``safe'', as long as that retrieval is not used to
authorize any local actions.

On Tue, 25 Jan 2000, Robin Gareus wrote:

> Hi there!
> 
> I hereby announce the first public release of a
> Pam Coda Module (2nd alpha Version), 
> available at
> 
> http://coda.uni-hd.de
> 
> pam_coda.so is a PAM-Authentication Module, that passes the users password
> to the Program clog. If clog sucessfully generates a token, this token is
> left and pam_coda returns a PAM_PERMIT. If no token could be generated a
> PAM_AUTH_ERR is returned.
> 
> 
> robin
> 
> -----------------------------------------------------------
> Robin Gareus
> Universitaetsrechenzentrum
> Im Neuenheimer Feld 293
> 69120 Heidelberg
> Email : robin.gareus_at_urz.uni-heidelberg.de
> Phone : 06221/54 4599
> -----------------------------------------------------------
> 
> 
> 
> 
> 
> 


  Robert N M Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services