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

["Bernard Aboba" <bernard_aboba@hotmail.com>]

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?

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/>