[5062] in bugtraq
Re: Shared Secret Recovery in RADIUS
daemon@ATHENA.MIT.EDU (Adam Shostack)
Thu Jul 31 12:46:44 1997
Date: Thu, 31 Jul 1997 10:23:57 -0400
Reply-To: Adam Shostack <adam@HOMEPORT.ORG>
From: Adam Shostack <adam@HOMEPORT.ORG>
X-To: mesrik@CC.JYU.FI
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.SOL.3.96.970730211200.4366C-100000@kanto.cc.jyu.fi> from
Riku Meskanen at "Jul 30, 97 10:00:17 pm"
Riku Meskanen wrote:
| On Tue, 29 Jul 1997, Thomas H. Ptacek wrote:
| > This attack was sent to Livingston and posted to the RADIUS discussion
| > list (I'm at a loss for the name of it) last year. I think it's worthwhile
| > to note that the attacks you're pointing out are actively being exploited,
| > and have been for awhile. "Global roaming" systems involving RADIUS
| > proxies will dramatically increase the implications of this attack.
| >
| Some work seems to be done by Dale Cook <cdm@hyperk.com> of SCIENTECH to
| solve these issues, see
|
| http://www.livingston.com/Tech/Technotes/Security/RADIUS-RSA.shtml
Some comments on this:
1. There may be speed issues; I can stop your radius server
by making more requests for authentication than you can handle. I
may even do this legitamately.
2. The use of RSA is incorrect; see Anderson's "Robustness
Principles" paper from Crypto 95. You need to sign before encrypting,
not afterwards. ("This public key is used to encrypt the entire
authentication packet along with a dummy secret key, the resulting
encrypted packet is signed with the private key of the server.")
Anderson's paper can be found at http://www.cl.cam.ac.uk/users/rja14/
3. Since the code uses RSAref, its probably vulnerable to a
timing attack. (See Kocher's paper in Crypto 96;
www.cryptography.com)
The use of signing an encrypted message leads me to worry
substantially about the implementation. I haven't spent time looking
to see if there are other problems, but with one that large, I'd be
suprised if its the only one.
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume
