Subject: [Isms] RE: Follow up on Authorize Only issue

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Fri, 21 Jul 2006 14:27:47 -0700

I agree with Avi, Glen and Alan.   

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Friday, July 21, 2006 1:44 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Follow up on Authorize Only issue
> 
> > For the SSHSM usage case, the question is whether it is an 
> > unacceptable security risk for a trusted NAS to be able to obtain 
> > authorization information about a user that is not actually 
> "present" 
> > at the NAS?
> 
> My interpretation is that three respondents (Glen, Alan, Avi) 
> believe that the answer is "no".  The existing RADIUS trust 
> model collapses if the NAS has been compromised and does 
> nefarious or foolish things.
> 
> I'd like to determine if we have consensus on this position.  If you
> *have* an opinion on this issue, please *respond* whether you 
> agree or disagree with this assertion.
> 
> 
> --
> 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/>
> 

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

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 22 Jul 2006 11:17:37 -0400

"Bernard Aboba" <[email-masked]> wrote:
> For example, should a NAS be able to retrieve the Tunnel-Password attribute 
> of any user, regardless of whether they are connected?

  i.e. A compromised NAS can leverage this requested feature to obtain
that information more readily.  Right now, if the NAS hasn't had a
user log in through it, it can get those credentials only through a
brute force attack on the password.  The server *should* be able to
catch that attack, mitigating the vulnerability.

  For users who have logged in through a compromised NAS, nearly all
hope for security is lost.

> If this is allowed, it should follow the principle of "least privilege", 
> only providing the attributes relevant to SSH.

  Which means that the Access-Request has to be recognizable as for
SSH in this use-case.  This means an attribute or value specifically
for this purpose.  The RADIUS server can then key off of that special
request, and return a limited response.

  The use case should also enumerate the possible attributes and
values needed in the Access-Accept, and state explicitely that
responding with any other attributes or values may result in security
violations.  i.e. Other attributes and values SHOULD NOT be sent in
the Access-Accept.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 21 Jul 2006 23:57:53 -0700

The security implications of unrestricted access to *any* user attributes 
are fairly severe.

There are also VSAs that contain sensitive information.

The Call-Check Service typically provides very little information in the 
Access-Accept (all that is needed is whether to accept or reject the call) 
so there is minimal leakage.

>"present"  at the NAS?

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 23 Jul 2006 14:31:12 -0700

>A compromised NAS can leverage this requested feature to obtain

Right.

>request, and return a limited response.

Right.  For example an additional Service-Type value of "SSH" could be 
allocated One concern would be whether an attacker could use this 
Service-Type with any NAS-Port-Type, in order to retrieve attributes 
relevant to that NAS-Port-Type.  To prevent this,  one possibility is to add 
NAS-Port-Type values of "SSH" and "ISMS" (since different attributes might 
be returned for a straight SSH or SSH-protected ISMS session) and only allow 
Service-Type="SSH" to be used with those NAS-Port-Type values; all other 
NAS-Port-Type values would result in an Access-Reject.

>violations.  i.e. Other attributes and values SHOULD NOT be sent in

Makes sense.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 24 Jul 2006 15:24:59 -0400

Hi, 

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, July 22, 2006 2:58 AM
> Subject: [Isms] RE: Follow up on Authorize Only issue
> 

OK. If RADIUS supports this, we can probably ask for specific
attributes or attribute sets.

> only providing the attributes relevant to SSH.

There are multiple possible proposals on the ISMS table, and we are
trying to determine what RADIUS can or cannot provide for us. We are
asking for an authorize-only because the current requirement of RADIUS
to tie the authentication and authorization together does not fit the
SNMP architecture. If we cannot get a RADIUS authorize-only, then we
probably will not be able to use RADIUS for one of our purposes.

What we are NOT asking for when we request "authorize-only" support:

We know that RADIUS can provide SSH-related attributes when the user
connects to the NAS using an SSH session and RADIUS provides the
authentication. 
We know that the RADIUS server might be able to provide SNMP-related
attributes when the user connects to the NAS using an SSH transport
and RADIUS provides the authentication.
We do not need "authorize-only" support for those situations, since
RADIUS would be doing the authentication. It would be pretty silly to
call a feature "authorize-only" if the authentication must be part of
the feature.

What we are asking for:

The purpose of authorize-only is to make the authentication
independent of the authorization.
So there would be no guarantee there is any SSH involved anywhere in
the system. The authentication might have been provided via Kerberos
or TLS or SNMPv3's USM, but RADIUS is not involved in the
authentication, only the (later) authorization.
What the RADIUS server will know is that a trusted RADIUS client
asserts that authentication of the principal has been performed, and
the trusted RADIUS client is asking for the attributes that indicate
what the principal is allowed to do. The attributes we want to see are
specific to SNMP, or to Network Management via SNMP/Netconf/CLI, etc.
If RADIUS supports it, the RADIUS client may be able to identify that
the request is associated wih an SNMP engine, so the server can return
only SNMP-related attributes.

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 24 Jul 2006 21:23:35 -0700

>attributes or attribute sets.

Typically this is handled by utilization of a unique Service-Type or 
NAS-Port-Type value.  The RADIUS policy engine then selects the attribute 
set to be returned based on these values.

>trying to determine what RADIUS can or cannot provide for us.
>

As far as I know there is no specification for SSH authentication support 
within RADIUS so I'm not sure if this is true or not.  For example, as I 
understand it SSH can support authentication mechanisms such as Kerberos 
which are not supported in RADIUS.

>and RADIUS provides the authentication.

In this case it sounds like the NAS-Port-Type might be "SSH" but the 
Service-Type might be "SNMP".

>RADIUS would be doing the authentication.

I think this depends on whether RADIUS can support all the required 
authentication methods.  If not, then either that support needs to be added 
to RADIUS or only authorization will be available.

>The authentication might have been provided via Kerberos

In this case you might have a Service-Type of "SNMP" and a NAS-Port-Type of 
"SNMP".

>The attributes we want to see are

A Service-Type of "SNMP" with a NAS-Port-Type of "SNMP" could be used to 
indicate this.

Question:  In the case where SSH is used, do you just need SSH attributes, 
or are SNMP attributes required there as well?   In other words, how is SSH 
for SNMP distinguished from plain old SSH?

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 25 Jul 2006 09:26:32 -0400

Well I am not exactly against using an Authorize Only in this way.

I do recognize that there is a severe security issue.

However, I still think designers need to be aware of the issues and
design appropriately.

We in the IETF need to make sure that designers are aware of the
security risk of a particular feature.  That is afterall what the
Security section is about.

> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, July 23, 2006 5:31 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Follow up on Authorize Only issue
> 
> >A compromised NAS can leverage this requested feature to obtain that 
> >information more readily.  Right now, if the NAS hasn't had 
> a user log 
> >in through it, it can get those credentials only through a 
> brute force 
> >attack on the password.  The server *should* be able to catch that 
> >attack, mitigating the vulnerability.
> 
> Right.
> 
> > > If this is allowed, it should follow the principle of "least 
> > > privilege", only providing the attributes relevant to SSH.
> >
> >Which means that the Access-Request has to be recognizable 
> as for SSH 
> >in this use-case.  This means an attribute or value specifically for 
> >this purpose.  The RADIUS server can then key off of that special 
> Right.  For example an additional Service-Type value of "SSH" 
> could be allocated One concern would be whether an attacker 
> could use this Service-Type with any NAS-Port-Type, in order 
> to retrieve attributes relevant to that NAS-Port-Type.  To 
> prevent this,  one possibility is to add NAS-Port-Type values 
> of "SSH" and "ISMS" (since different attributes might be 
> returned for a straight SSH or SSH-protected ISMS session) 
> and only allow Service-Type="SSH" to be used with those 
> NAS-Port-Type values; all other NAS-Port-Type values would 
> result in an Access-Reject.
> 
> >The use case should also enumerate the possible attributes 
> and values 
> >needed in the Access-Accept, and state explicitely that 
> responding with 
> >any other attributes or values may result in security 
> violations.  i.e. 
> >Other attributes and values SHOULD NOT be sent in the Access-Accept.
> 
> Makes sense.
> 
> 
> 
> --

---

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

> only SNMP-related attributes.

Careful here.  I don't want to end up with something that's specific to 
SNMP, SSH, or any particular authentication mechanism.  It's fine to have 
an approach where the RADIUS server will only provide attributes relevant 
to the service and/or the particular RADIUS client (NAS) in question.  That 
decision can be made by the RADIUS server based on things like the client's 
identity, but it should _not_ be made based on the client's assertion of 
what service it's providing.

What I'd like to see is a model in which the RADIUS server is told, as a 
matter of policy, which attributes it is allowed to provide in an 
authorize-only transaction, and to which RADIUS clients, and which 
attributes can only be reported after successful authentication of a user. 
The administrator can then configure this based on his deployment needs.