Re: Submission for RADIUS extensions working group

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

> Post under a pseudonym to bugtraq,

Great.  Now every anonymous post on bugtraq related to RADIUS will be blamed
on me :).  Seriously though, I'm looking for a way to get the vendors to
understand the severity of not being compliant and also educate the consumer
on the best practices when implementing Radius.

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


That's the thing.  How secure something is also depends on what and how it's
used.  By not incorporating IPSEC as a requirement, too many of the security
decisions IMO are left to the consumer who a lot of times is not
knowledgeable enough to make an educated decision.  Not that I'm suggesting
people to use 6-byte shared keys, but using it as an example...If I had an
offline sniff of a RADIUS handshake that was encrypted with a 6-byte RADIUS
shared key, I'd be able to decrypt that very easily.  On the other hand, if
I had the same handshake over IPSEC w/ a 6-byte IKE pre-shared key, I would
never be able to decrypt that assuming DH is used (as it typically is).
That's just one of the properties of IPSEC.

Another example would be the case where a good enterprise uses RADIUS and
rotates the RADIUS shared secret diligently say once every week.  If a
hacker sniffed RADIUS packets, stored it, and say somehow gets the shared
secret 12 weeks later, he would still be able to get the contents.  On the
other hand if IPSEC was used in this case, the hacker would not be able to
decrypt the contents even after he knew the IKE pre-shared key.  This
problem may or may not be serious depending on the application.  If the
contents were the keys that secured financial reports from a company, the
decryption of the report 12 weeks later would matter much less (public
knowledge by then) than compared to data that contained employee
compensation.  By not using IPSEC, we're settling for the lowest common
denominator.  But most consumers don't know the implications of that
decision.  Again, there are many other properties of IPSEC that are missing
in RADIUS.  To get to the same level of security would be re-inventing the
wheel.  I would assume this conclusion was reached back when RADIUS over
IPSEC was already recommended in the RFC.  However, few NAS vendors follow
such recommendation.

Anyways, let me know if you think we're still wasting your time.  If not,
we'd really like more feedback.  We chose what we considered a set of
examples that illustrated the severity of the problems.

Regards,

--
Randy


----- Original Message ----- 
From: "Barney Wolff" <barney@databus.com>
To: "Randy Chou" <rchou@arubanetworks.com>
Cc: <radiusext@ops.ietf.org>
Sent: Saturday, July 31, 2004 12:00 AM
Subject: Re: Submission for RADIUS extensions working group


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