Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
"Alan DeKok" <aland@ox.org> Thu, 29 December 2005 18:19 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 29 Dec 2005 18:14:34 +0000
From: Alan DeKok <aland@ox.org>
To: radiusext@ops.ietf.org, squid@henriknordstrom.net
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Date: Thu, 29 Dec 2005 13:19:24 -0500
Message-Id: <20051229181924.D31CF16DD6@mail.nitros9.org>
> 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 don't think there's any precedent in RADIUS for pushing authentication data to the client. I think it would be a significant change to the security model of the protocol. > 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). That's what cookies are for. See my "mod_auth_radius" for an implementation that authenticates the user once, and uses a cookie for the following HTTP sessions. The module isn't perfect (by any means), but the general concept goes like this: Session1 : get authentication data from the user pass to radius server if access-accept cookie = MD5(authentication data + secret + timestamp) + ... SessionN : get authentication data from the user validate cookie if cookie has expired or is invalid, re-auth the user else let them in. The cookie is formed as follows: an MD5 of data followed by some clear-text data used in the MD5 hash. I'd suggest using HMAC rather than MD5, though. The hash needs to contain the authentication data, to tie it to the session. It also needs to contain a per-server secret (e.g. data read from /dev/urandom at initialization time). The secret is really a salt, and ensures that the cookie can't be discovered via dictionary attacks. It also ties the cookie to an instance of the server, so if it restarts, the user must authenticate. The cookie also contains a timestamp, so that the server can force it to expire, because you don't trust the client to honor the expiry time. The timestamp is in the clear in the cookie, so that the server doesn't have to keep any per-session data. The timestamp is also used in the hash, to ensure that the client can't undetectably change the clear-text version of the timestamp. If the cookie gets too long, you can include only a portion of the hash in the cookie. That's a long-winded explanation, but I think it addresses your situation. I would very, very, much recommend against pushing authentication data to the client without a detailed security review of the implications. Since there are pre-existing methods for implementing what you want without changing RADIUS, I would recommend against changing RADIUS. Alan DeKok. -- 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