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

From: "Nelson, David" <[email-masked]>
Date: Tue, 18 Jul 2006 18:10:20 -0400

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?

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 21 Jul 2006 14:44:52 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, July 18, 2006 6:10 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Avi Lior writes...
>  
> 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.
> 
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 24 Jul 2006 14:08:06 -0400

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.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: Avi Lior [mailto:[email-masked]] 
> Sent: Friday, July 21, 2006 2:45 PM
> To: Nelson, David; [email-masked]; [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Jul 2006 21:16:13 +0200

Dave,
> 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

---

From: "David Harrington" <[email-masked]>
Date: Mon, 24 Jul 2006 16:00:33 -0400

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

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 3:16 PM
> To: David Harrington
> Cc: 'Avi Lior'; 'Nelson, David'; [email-masked];
[email-masked]
> Subject: Re: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Dave,
> > Hi,
> >

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 24 Jul 2006 18:03:35 -0400

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.

> From: David Harrington [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 4:01 PM
> To: 'Eliot Lear'
> Cc: Avi Lior; 'Nelson, David'; [email-masked]; [email-masked]
> 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
> 
> > 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
> > 
> 
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 14:02:20 -0400

> entity that it trusts. The token can be generated by the Authentication

Most authentication mechanisms don't have any such token, or even any such 
thing as an "Authentication Server".  There is no central entitiy that 
knows every time a Kerberos client proves its identity for a server.  Nor 
is there such a thing for SSH publickey, or USM, or TLS.  And even if there 
were, I wouldn't want this to be a requirement.

Authentication and authorization are separate concepts, and many people 
want to (and do!) handle them independently.  The selection of mechanisms 
for these should, to the maximum extent possible, be orthogonal.  A service 
providing authorization, as we are asking RADIUS to do, should not care 
what authentication mechanism was used, and certainly should not require 
that protocol elements be defined for each authentication mechanism.

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

No, you don't.  The correct profile is the one requested by the NAS.

What you mean to say is "we need this assertion to make sure we don't 
deliver the correct profile to a bad guy", but I don't agree with that. 
Just don't give the bad guys access to the RADIUS server (that is, don't 
give them keys with which to authenticate to the RADIUS server).  If you're 
concerned that a NAS might be compromised or be malicious for some other 
reason, then restrict that NAS to retrieving only information relevant to 
itself.  Bear in mind that it is the NAS, not the RADIUS server, which is 
providing service here, so if the NAS has been compromised then you've 
already lost.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA