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

"Alan DeKok" <aland@ox.org> Fri, 30 December 2005 00:33 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 30 Dec 2005 00:29:01 +0000
From: Alan DeKok <aland@ox.org>
To: radiusext@ops.ietf.org, Henrik Nordstrom <henrik@henriknordstrom.net>
Subject: Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Date: Thu, 29 Dec 2005 19:33:57 -0500
Message-Id: <20051230003357.311CD16DD6@mail.nitros9.org>

Henrik Nordstrom <henrik@henriknordstrom.net> wrote:
> I assume you are aware that Digest MD5-sess iss running circles around the 
> above scheme in terms of security thanks to the replay protection provided 
> by the nonce-count in the Digest protocol. The above proposed scheme can 
> only be considered reasonably secure if combined with end-to-end transport 
> security (i.e. https for encryption). Even if using a more secure hash 
> than MD5 in your cookie is taken into account.

  It's security is limited by the fact that non-digest HTTP
authentication already sends the password in the clear.  So adding a
cookie to that changes little of the security, but lowers the
authentication impact on the RADIUS servers.  Breaking the cookie hash
depends on the size of the salt used, which can be large.  Once the
salt is past a certain size, other attacks become cheaper.

  As for the digest nonce replay protection, the goal of the cookie
scheme isn't to re-authenticate the user every time, but instead, to
validate their possession of a "magic token" that allows them access.
(And to avoid all evaluating subsequent authentications). The
authentication method used prior to giving them a magic token is
almost irrelevant.

  Used in conjunction with https, this method would have minimal
effect on security, and wouldn't require changes to RADIUS.

> I can do what I want with the proposed radius digest draft already, just 
> has to bend the RADIUS exchanges slightly as explained a few minutes ago. 
> The proposed changes is only to allow this to be done without lying to the 
> RADIUS server, and only as an optional feature.

  I'm not opposed to people doing it in site-local deployments.  I
think it can have significant benefits in controlled environments.  I
*am* opposed to standardizing it.

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