[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: XSSO? How to communicate to XSSO/PAM external authentication info?

On Sun, Aug 27, 2000 at 09:19:35AM -0700, Andrew Morgan wrote:
> Ingo Luetkebohle wrote:
> > S: FTP server ready
> > S: 534 Request denied for policy reasons.
> > 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

> > 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"
> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []