Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess

[Jo Hermans <jo.hermans@gmail.com>]

On 12/29/05, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> Date: Thu, 29 Dec 2005 05:29:59 +0100 (CET)
> From: Henrik Nordstrom <squid@henriknordstrom.net>
> To: radiusext@ops.ietf.org
> Subject: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
>
> Has there been any thought of allowing RADIUS to be used for session based
> MD5-Sess authentication, where processing of further authentication within
> the same session is carried out by the radius client (i.e. HTTP
> server/proxy) rather than the RADIUS server?

I've implemented a scheme like this before, and will have to do soon
again (both in VOIP applications), but only when there was a strong
trust relationship between the radius client and the server, and only
to improve authentication-latency. There are serious security
implications caused by this. The transport can be protected with
IPSEC, and/or the attribute can be additionally encrypted or signed to
prevent snooping or spoofing. But that's not enough.

It should not be used together with MD5, since A1 is then
"user:password:realm", and this makes it too easy to use in later
authentications. MD5-sess is better, but the RADIUS-server can't know
how long the client is planning to use this session-key. Too bad we
can't use hashes that are only valid for a certain time.

Although it can be a good improvement in latency, I don't think that
we should standardize this.

>
> This is quite interesting in HTTP applications, where quite many requests
> can be seen within the same session and at a relatively high rate. (i.e.
> thousands of requests/second, for a active end-user population of a few
> thousands). Having the bulk of the authentication verifications carried
> out in the RADIUS client (HTTP server/proxy) can significantly reduce the
> load on the RADIUS server and greatly improve the request latency
> (quality) of the service provided.
>
> The principle behind this is that the MD5-sess hash A1 (Digest-HA1, aka
> 'session key' in RFC2617) attribute is given to the client (HTTP
> server/proxy) even if qop=auth (or perhaps even missing). This allows the
> HTTP server/proxy to internally process further requests in the same
> session (same server side nonce), considerably reducing the load on the
> RADIUS server.
>
> Today the wordings in draft-ietf-radext-digest-auth06.txt forbids this
> mode of operation, and one has to loop via qop=auth-int to fool the RADIUS
> server into a mode allowing for this, even if . The following quite modest
> changes is needed to allow for RADIUS to be used in such conditions:
>
> 1.3.  Overview
> 3.1.  RADIUS Client Behavior
>
> here one may want to add a section describing this optional behavior of
> the client.
>
> 3.2.  RADIUS Server Behavior
>
> Add the following condition
>
>     o  If the Digest-Qop attribute's value is 'auth' and the
>        Digest-Algorithm attribute's value is 'MD5-sess' the RADIUS
>        server MAY add a Digest-HA1 attribute into the Access-Accept
>        packet to allow the client to process further authentication
>        requests within the same session.
>
> 4.19.  Digest-HA1 attribute
>
> Here the qop related restriction on when this attribute may be sent needs
> to be dropped. Having restrictions here is also in large redundant with
> section 3.2 I think.
>
> For security reasons I would also add a recommendation to restrict the
> MD5-sess case (including qop=auth-int) to when the RADIUS server has
> generated the Digest-Nonce. Sending MD5-sess Digest-HA1 in the mode where
> the RADIUS client has generated the nonce allows for session theft if the
> attacker can listen to the external traffic and also query the RADIUS
> server, even if he can not see the traffic between the actual RADIUS
> client used and the RADIUS server.
>
> Regards
> Henrik
>
>
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>


--
Jo Hermans

"Eagles may soar, but weasels aren't sucked into jet engines"

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>