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

[Henrik Nordstrom <[e-mail]>]

On Thu, 29 Dec 2005, Jo Hermans wrote:

> I've implemented a scheme like this before, and will have to do soon
> again (both in VOIP applications), but only when there was a strong
> trust relationship between the radius client and the server, and only
> to improve authentication-latency. There are serious security
> implications caused by this. The transport can be protected with
> IPSEC, and/or the attribute can be additionally encrypted or signed to
> prevent snooping or spoofing. But that's not enough.

In this regard it's no different than qop=auth-int in my view.

> It should not be used together with MD5, since A1 is then
> "user:password:realm", and this makes it too easy to use in later
> authentications. MD5-sess is better, but the RADIUS-server can't know
> how long the client is planning to use this session-key. Too bad we
> can't use hashes that are only valid for a certain time.

Granted, and is why my message was about MD5-sess only, and worded
carefully to restrict it to MD5-sess only.

Regarding session time, in setups using session authentication this is 
generally configured in the access server today anyway. The Radius 
authentication is for authenticating the session as such, not the 
individual requests. Digest as such already protects from replay attacs 
thanks to the nonce count (which any decent Digest implementation should 
track carefully), so the only real security threat here is eavesdropping 
of the MD5-sess hash between the RADIUS client and server as this could 
allow for session theft. This is no different from the qop=auth-int case 
already covered by the draft

Exception to the above: The combination of qop=auth-int + 
algorithm=MD5-sess and a Radius server (or client depending on mode of 
operation) only allowing a single request per nonce implicitly blocks any 
replay attacks thanks to the per request randomisation of the MD5-sess 
H(A1).

> Although it can be a good improvement in latency, I don't think that
> we should standardize this.

Any reasons besides the security implications which already exists in 
qop=auth-int exchanges of Digest-HA1?

Small sidenote fact: The RADIUS client can already gain access to what is 
required for MD5-sess session based authentication by faking the digest 
RADIUS request using qop=auth-int even if qop=auth is used in the 
communication to the end user agent. As this delegates the responsibility 
of creating the Digest-Response to the RADIUS client it is able to modify 
the qop (and even MD5/MD5-sess) to it's liking. The proposed change in 
wording only makes this support more explicitly visible without having to 
modify the digest parameters while talking to the RADIUS server to work 
around the restrictions in the draft..

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