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

Basically yes, but one should note that this phase has the
authentication embedded. If authentication fails, it begins
again. Additionally, RFC 2228 provides for the possibility to
authenticate again at any time during the session. FTP servers are not
required to implement that, but they can.
 
> 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?

I refuse to do that. I tried three times, always ending up with
several long paragraphs of detailed explanation of the FTP-SEC
protocol and why your suggestion would mean to implement a good deal
of that protocol in the PAM module and why that is a bad idea, but
always ended up with holes that I knew could be fixed but only with
another few paragraphs of explanation. Thats simply too much.

Please read RFC 2228. Please try to step down from 'in principle' and
try to make it 'in detail'. Look where the protocol assumes that
something like PAM or GSSAPI fits (in the authentication loop) and why
doing it anywhere else will create problems. I'm sure you'll see
it. 

While you're at it, please note that defining a new scheme "PAM" and
doing the authentication inside the auth loop would be almost
completely effortless because the encapsulation added by the server in
that case could be done with perfect ease inside a generic
conversation function. This ease should be an indication of how much
better that way of doing things would be. It should also serve as an
example that GSSAPI and PAM is really fundamentally the same, because
GSSAPI does it that way.

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

Just some problems:

1) seperating negotation from the mechanism itself, as outlined in
your pam.d file, won't work. After one scheme fails, the next is tried
and that involves another round of negotation.

2) FTP-SEC can re-start authentication at any time, from the client-side

3) when command channel confidentiality and/or integrity is
negotiated, every FTP command is encapsulated in a cryptographic
wrapper. GSSAPI has support API to faciliate that, PAM has not.

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