[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>