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