Re: NTLMSSP and Squid

On Saturday 10 May 2003 14.00, Robert Collins wrote:

> Due to limitations in the original helpers, they *had* to maintain
> a TCP session to the domain controller, and the challenges they
> issued came from the that controller - so the specific requests
> could not follow this pattern:
>
> negotiate->squid->helper 1
> helper1->squid->client
> client->squid->helper 2
> helper2 ->squid
>
> winbind, and AFAIK Guidos' helper, don't suffer from this issue.

It is true that the winbind approach does not need to suffer from this
if you modify the protocol to echo the CHALLENGE packet back to the
helper together with the AUTHENTICATE packet. However, such operation
can only operate when using a helper having direct access to the
domain trusted channel.

I strongly maintain that the above state should be kept in Squid. Not
keeping it would be silly.

Also, with the overlapping requests approach you get rid of the
resource problem of "locking" helpers.

> We *have* to know the handshake logic. Decoding the packets is
> orthogonal. (I wasn't suggesting decoding). Simply storing the
> base64 encoded challenge as we do today will do. And that *will* be
> needed to do efficient overlapping stateful requests anyway.

Storing the challenge is not sufficient. The helper may require other
state to be able to use the challenge.

The only helper which can do without keeping internal state and
instead using the CHALLENGE+AUTHENTICATE packets in combination is
the winbind helper, and this only because this helper has direct
access to a trusted channel where NTLM response+challente tuples can
be verified, and implements all (well, in reality almost none to be
honest) NTLMSSP functionality internally.

The win32 AcceptSecurityContext does not have direct access to the
domain trusted channel, and requires full state to be kept in memory
from start to finish in order to operate correcly, and this state is
not the CHALLENGE packet blob.

Regards
Henrik
Received on Sat May 10 2003 - 07:58:14 MDT