Issue 100: Security Considerations (IEEE802 WG Last Call)

["Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com>]

Alan writes...

> Issue 100: Security Considerations
> Submitter name: Alan DeKok
> Submitter email address: aland@ox.org
> Date first submitted: July 11, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00524.html
> Document: IEEE802-00
> Comment type: T
> Priority: S
> Section: 7.3
> Rationale/Explanation of issue:
> The last sentence of section 7 has strong new requirements on RADIUS
> 
>   The last sentence of section 7 is also the last section of 
> the document, and says:
> 
>       In addition, the same RADIUS shared secret MUST NOT 
> used for both 
>       IEEE 802.1X authentication and PAP authentication. 
> 
>   It's a little surprising to have a requirement with such a 
> large impact as the last sentence in the document, with no 
> further discussion.
> 
> This requirement means that it may be impossible for 
> implementations to call themselves "unconditionally 
> compliant".  Since RADIUS servers cannot control the 
> authentication methods used by a NAS, there is no way for an 
> implementation to know if a particular shared secret is used 
> for IEEE 802.1X or PAP authentication.
> 
> When a RADIUS server is proxying requests from one or more 
> NASes to a home server, it may not have a choice about how 
> many shared secrets it uses.  In order to satisfy the MUST in 
> section 7.3, the proxying server MUST send send packets from 
> two different IP addresses.  This configuration may not be 
> possible in many deployments.
> 
>   In addition, 802.1X devices may pass through EAP for user 
> authentication, but also implement device administrator 
> authentication via RADIUS.  Implementors should be guided as 
> to how to implement administrator authentication without 
> breaking the security of user authentication.
> 
> Requested change:
> 
>   1. Change the MUST to a SHOULD.
> 
>   2. Add the following suggested text:
> 
> 	Implementors are strongly cautioned to treat the 
> preceding SHOULD
> 	as a MUST.  Issues with the RADIUS protocol prevent the above
> 	requirement from being a MUST in all deployments.
> 
> 	If the device supports administrator authentication via RADIUS,
> 	that authentication MUST NOT use PAP.  That is, a device
> 	such as an access point that implements IEEE 802.1X
> 	authentication MUST NOT send a User-Password attribute in any
> 	Access-Request packet.  Another authentication method MUST be
> 	used, though we do not suggest one here.
> 
> 	RADIUS server implementations that proxy both PAP and IEEE
> 	802.1X authentication to another RADIUS server SHOULD use
> 	multiple source IP addresses for the proxied packets.  Where
> 	this configuration is used, the implementation MUST NOT
> 	use the same source IP address for both IEEE 802.1X
> 	authentication and for PAP authentication.  In those
> 	deployments, the same RADIUS shared secret MUST NOT used for
> 	both IEEE 802.1X authentication and PAP authentication.

One could say that the cat is out of the bag. Section 7 was taken mostly
from existing RFCs, in particular RFC3580.  The specific sentence your
issue relates to already exists verbatim in RFC3580 section 5.3.  My
proposal is to change the last sentence in section 7 to:

"For IEEE 802.X environments, best practices outlined in [RFC3580]
mandate the use of different RADIUS shared secrets for IEEE 802.1X
authentication and PAP authentication."

An normative reference will also need to be added to RFC3580 in section
8.1.

Cheers,
MS 


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