Re: Submission for RADIUS extensions working group

[Barney Wolff <barney@databus.com>]

On Fri, Jul 30, 2004 at 11:12:56PM -0700, Randy Chou wrote:
> 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.

Post under a pseudonym to bugtraq, if you have actually notified the
vendor(s) and gotten no satisfactory response in a reasonable time.
Why on earth should RADIUS vendors be immune from having security
vulnerabilities pointed out when everybody else in the world 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
> 
> 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.

RADIUS hashing predates IPsec.  One might argue that it should have been
dropped when IPsec became practical to run on all new equipment, but
just this week I saw somebody wanting to acquire a Portmaster to use for
multiple remote console access.  Customers do tend to get upset when
equipment that still works is obsoleted by fiat, much as protocol
designers and developers might wish otherwise.

IPsec with a 6 byte shared key is not very secure either. :)

There's no excuse for a vendor's not allowing an adequately long shared
secret.  If RADIUS is actually insecure with a shared secret with at
least 128 bits of entropy, we need to hear about it and take action,
but unless I'm missing something that's not the case.

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