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

["Alan DeKok" <aland@ox.org>]

Henrik Nordstrom <henrik@henriknordstrom.net> wrote:
> I brought up this question mainly to ask if the Digest extension to Radius 
> intentionally blocks session based Digest authentication (MD5-sess with 
> offload of authentication of further requests within the same session), or 
> if it is just an oversight thinking that Digest is only per-reqest 
> authentication.

  RADIUS *is* per-request authentication.  The dissonance here is that
HTTP has multiple "requests" for one "session".  We're trying to have
two different paradigms interact, which means one of them has to give.

> Personally I do not onsider cookie based session management approaches as 
> a viable alternative to Digest MD5-sess. Digest MD5-sess is a fully 
> specified protocol, while each cookie based session management apart from 
> requiring cookie support (which not all useragents supports or are willing 
> to support) each is implemented differently, and does not and will not 
> integrate well with non-interactive agents as the authentication is 
> effectively "out-of-band" in custom coded forms etc.

  Sure.  And RADIUS is a fully specified protocol with fully specified
behavior.  Pushing authentication credentials from the RADIUS server
to the client is a *major* change of the security model of RADIUS.

  If nothing else, I would like to know the full impact of making that
change to RADIUS before standardizing it.

> Digest MD5-sess has the opportunity of becoming a very functional 
> authentication model for HTTP only relying on standards. But enforcing a 
> roundtrip to the Radius server on each and every request is in my opinion 
> not an option as it is very unlikely to scale, and adds significant 
> latency to the provided service.

  I agree.

>  RADIUS is designed primarily with session authentication in mind,
> not message authentication. Digest MD5-sess unlike the other
> available authentication schemes for HTTP provides session based
> authentication within HTTP.

  Yes, but as I said previously, RADIUS currently authenticates a
session once.  There is *no* provision in RADIUS for a NAS re-sending
authentication requests for one session.  Therefore, the historical
method of mapping HTTP "sessions" to RADIUS was to treat each HTTP
request as a RADIUS "session", and send an authentication request.

  This doesn't scale, as you said.  Now, one protocol or the other has
to give, which is the source of the current discussion.

> It has been selected to at all include support for the Digest-HA1 
> attribute, opening the whole can of security issues involved here. As soon 
> as this is supported all the security implications of supporting MD5-sess 
> correctly is already there.

  Then maybe we need to re-visit the decision to include support for a
Digest-HA1 attribute.  I'm not flat-out opposed to it, but I am
opposed to changing the RADIUS security model without performing due
diligence.

> But perhaps it's due to different views of what MD5-sess is. In my view 
> MD5-sess allows for session based authentication within the message based 
> Digest protocol. The RADIUS server authenticates the session on the first 
> message exchange, and the "client" then verifies the validity of the 
> session in further message exchanges. I do not view this as pushing 
> authentication to the client, even if technically the algorithm used is 
> mostly the same but based on the authenticated MD5-sess H(A1) session key 
> rather than the plain password.

  It is giving the client access to authentication credentials it did
not previously have.  This *is* a change in behavior.

  The only reason that this method is being proposed is that one HTTP
"session" can involve multiple TCP/IP connections, spread over time.
Normal RADIUS client behavior is that the user session *is* the
connection to the user.  When the connection goes down, the session is
over.

> gaping security holes due to lack of standards and awareness on session 
> security, or be forced to have huge RADIUS server farms (including 
> directory backends) only to handle the authentication load.

  That's not fair.  If the HTTP server can cache H(A1), then the
RADIUS servers can, too.  There's no need to go to a directory
back-end for every request.  Give me 1/2 hour, and I can have that
implemented in FreeRADIUS, and people will be testing it in
deployments next week.

> ...
> sufficient grounds that it should be standardized. If not there is a high 
> risk many implementations gets it done wronly (such as exchanging H(A1) in 
> plain over untrusted links, or screwing up the nonce security 
> requirements).

  Such as sending H(A1) in the clear in a RADIUS packet?  The only
security difference between that and using a cookie is that the cookie
goes over the net, while the Digest-HA1 attribute is (generally) sent
within a controlled network.

  My reading of the radext issues archive indicates that there hasn't
been consensus over whether Digest-HA1 is a good idea.  It's *useful*,
there's no question there, but it has security issues, as the
discussion in the archive says.  The text that the attribute MUST NOT
be sent unless the RADIUS traffic is protected from eavesdropping is
just wishful thinking.  People will make the same mistakes deploying
this as they currently do for HTTP cookies.

  I wasn't following that conversation earlier, otherwise I probably
would have jumped in then.

  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/>