(Illustration by Gaich Muramatsu)
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/Received on 1998-11-12 00:38:54