On Sun, Aug 27, 2000 at 07:57:54PM +0200, Ingo Luetkebohle wrote: > 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. FTPd can easily call pam_close_session(), pam_end() and then start all over with PAM when the client wishes to re-authenticate or when a timer (or something else) goes off in the server that indicates the client should re-authenticate. Actually, there is no requirement that the session be closed and a new PAM handle be opened, I don't think; pam_authenticate() should be allowed to be called after the session is open, though it might be hard to deal with any change in the client's ID. > > 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. My proposal does not require that PAM or PAM modules know anything about the PAM application's protocols. The PAM application's binary prompt conversation function, supplied to PAM before calling pam_authenticate() does have to understand the protocols, but then, it belongs to the app, so that's ok. PAM would remain protocol agnostic. > 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. This IS what I'm proposing. The server provides the conversation function; PAM provides the modules which use that conversation function. GSS-API and PAM are NOT fundamentally the same. GSS-API is simply a way of encapsulating the authentication token exchange process for any authentication system. PAM binary prompts certainly sound similar to GSS-APi, but there's some big differences: - PAM is a server-side only thing; the client still has to access GSS-API directly in my proposal - PAM is AAA, GSS-API is A - PAM does session management > > 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. Nope. See my other post tonight on this topic. > 2) FTP-SEC can re-start authentication at any time, from the client-side Ok. See above. > 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. Yes. This is quite true. I think the PAM app needs to be able to get at the GSS-API context resulting from authentication. This is one reason I suggested making pam_set_data()/pam_get_data() available to the application, not just the modules. Then the application could use pam_get_data() to try to get at the GSS context, and would succeed if one was indeed established. Once the app obtained the GSS context it could use the GSS-API facilities for integrity and privacy. > -- > Ingo Luetkebohle / 21st Century Digital Boy > > Nico --
