> and examples are trivial -- just plain ftp/pop shows that > nicely. One little thought -- maybe we should think in > other direction -- i.e. correcting _protocols_ so that them > will work nicely with one centralized/well-managed "AAA" > infrastructure? :^8 (read: _BIG_ funny smailik here!) :) a data-transfer protocol's job is not to worry about the details of auth etc. ... that having been said, dce/rpc does have a function whereby the level of encryption / authentication can be obtained, for the purposes of, say _rejecting_ a session that is technically possible to perform encrypted or unencrypted, but for the purposes of _this_ specific session instance the server chooses not to accept it. the server chooses, not the authentication / encryption etc layer. however, for this to work, the api [for a server to query authentication / auth etc.] _should_ have been built in right from the start, otherwise you have to jemmy things in and pam is a good opportunity to do this. so, an alternative to modifying protocols like this is to "proxy" them over secureable transports. for example, ipsec. for example, ssl. consider this: in the light of the existence of secure transports, is it in fact pam's job to propose modifications to protocols to provide secure alternatives to those protocols? [the answer might be yes] lukes
