On Sat, Aug 26, 2000 at 11:20:58PM -0400, Nicolas Williams wrote: > And then imagine ftpd having a binary conversation function which > doesn't use the GSS-API C bindings at all (though it may have to know > how to, say, encode GSS-API tokens for use in the FTP protocol), or SRP, > or SOMETHING_ELSE. All ftpd would have to do is setup PAM (pam_start(), > maybe some pam_set_item() calls, etc...) then call pam_authenticate() > and let the pam_sm_authenticate() methods of the pam_gss et. al. modules > do the authentication work via the conversation function. *argh* So I understood it right the first time and not the second. Sorry for the confusion. Anyway, this all looks like you are trying to fit a square plug into a round hole. GSSAPI and PAM *do the same*. They are both an authentication framework for arbitrary algorithms. PAM is slightly more than that, but that does not make things better. Now, I'm going to look at your proposal from an application developers perspective. Heres what RFC 2228 makes me do (and many other protocols are similiar, for example IMAP is): S: FTP server ready C: AUTH PLAIN S: 534 Request denied for policy reasons. C: AUTH GSSAPI S: 335 ADAT=<base64 stuff> C: ADAT morebase64stuff S: [loop until security exchange is complete] (C is the client, S the server) This is meant to illustrate that, in FTP-SEC, client and server have a predefined and strict negotiation phase. The server knows which schemes it can accept (most servers can only support GSSAPI because thats enough), the client tries some until it gets one accepted and then they authenticate. PAM has absolutely no business to do during this negotation phase -- and GSSAPI does not have, either. GSSAPI then does a second negotiation phase that can't be seen here (its inside the auth loop), selecting which of the GSSAPI mechanisms (e.g., Kerberos V) are to be used and then it exchanges authentication information for the chosen one. This later exchange corresponds to the same thing that PAM does. To fit PAM into RFC 2228 would mean to invent a new scheme named "PAM" that uses binary prompts (and probably libpamc on the client) and can then negotiate whichever security scheme its modules support. *phew* I fear I'm repeating myself. Please try to digest the above. Try to leave the API designers seat and look how your suggestion would fit into the protocol exchange. I hope I could explain why integrating PAM and GSSAPI, in the way proposed, is superfluous. > If you only have to support GSS-API, then this approach should still > make for simpler code and it would make it easier to add something other > than GSS-API later. No, it wouldn't. You assume that PAM can select which of the mechanisms know to the FTP server is chosen. Well, it can't. It can only make *itself* be chosen and then do the rest inside the auth loop. -- Ingo Luetkebohle / 21st Century Digital Boy its easy to stop using Perl: I do it after every project
