RE: Issue with SIP - Need for Message-Authenticator

["Randy Chou" <rchou@arubanetworks.com>]

If you're referring to the recent collisions found in MD5 and SHA-0,
here are a few points:

- Many believe that it's just a matter of time before a collision is
found in SHA-1.
- nothing indicates that the collisions affect HMAC-MD5.
- The more important (weakest link) in Radius is actually the response
authenticator which uses plain MD5.  If the method used in finding the
collision (diff analysis) can somehow speed up the cracking of the
RADIUS shared secret, it doesn't make any difference how the message
authenticator is arrived at.
- On the other hand, if someone has figured out how to crack this, it's
unlikely that the attack will be released to the public anytime soon due
to disclosure requirements :).

Any of these hashes coupled with a static shared key is an accident
waiting to happen.  The real fix IMO would be to derive encryption and
authentication keys through  assymetric encryption (use IKE/IPSEC, TLS,
...).  There's no point in patching it with HMAC-SHA1, might as well
leave it as is for compatibility.  The gain is minimal.

Regards,
 
--
Randy


-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Joseph Salowey
Sent: Thursday, August 26, 2004 10:01 AM
To: 'Bernard Aboba'; 'Avi Lior'
Cc: 'Beck01, Wolfgang'; radiusext@ops.ietf.org
Subject: RE: Issue with SIP - Need for Message-Authenticator


owner-radiusext@ops.ietf.org wrote:
> Thanks for pointing this out Avi.  Here is what it says in Section 
> 5.19 of RFC 2869:
> 
>    An Access-Request that contains either a User-Password or
>    CHAP-Password or ARAP-Password or one or more EAP-Message
>    attributes MUST NOT contain more than one type of those four 
> attributes.  If it
>    does not contain any of those four attributes, it SHOULD contain a
>    Message-Authenticator.  If any packet type contains an EAP-Message
>    attribute it MUST also contain a Message-Authenticator.
> 
> Note that Message-Authenticator is based on HMAC-MD5.  Recent research

> has demonstrated collisions in MD5 (though not in HMAC-MD5), so that 
> it may make sense to define a new attribute that uses a more highly 
> regarded algorithm, such as HMAC-SHA1.

[Joe] See
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt,
this defines an attribute that can SHA for message authentication.  

> 
> On Thu, 26 Aug 2004, Avi Lior wrote:
> 
>> Wolfgang,
>> 
>> In the SIP doc I think you need to use Message-Authenticator(80) in 
>> the access request.
>> 
>> The problem is this:  without using a field such as CHAP-Password or 
>> Password, the RADIUS server has no way to validate that the 
>> Access-Request is arriving from a valid NAS.
>> 
>> Message-Authenticator(80) is used to provide integrity protection for

>> the entire Access-Request packet and can be used by the RADIUS Server

>> to validate that the packet was received from a known Client (since 
>> the Message-Authenticator uses a shared secret shared by the
>> Client-Server.)
>> 


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



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

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