A bit of background on [RFC3580] Section 5.3

[Bernard Aboba <aboba@internaut.com>]

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. 
This attack is easy to mount because RFC 2865 does not require
that the RADIUS Access-Request be integrity protected.  

Since the User-Password keystream is a function of the Shared 
Secret and the Request Authenticator, a user's password should
be considered compromised if the Request Authenticator 
(User-Password) repeats on any NAS utilizing a given RADIUS 
shared secret. 

In order to prevent this attack, RFC 2865 requires the 
Request Authenticator to be globally and temporally unique,
but not all NASes satisfy this requirement.  For example,
a NAS can attempt to satisfy the global uniqueness property
by utilizing the IP address in the high order bits of the
RA and then utilizing a pseudo-random number in the low
order bits.  However, not all NAS devices have sufficient
entropy to produce high quality pseudo-random numbers. 

If in addition, the same RADIUS shared secret is used on
for more than one NAS, the chance of compromise increases
significantly. 
 
Once an attacker has compromised user passwords, they can
gain access to all media which utilize those credentials,
enabling known plaintext attacks on other hidden attributes
such as Tunnel-Password and MPPE-Keys. 

These other hidden attributes cannot be attacked by an
unauthenticated attacker because these attributes are only
sent in an Access-Accept, which implies a successful
authentication.  So the attacker must first obtain
access to compromised passwords before trying this more
difficult attack. 

However, once this attacks collects sufficient keystream
material, if the RA + salt ever repeats on a NAS utilizing
a given shared secret, then the EAP MSK or Tunnel-Password
is compromised. 

As a result, Section 5.3 is attempting to discourage the 
use of PAP and the potential cascading vulnerablities that
can result. 

If PAP cannot be deprecated entirely, then it is best if its 
use is isolated to accounts that have limited access rights.  
Also, EAP made a conscious decision not to support PAP, 
so re-introduction of PAP support into EAP is undesirable. 

If these principles are followed, it possible to limit the 
use of PAP without forcing a RADIUS proxy to utilize a 
different IP address for PAP and EAP authentication.

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