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

["Alan DeKok" <aland@ox.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/>