[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 03:04:57PM +0200, Ingo Luetkebohle wrote:
> On Sat, Aug 26, 2000 at 11:20:58PM -0400, Nicolas Williams wrote:
> *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.

No, I'm trying to allow PAM to make decisions based on GSS-API
authentication information. Considering all the possibile authentication
systems I think the most generic approach is the one I'm currently

AND, this approach does not require that PAM be involved in the
negotiation phase of FTP, or any other protocol.


 - FTPd accepts connection

 - FTPd and client negotiate authentication

 - FTPd starts and setups PAM (pam_start(), set conversation callback
   function, etc...)

 - FTPd calls pam_authenticate()

    - PAM calls pam_sm_authenticate() for each module in the stack

       - pam_gss' pam_sm_authenticate() prompts FTPd: "are we doing

	  - FTPd says: "no" => pam_gss:pam_sm_authenticate() returns

	  - FTPd says: "yes" => pam_gss starts prompting for GSS-API
	    tokens exchanges with the client

	     - GSS-API auth completes, pam_gss:pam_sm_authenticate()
	       returns PAM_SUCCESS

Now, going back to the pam.conf snippet I showed before, if pam_gss
fails or returns PAM_IGNORE, then PAM goes on the next module, and so
on, as PAM is wont to do, until pam_authenticate() succeeds or fails.

So you can see that this approach does not affect the way authentication
is negotiated in the FTP protocol, or any other protocol, for that

> 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
> 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)
> 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.

Agreed. See above.

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

I already had. I thought one of my previous posts made it clear that
FTPd would call pam_authenticate() only after negotiating what auth
system to use.

See, pam_gss won't know how the PAM app is obtaining the answer to any
binary prompt pam_gss issues. When pam_gss prompts for "are we doing
GSS-API auth?" the server may or may not know the answer. In the case of
FTP the daemon would have to already know the answer; for some other
protocol where the server drives the negotiation the app may have to
relay the "are we doing GSS-API auth?" prompt to the client. To the PAM
module it's all the same.

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

Again. See above.

> -- 
> Ingo Luetkebohle / 21st Century Digital Boy


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