[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 7: Message-Authenticator?



Wolfgang Beck said:

"Issue 7

My interpretation of the list discussion was that the consensus was to
make the Message-Authenticator mandatory. I'll copy the relevant parts
of section 3.1 and 3.2 of RfC3579, as Bernard proposed.

I don't think that integrity protection of Access-Requests is really
a big issue. Carrying HTTP Digest over unprotected RADIUS can't be
worse than carrying it over unprotected HTTP or SIP. Digest-HA1 is the
only exception, because a MITM can 'sign' arbitrary HTTP-style responses.

Here is a proposal:
- Message-Authenticator is optional
- Digest-HA1 MUST be encrypted like User-Password, using a shared key.
That means, Digest-HA1 can be used with MD5, AKAv1-MD5; reliance
on IPSec is no longer needed (the requirement remains with sips /
https where all attributes would have to be encrypted)."

On Issue 7, Avi posted a proposal, so far the reaction seems to be
favorable.  But we will wait a bit longer before judging consensus.

In terms of the threats, Access-Request vulnerabilities generally are
of the DoS, dictionary attack and bidding down type.  Without a
Message-Authenticator, an attacker can send many Requests and try to do a
dictionary attack on the user password.  With the capabilities negotiation
features we're talking about, forging Access-Request messages can convince
the RADIUS server to lower the level of security (e.g. no filters, etc.).

In terms of encryption, there is again the issue of what encryption to
use.  The stream cipher used in RFC 2865, 2868 and 2548 is vulnerable to a
known plaintext attack a la WEP.  While the Request Authenticator space is
a lot larger in RADIUS, RADIUS password hygene is notoriously bad, and if
on top of that the Request Authenticator doesn't satisfy the global and
temporal uniqueness requirements of RFC 2865, then the Request
Authenticator could repeat with the same shared secret.  This allows
encrypted attributes to be decrypted.

So overall the problems with MD5-based keywrap are considerably more
serious than the concerns over cracking of HMAC-MD5, in that the attacks
have been documented.


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