Re: Submission for RADIUS extensions working group

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

Thanks for the feedback.  Here are my comments...

> A draft discussing faulty implementations, by name, would be useful.
> So would problem reports to the vendors/authors of said faulty
> implementations.

A CERT was already sent.  Unfortunately, discussion of the vendors by name
is not a good way to approach this for hopefully obvious reasons.  On the
other hand, as you said, many of these vulnerabilities have been known for a
while.  If you have any other creative ideas on how to approach this, please
do share.

> A draft pointing out, yet again, that shared-secret crypto depends
> on an adequately long and not widely shared key, is not.

We also wanted to point out the practicality of attacking and consequences
of faulty implementations.

> If one were going to expound on RADIUS vulnerabilities, the most
> serious one in my opinion is that the CHAP response is unencrypted

Everyone has their favorite one.  I actually don't consider these
vulnerabilities in RADIUS, but the lack of compliance to the standard itself
in many NAS devices.  If everyone ran RADIUS over IPSEC as recommended in
the RFC, most of these issues would go away.  Sometimes I wonder if it
would've been better if none of the RADIUS handshakes were hashed.  Then
maybe people would've stopped using it to send keys around until they made
sure the mechanism to transport it was truly secure.

Regards,

--
Randy


----- Original Message ----- 
From: "Barney Wolff" <barney@databus.com>
To: "Bernard Aboba" <aboba@internaut.com>
Cc: <radiusext@ops.ietf.org>
Sent: Friday, July 30, 2004 9:40 AM
Subject: Re: Submission for RADIUS extensions working group


> On Fri, Jul 30, 2004 at 07:48:03AM -0700, Bernard Aboba wrote:
> > We have had a late submission relating to RADIUS security
vulnerabilities.
> > I've allocated time for discussion of this within the Thursday session.
> >
> > Since the draft submission deadline has closed, the document is
available
> > for examination here:
> > http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt
>
> Since I won't be at the meeting, I'll make my comments here.
>
> A draft discussing faulty implementations, by name, would be useful.
> So would problem reports to the vendors/authors of said faulty
> implementations.
>
> A draft pointing out, yet again, that shared-secret crypto depends
> on an adequately long and not widely shared key, is not.
>
> If one were going to expound on RADIUS vulnerabilities, the most
> serious one in my opinion is that the CHAP response is unencrypted,
> thus exposing users' secrets to offline attack.  That makes user-chosen
> CHAP secrets very risky.  Hardly new news.
>
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via the 'Net.
>
> --
> 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/>