RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session

["Avi Lior" <avi@bridgewatersystems.com>]

 David,

I agree with Glen and Alan.

NAS is within the trust boundary of AAA.  

If you comprise the NAS you are done.  It can leak information, modify
accounting, disallow or allow services that are not authorized.




> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Tuesday, July 18, 2006 6:10 PM
> To: isms@ietf.org; radiusext@ops.ietf.org
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Avi Lior writes...
>  
> > I am having trouble understanding "user that is not 
> actually present".
> 
> In the proposed use case, the NAS could request, from a 
> RADIUS server, authorization information for a user that it 
> asserts is present, but is not.  The RADIUS server cannot 
> tell, since no user credentials are presented.  Well behaved 
> NASes won't do this.  One might argue that all trusted NASes 
> will be well behaved, but that makes certain threat model assumptions.
> 
> Why would a (compromised) NAS want to do this?  Well, leaking 
> authorization information on various user accounts may help 
> an attacker select high value target accounts. 
> 
> The only standardized scenario for non-authenticated 
> authorization RADIUS is call check.  The assumption is that 
> the PSTN is a reliable source of the telephone number(s), the 
> NAS is trusted and non-compromised, and the user will 
> typically be authenticated once the session is initiated.  
> Thus, the risk is relatively low.
> 
> For Dynamic RADIUS, RFC 3576 requires a State attribute, 
> which can only have come from a previous successful authentication.
> 
> In this particular ISMS use case, SNMP service is authorized 
> based on the assertion of identity of the user by the NAS, 
> without the RADIUS server ever having performed an 
> authentication, and without the benefit of the resultant 
> State attribute.  Thus, the risk is potentially higher.
> 
> The questions at hand are whether the risk is high enough to 
> be of serious concern, and whether or not it can be mitigated?
> 
> 
> --
> 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/>
> 

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