Subject: Re: (radius) tunnel-password language

From: Barney Wolff <[email-masked]>
Date: Tue, 14 Dec 1999 11:23 EST

Ran, if this attack is real, then whenever it is published there
will be much emergency work to repair the breach.  But until enough
is published to indicate what needs to be changed, no such work
can be started.  Therefore, postponing revealing the attack does
nothing to help anybody.  And of course, it it's real it can be
rediscovered by a bad guy, who will quietly vacuum up lots of
user passwords until the attack becomes known.

If you really believe there is benefit to keeping the attack quiet,
what actions by owners or producers of RADIUS gear should be taking
place while we wait?  Other, of course, than just abandoning RADIUS,
or running it over IPSEC?

I know that the IPSEC WG was adamantly opposed to using RADIUS for IPSEC
key distribution, and I would not wish to make any claim that RADIUS
encryption is as bulletproof as IPSEC.  But that's very different from
claiming that there is an attack on it.

I'm sorry, but the bald assertion that breaking RADIUS-style encryption
is child's-play is not a "reasonable technical point" without a testable
indication of *how* it's child's-play.

Regards,
Barney

> To: Barney Wolff <[email-masked]>
> Cc: [email-masked]
> Subject: Re: (radius) tunnel-password language 
> Content-Length: 1388
> Date: Tue, 14 Dec 1999 09:32:56 -0500
> From: Ran Atkinson <[email-masked]>
> 
> % Ignacio, you are now the second person to claim (the first privately)
> % that RADIUS (and equivalently, L2TP) hiding is not serious encryption.
> % But nobody has come forward with any attack on the encryption mechanism
> % in either protocol.  Until someone does, and the attack looks credible,
> % this amounts to FUD with no visible basis.
> 
> Barney,
> 
> 	It would be irresponsible to publish the attack in a
> full-documentation manner at this point.  Step one of working 
> within the system is the effort that several folks are making here 
> to get the risks more clearly and crisply documented.  An average reader 
> of the current RADIUS RFCs and I-Ds will not come away with the grasp
> that the system is fundamentally a "scrambler" rather than a real
> "security" mechanism.
> 
> 	The claim that RADIUS does not provide effective privacy
> is not new and has been made repeatedly in public IETF fora 
> -- in the context of proposals to use RADIUS for IPsec key management,
> to give one example of many.
> 
> 	If an attack were published today, then every RADIUS server in
> operational use becomes vulnerable.  Thus, it is not responsible
> behaviour (IMHO) to publish an attack in this kind of situation;
> it is most decidedly NOT FUD.
> 
> 	Your turning a reasonable technical point that Ignacio (and
> others) have tried to make into an ad hominem comment about
> FUD was disappointing.
> 
> Yours,
> 
> Ran
> [email-masked]
> 
> 
> 
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Ran Atkinson <[email-masked]>
Date: Tue, 14 Dec 1999 12:24:51 -0500

Barney,

	The root problem is the way RADIUS performs "encryption",
as has been noted before in various IETF fora.

	Details of the attack ought NOT be noted here in public until things
get fixed in the spec and in implementations (thus giving operators
a fighting chance of closing the hole before a truck gets driven
through their RADIUS-based systems).

	The current (pseudo-)cryptographic part of RADIUS needs to be
replaced.  Dropping in a real encryption algorithm into RADIUS, along with
a shared key between endpoints would resolve/mitigate the non-proxy aspects
of RADIUS confidentiality somewhat, for example.  This is feasible
without changing the protocol radically.  It would involve changing
running code in lots of implementations.

	I surely haven't advocated "just protect RADIUS with IPsec";
I haven't seen others suggest it here (perhaps I missed an email ?).

Yours,

Ran
[email-masked]

-

---

From: Ran Atkinson <[email-masked]>
Date: Tue, 14 Dec 1999 12:41:30 -0500

I propose that we add the following text to Security Considerations:

	"The password scrambling mechanism described in 
Section 5.2 has not been subjected to significant amounts of
cryptanalysis in the published literature.  Some in the IETF
community are concerned that this method might not provide
sufficient confidentiality protection to passwords and other
forms of keys transmitted using RADIUS.  Users should evaluate 
their threat environment and consider whether additional security 
mechanisms (e.g. one-time passwords [RFC-2289]) should be employed 
within RADIUS to reduce the risk of break-in due to potential 
compromise of the RADIUS scrambling scheme."

Ran
[email-masked]

-