On Sun, Aug 27, 2000 at 09:19:35AM -0700, Andrew Morgan wrote: > So what you are saying is that pre-authentication, there is a protocol > negotiation phase that includes an exchange that will define the > authentication scheme to be used. Basically yes, but one should note that this phase has the authentication embedded. If authentication fails, it begins again. Additionally, RFC 2228 provides for the possibility to authenticate again at any time during the session. FTP servers are not required to implement that, but they can. > You are saying that neither PAM nor GSSAPI nor anything 'generic' is > involved in this negotiation. Could you explain why 'in principle' a PAM > module couldn't handle this sequence? I refuse to do that. I tried three times, always ending up with several long paragraphs of detailed explanation of the FTP-SEC protocol and why your suggestion would mean to implement a good deal of that protocol in the PAM module and why that is a bad idea, but always ended up with holes that I knew could be fixed but only with another few paragraphs of explanation. Thats simply too much. Please read RFC 2228. Please try to step down from 'in principle' and try to make it 'in detail'. Look where the protocol assumes that something like PAM or GSSAPI fits (in the authentication loop) and why doing it anywhere else will create problems. I'm sure you'll see it. While you're at it, please note that defining a new scheme "PAM" and doing the authentication inside the auth loop would be almost completely effortless because the encapsulation added by the server in that case could be done with perfect ease inside a generic conversation function. This ease should be an indication of how much better that way of doing things would be. It should also serve as an example that GSSAPI and PAM is really fundamentally the same, because GSSAPI does it that way. > I'm sure there is something I am not understanding about this issue. In > the past, the way protocol negotiations tend to tangle up transport > layer encryption protocol and authentication protocol decisions seems to > be where the above scheme falls on its face. Is this the problem here? Just some problems: 1) seperating negotation from the mechanism itself, as outlined in your pam.d file, won't work. After one scheme fails, the next is tried and that involves another round of negotation. 2) FTP-SEC can re-start authentication at any time, from the client-side 3) when command channel confidentiality and/or integrity is negotiated, every FTP command is encapsulated in a cryptographic wrapper. GSSAPI has support API to faciliate that, PAM has not. -- Ingo Luetkebohle / 21st Century Digital Boy its easy to stop using Perl: I do it after every project
