[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A bit of background on [RFC3580] Section 5.3
Hi,
On Sat, Sep 10, 2005 at 10:17:02PM -0700, Bernard Aboba wrote:
> A bit about the intent of the cited sentence in [RFC3580]
> Section 5.3.
>
> Section 5.3 relates to known plaintext attacks against PAP,
> where the attacker attempts to authenticate to a NAS and
> then collects the User-Password attribute sent by the RADIUS client,
> in order to derive the keystream used for attribute hiding.
[SNIP]
There's a bit of an uneasy feeling I get when reading that text, and RFC
3579 section 4.3.4, and it's not from the risk of the possible attacks
on RADIUS, but rather the risk that comes from unbalanced PAP bashing!
First: every bit of RADIUS security depends entirely on the
cryptographic strength of the RNG generating the authenticator, combined
with the strength of the shared secret. That's well known ever since it
was conceived.
To stress that dependency in an alarmist fashion suggests that we've
learned something new, and we haven't.
Security depending on a strong RNG and a strong secret is true for many,
many protocols. Ask any TCP implementor who was ridiculed (and rightly
so) for using a weak sequence number generator.
The situation with RADIUS is no different. We even have 128 bits instead
of the 32 available in TCP, so the number and width of deltas before a
wraparound is much higher. ;-)
The only thing we can't stress enough is shared secret hygiene. RADIUS
is as secure as its administrator, and that also goes for most
protocols.
I've more than once seen holier-than-thou roaming partners deploying
IPSEC to shield that oh-so-weak RADIUS and then mailing the IPSEC PSK in
the clear.
I think that the PAP issue is slightly more complex than it's portrayed
here, because these texts don't go into the issues of weighing PAP
against its alternatives.
If you take a look the password hiding algorithm, assuming <= 16 octet
passwords to leave out the chaining for simplicity, where ^ denotes XOR,
and . denotes concatenation:
User-Password' = User-Password ^ md5 (Secret . Req-Authenticator)
you can see that if you know one User-Password and User-Password', you
know the MD5 hash of (Secret . Req-Authenticator).
This same hash is also used in the response packet to 'encrypt' response
attributes. That means the attacker who captures a request and response,
is able to decrypt the request- and response attributes for that session
and all future sessions using the same Secret and Authenticator. This
includes the sessions themselves if they are somehow protected by the
contents of response attributes, as is the case with MPPE-*-Key.
As you can see, so far I agree completely with those texts.
However, you still have to weigh
a. the difficulty of tapping a RADIUS connection long enough to generate
a significant number of captured Request Authenticator -> hash combo's,
to increase your chance of being able to compromise a future session that
uses a captured RA, vs.
b. the difficulty of cracking a RADIUS backend database containing ALL
cleartext passwords of ALL users (which you need in the case of most
CHAP-like algorithms), allowing you to compromise ALL future sessions.
With PAP you don't need to store plaintext passwords or password
equivalents, and that fact must not be left out of the equasion.
It's either plaintext session, hashed database for PAP, or hashed
session, plaintext (or equivalent) database for CHAP, incl. MSCHAPv2.
The choice simply depends on the situation.
In most cases, I rather use PAP with a hashed database, accepting the
risk of an individual compromised session (dependent the repeating of
the RA while RADIUS is sniffed), than CHAP with a plaintext database,
accepting the risk of ALL passwords being compromised (including the
subsequent sessions that occur while RADIUS is sniffed).
The hashed database can use a good salt, making the off line dictionary
attack that's needed after obtaining the database hard, because it must
be done for each password individually.
Summarizing, I dare say a CHAP solution will often be less secure than
one using PAP -- if you look at the whole picture.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)78 6136282 http://www.e-advies.nl
--
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/>