draft-ietf-radext-digest-auth06.txt Digest MD5-sess

[Henrik Nordstrom <[e-mail]>]

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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>