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

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

Hi,

If I was specifying how this is done:

It would be nice if the AAA client could return some sort of token to
the AAA server to assert that the user has been authenticated by an
entity that it trusts. The token can be generated by the Authentication
Server.

We need this assertion to make sure we deliver the correct profile.

Even if we don't have this type of interaction I still think that we
should support Authorize-Only for this type of transaction.  Since this
can be used in cases where the NAS is absolutely trusted or there are
other means to secure the NAS/AAA -- eg in a closed system.


> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net] 
> Sent: Monday, July 24, 2006 4:01 PM
> To: 'Eliot Lear'
> Cc: Avi Lior; 'Nelson, David'; isms@ietf.org; radiusext@ops.ietf.org
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Hi Eliot,
> 
> The ISMS concern is that some operators want to use 
> authentication mechanisms other than RADIUS to authenticate 
> the SNMP principal (which may or may not be a human user), 
> but would like to be able to use a RADIUS server to provide 
> information about what "SNMP-policy" (think SNMP-specific 
> FilterID) the SNMP agent should apply regarding "which SNMP 
> operations to what SNMP data sets" the already-authenticated 
> "user" is permitted. 
> 
> And they would like to get the SNMP-policy without having to 
> perform another authentication of the principal via the 
> RADIUS server, since requiring that might force the operators 
> to store the principal's authentication credentials at the 
> SNMP agent or require the realtime intervention of a human 
> being. The "NAS" has already done an authentication and does 
> not want to waste resources doing yet another one.
> 
> We only want this "authorize-only" service to be performed at 
> the request of an authenticated/trusted RADIUS client. If the 
> AAA trust for an ISMS-related client is compromised, the 
> situation should be identical to that of any other 
> compromised AAA client - all bets are off concerning the 
> behavior of the RADIUS client.  
> 
> Who provides the hints that identify which set of attributes 
> should be returned in a request-accept? The AAA client? If 
> the AAA client is compromised, who provides the hints that 
> identify which set of attributes should be returned?
> 
> dbh
> 
> > -----Original Message-----
> > From: Eliot Lear [mailto:lear@cisco.com]
> > Sent: Monday, July 24, 2006 3:16 PM
> > To: David Harrington
> > Cc: 'Avi Lior'; 'Nelson, David'; isms@ietf.org;
> radiusext@ops.ietf.org
> > Subject: Re: Follow up on Authorize Only issue (was RE: 
> > [Isms] ISMS session
> > 
> > Dave,
> > > Hi,
> > >
> > > Let me point out that authorize only is being requested for use
> with
> > > SNMP. The NAS is effectively the SNMP agent, and the RADIUS 
> > > interaction is to determine which data the already authenticated 
> > > principal should be allowed to access.
> > >
> > > If the NAS is compromised, then the SNMP agent is 
> compromised, and 
> > > within the scope of the managed entity, you are probably already 
> > > toast, with or without support from RADIUS. And if the SNMP agent
> is
> > > compromised, then an attacker probably doesn't much care what
> RADIUS
> > > has to say about accessing the SNMP MIB.
> > >   
> > 
> > I've lost the plot just a little here.  I thought the concern was 
> > beyond the scope of the managed entity but the broader 
> service area of 
> > the radius server.
> > 
> > Eliot
> > 
> 
> 

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