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
proposing.
AND, this approach does not require that PAM be involved in the
negotiation phase of FTP, or any other protocol.
Here:
- 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
GSS-API?"
- FTPd says: "no" => pam_gss:pam_sm_authenticate() returns
PAM_FAIL or PAM_IGNORE
- 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
matter.
> 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.
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
>
Nico
--
