Re: mod_auth_kerb and Squid proxy

mån 2006-11-13 klockan 09:26 +0100 skrev Daniel Kouril:

> this your mail got too burried too deeply in my mailbox, sorry for not
> responding earlier. If you're still interested in the SPNEGO/Basic (krb5
> passwords verification) support, I'd be happy to contribute a code for Squid.
> However, I don't know the code of Squid or have much time to learn it, so it
> would be nice if you provided me with a more detailed description of what
> needs to be changed and where I should start looking at.

What we need is a helper application which understands the
authentication protocol, nothing more. All the HTTP header stuff is
managed by Squid. This helper process is running separate from Squid and
is reading authentication exchanges on stdin and sending responses on
stdout using a simple text based protocol.

For Basic the interface is simply

REQUEST : username<space>password<nl>
RESPONSE: OK/ERR[<sp>Error message]<nl>

where username & password is URL-encoded.

An alternative more effective protocol is also available where the
requests/responses is prefixed by a tag binding the request and response
uniquely together.

REQUEST : tag<sp>username<sp>password<nl>
RESPONSE: tag<sp>OK/ERR[<sp>Error message]<nl>

in this format it's important the helper doesn't discard unprocessed
input as there may be a long queue of requests waiting on stdin. This
mode of operation is intended for helpers which can process multiple
requests in parallel, but it also helps a lot for single request helpers
as well as it allows Squid to queue multiple requests to the same helper
instance.

For SPNEGO the interface is slightly more complex due to the multistage
nature of the protocol. If you know Samba ntlm_auth
--helper-protocol=gss-spnego then this is the helper protocol we use.
This protocol is based on the protocol we designed for NTLM
authentication helpers many years ago, but slightly different to adopt
for the requirements of SPNEGO.

REQUEST : <command><sp><base64spnegoblob><nl>
RESPONSE: <response><sp><base64spnegoblob|*>[<sp><details>]<nl>

commands:

YR Start of a new Negotiate/SPNEGO handshake.

KK Additional handshake from the client

responses:

AF Authentication successful. The returned details indicate the username
in ASCII or UTF-8 encoding (not UTF-16).

TT Authentication not yet finished. Challenge or additional blob to send
to the client.

NA Permanent failure. Invalid credentials, request not understood, or
some other permanent problem processing the request. Details contain an
error message describing the condition.

BH Temporary failure, for example communication error.

* may be used as a placeholder for the spnego blob if no blob is
available.

As for Basic there is plans to introduce the tagged request/response
format for these helpers as well, in which case the helper is expected
to be able to handle multiple challenge/response channels identified by
their tag, and optimally to be able to process multiple requests in
parallel (at most one per channel).

> Also I don't know
> what is the situation on the client side and what HTTP clients provide
> support for SPNEGO authN against proxies. I believe the Gecko-based browser
> support that but not sure.

It's not too bad these days I am told.

MSIE since MSIC 7 supports it. Or at least the Vista version.

Current versions of Firefox also supports it, but maybe not enabled by
default.

We have also noticed Microsoft has introduced a "Kerberos" HTTP
authentication scheme. The details of this scheme is still unknown to
us, but we expect it to be raw GSSAPI exchanges not wrapped in SPNEGO.

Regards
Henrik