Re: Squid NTLMSSP helpers

On Sun, 2003-05-11 at 21:26, Henrik Nordstrom wrote:
> On 11 May 2003, Andrew Bartlett wrote:
>
> > The way I figure it is that it's easier for Samba to track a relatively
> > simple, documented, stdio interface, than it would be for Squid to track
> > Samba's guts :-).
>
> It is, and until we don't need to track Samba's guts any more the helper
> belongs in Samba :-)

:-)

> > I figure if you can manage to give me a heads-up before you change the
> > squid->helper protocol, we should be able to keep current Samba releases
> > working with current Squid releases without particular pain.
>
> Yes, I believe so.
>
> The first change we are going to do is the overlapping requests change,
> allowing the helper to maintain multiple challenges. This will use the
> exact same protocol as today but prefixed with an integer. This is
> scheduled to happen within the next few weeks (before the end of the
> month).

Good. I'll bug the team member who was going to add it to ntlm_auth, or
do it myself (it's not exactly hard :-).

Do we have a 'shutdown' packet for a selected 'channel id'? Or will
squid just use numbers 1-x (where x is the limit of concurrency).

> Second (for Squid-3.1), the protocol should be extended with
>
> a) Supplying the NEGOTIATE packet (we might do this in 3.0 if challenge
> reuses is disabled.. thinking of it we probably should)

Please yes :-). Just after the YR would do well :-)

> b) Having the helper return the user credentials on successful
> authentication, saving Squid from looking into the guts of the NTLMSSP
> packets.

We already return the username...

I intend to return the username, in the form that the DC told us in it's
reply, at some point. But for now it's just as parsed, in UTF8.

> And as part of this the protocol may be restructured slightly to better
> reflect the fact that Squid does no longer know the details of
> NTLMSSP blobs and only tracks the connection state. I.e. something like:
>
> 1. New NTLMSSP session request, preferably including a NEGOTIATE packet
>
> 2. NTLMSSP exchanges, Squid waiting for helper to indicate
> success/failure.
>
> 3. Helper returns a terminal sucess/failure status, including ASCII user
> credentials where applicable and a suitable error message on failures.
>
> 4. Squid may at any point request to have the NTLMSSP session aborted,
> usually due to the client aborting his connection.
>
> Details of such protocol not yet specified. If you have a suggestion this
> may well be selected.

Samba's existing ntlm_auth already assumes this scheme. YR indicates
that any previous session should be abandoned, and a new session
started. Any other command is just taken to be a continuation of the
current session. The ntlm_auth layer doesn't know what's in these
packets, and just passes them into the NTLMSSP code, without annotation.

All NTLMSSP replies are coded "TT". Errors may be returned at any
stage.

> Note: It should be possible to use the same Squid helper protocol for
> SPNEGO authentication, which in terms of HTTP is very similar to NTLM(SSP)
> but may involve additional exchanges.

This should be easy. There just needs to be a space in the protocol to
tell the helper what scheme "NTLM" or "NEGOTIATE" was used.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet@samba.org
Student Network Administrator, Hawker College   abartlet@hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net