Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Jo Hermans <jo.hermans@gmail.com> Thu, 29 December 2005 19:53 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 29 Dec 2005 19:54:18 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BCND8foUD+SXMIVTidNkA2rlOTmpDV01Dzd7miRIr+EUap3CpmkxyOcd0DOwmczBviimPCCVhonHEoNJwYbLMX7oIxv5u3dF2qYcCWPEVqAxFyAqvWlZ83fG0Cjcom2FJdCohw+QEeSSThrqzGAeGktAi8NRZc8ceU68FdQka+s=
Message-ID: <a4ba2af60512291153w6256bb6ckd2186a12ff5ba27@mail.gmail.com>
Date: Thu, 29 Dec 2005 20:53:50 +0100
From: Jo Hermans <jo.hermans@gmail.com>
To: radiusext@ops.ietf.org
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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/>
- Re: Issue: draft-ietf-radext-digest-auth-06.txt D… Alan DeKok
- Re: Issue: draft-ietf-radext-digest-auth-06.txt D… Henrik Nordstrom
- Re: Issue: draft-ietf-radext-digest-auth-06.txt D… Alan DeKok
- Re: Issue: draft-ietf-radext-digest-auth-06.txt D… Henrik Nordstrom
- Re: Issue: draft-ietf-radext-digest-auth-06.txt D… Henrik Nordstrom
- Re: Issue: draft-ietf-radext-digest-auth-06.txt D… Jo Hermans
- Re: Issue: draft-ietf-radext-digest-auth-06.txt D… Alan DeKok
- Issue: draft-ietf-radext-digest-auth-06.txt Diges… Bernard Aboba
- RE: Issue: draft-ietf-radext-digest-auth-06.txt D… Avi Lior