On Wed, 11 Nov 1998, Elliot Lee wrote:

> > 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.
> 
> Oh yea, I think everyone else is thinking in this vein too :-)

Ah -- I was taking it for granted that this behavior could be implemented,
and that therefore it was a boring issue :-).

> OK, if you were thinking of having the auth server use PAM to do its
> checking, that is an interesting thought, but it sounds like the auth
> server is too tied into the auth database to be completely PAMifiable.
> 
> Perhaps if the auth database were abstracted enough to allow writing a PAM
> module for it, then the auth server could use the auth database API
> directly for decryption purposes, and then the actual "are they allowed to
> connect" check goes through PAM, which might then call the pam_codadb
> module as well as any other pam modules...

The problem is not the implementation of the auth server, but rather the
basic requirement that we use shared secret cryptography to establish a
session key.

The point of the cryptographic binding for RPC2 is to guarantee freshness
and uniqueness -- that we are not having old packets replayed at us
(either a long or short time ago).  The condition upon entrance into the
binding protocol is that both sides must share a secret (usually a
password in this context).  The init binding uses nonces and this shared
secret encryption to prove that both sides have the same secret, and in
such a way that only if they have the same secret does a) the binding
succeed, and b) the resulting session key be shared.  That is, you can
always detect a failed binding, and that in the case of a successful
binding, the two parties will share a session key, but that no one else
will have access to it unless they have the secret.

On the client, indeed the secret is available as it comes from the user.
But if you are using a module to on the server, PAM will accept the pair
(username+password) but cannot provide the password given just the
username, which is what would be required to allow the auth server to use
PAM to authenticate.

Now, if we use public/private key, etc, we can go beyond this model in
useful ways, but the computational expense of this is quite high, and we
then lose the benefit that you are looking for also, PAM module support.
In this environment, PAM would only work if it happens inside of a secure
tunnel -- but that relies on encryption and key negotiation having
happened already, and that means either you've already used shared secret,
or you have already used pk key setup.

I understand that TIS has an authentication protocol that is quite a bit
more flexible than PAM, although not something you would want users to
talk to directly.  It was associated with the fwtk, but I have never used
it so don't know much about it.  PAM is useful for some things, but not
for others.

  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/