Re: Digest 3rd party auth

On Wednesday 06 November 2002 01.49, Robert Collins wrote:

> > Right. Implementing MD5-sess is a bit pointless without a serious
> > context where it makes sense, but a first step would be to supply
> > server and client nounces in the HA1 helper request.
>
> I need to recheck the details, but IIRC I was going to run a
> separate helper format when doing 3rd party auth. An LDAP server
> module should be able to implement 3rd part auth quite well.

The difference is that the A1 is hashed with the initial nounces (both
client and server). This allows a secure exchange of the "HA1"
between the Digest authenticating application and the authentication
system as the exchanged hash is only valid for this session.

As for the helper protocol I see it can be done in two ways

a) "raw", where Squid calculates the server nounce and then gives both
the server and client nounces to the helper when the password hash is
required. This mode requires a secure authenticated channel between
the Squid helper and the auth backend to be regarded as reasonably
secure as the backend auth server then has no control of the quality
of the server nounces.

b) "stateful", where the external auth system generates the server
nounce. This mode can perhaps be regarded reasonably secure without a
secure authenticated channel.

Which of the two that makes sense depends on the capabilities of the
auth backend system. In both cases it need to provide special support
for HTTP Digest MD5-sess integration integration to make this work.

The other alternative I see without specific support for HTTP Digest
integration would be to offload the whole digest auth process to a
MD5-DIGEST capable server. MD5-DIGEST should be compatible with
HTTP/1.1 Digest.

Regards
Henrik

> snprintf(buf, 8192, "\"%s\":\"%s\"\n", digest_user->username,
> digest_request->realm);
>
> that is
> "user foo":"realm bar"
>
> It returns the hex encoded HA1.

Ok. Should probably use URL encoded strings as the basic auth protocol
to ease parsing and ensure there is no issues with " or : in the
username, but is obviously less sensitive than our old basic auth
protocol..

Regards
Henrik
Received on Wed Nov 06 2002 - 01:38:48 MST