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





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