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

[Henrik Nordstrom <[e-mail]>]

On Thu, 29 Dec 2005, Alan DeKok wrote:

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

Sort of the same as for Digest MD5-sess. It shouldn't be viewed as 
authenticating the user on each and every request, only verifying the 
validity of the session.


It should be noted that the absolute majority of the people implementing 
cookie based authentication ontop of HTTP does not realize that the cookie 
as well is sensitive and access to the cookie allows for session theft. If 
you browse around a bit on sites implementing such schemes you will 
quickly find that while they often protect the authentication as such with 
transport level security (https) the session then most often continues 
without any encryption. Digest authentication does not share this problem 
as the security of the authentication is not relying on any transport 
level security.

Similarily there is a lot of places where end-to-end transport level 
security is not allowed. This includes several major corporations having 
as policy that all traffic must be decrypted at the border for inspection. 
Digest allows for this without any risk of compromise of the 
authentication as such, which is a big win compared to cookie based 
authentication.

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

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.

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.

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

However Digest authentication and MD5-sess session based authentication in 
particular has for a long time been held back mainly due to the lack of 
integration with authentication backends. It is my clear opinion that it 
would be very sad to pass this opportunity of finally standardizing an 
authentication integration method capable of supporting Digest MD5-sess, 
allowing HTTP authentication to finally evolve into something reliable, 
secure and performing, without having to resort to transport level 
encryption of plain text passwords and custom session management.

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

And I just don't get the reasoning behind this.

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.

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.

HTTP Digest MD5-sess is a standard, and with this radius extension we have 
the ability to let this authentication mode florish. If support for this 
does not get into RADIUS then MD5-sess will almost certainly never ever 
become what it was intended, and we all have to live with either custom 
session management systems with all the drawbacks, incompabilities, and 
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.

I think the evidence that there is a lot of people already doing MD5-sess 
session authentication using RADIUS, and even more planning to do so, and 
the fact that the proposed draft already have full support for MD5-sess 
authentication provided one knows the Digest protocol sufficiently well is 
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).

Regards
Henrik

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>