On Sun, Aug 27, 2000 at 09:19:35AM -0700, Andrew Morgan wrote: > Ingo Luetkebohle wrote: > > 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) > > 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. > > 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? [It looks like some sort of SASL > thing, and I remember previously concluding that PAM could support > that.] Andrew, in principle PAM could have a module that uses binary prompts to cooperate with the PAM app to handle negotiation issues in the protocol, but that seems overkill. As long as the PAM app knows about several authentication systems and its binary conversation function can deal with all of those, then it doesn't matter much wether the app handles negotiation on its own or not for all you can hope to gain from letting PAM drive the negotiation is to give the sysadmin the power to setup preferences. > > 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. > > Well, its not exactly pretty, but with a sufficiently cross-referenced > pam.d/XXX file, couldn't you have some sort of: > > auth requisite pam_negotiate.so "FTP server ready" > PLAIN GSSAPI > auth [default=1 success=IGNORE] pam_switch negotiate_key=GSSAPI > auth requisite pam_gss.so > auth [default=1 success=IGNORE] pam_switch negotiate_key=PLAIN > auth requisite pam_unix.so > auth requisite pam_deny.so > > 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? I think you can make this work, if you wish. If the protocol allows the client to drive the negotiation for an authentication protocol (i.e., client: "do you support GSS-API?", server: "yes" or "no") then it's hard to see how you could have a pam_negotiate be really effective. If, OTOH, the client says to the server "here's all the auth systems I support", or if the server asks the client what systems it supports, one by one till a match is found, then pam_negotiate could work. > Cheers > > Andrew > > Nico --
