[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-radext-digest-auth06.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
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:
3.1. RADIUS Client Behavior
here one may want to add a section describing this optional behavior of
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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.