Subject: RE: [Isms] SNMP "access control" terminology

From: "Nelson, David" <[email-masked]>
Date: Thu, 6 Jul 2006 14:13:06 -0400

Uri Blumenthal writes...

> Well, you did want common auth base, didn't you? One implication
> is that whoever is listed in that common auth database, can get
> SSH-authenticated and thus open an SSH session. How long that 
> session will stay alive - is a different question that depends 
> on who decides what on the other end of the SSH pipe.

I think this is an accurate description of how SSH works, as deployed.
If you can authenticate, you get the "access right" to open an SSH
session and attempt to use an application over that session.  It is up
to the applications to provide further authorization, if required.  In
this instance, SNMP is the application.

I don't think this is how SSH ought to work, when integrated with
RADIUS, or any other AAA service.  It is not in our charter to specify
how SSH integrates with RADIUS, of course, and since we aim to leverage
existing deployments, it is somewhat moot anyway.  However, I'll indulge
in a small digression.  I think that the SSH server should take into
consideration RADIUS authorization information, when RADIUS is used for
SSH authentication.  I'll leave out a discussion of any possible SSH use
of RADIUS for "Authorize Only" services.  In such a scenario, the SSH
server should launch the application that is specified by the RADIUS
Service-Type attribute.  It would not be up to the application to
determine the user's authorization.

Back to the main point.  If it is up to SNMP, as the application, to
determine the user's authorization to invoke/use SNMP, how should this
occur?

I've heard two suggestions:

(1) It doesn't matter.  With appropriate authorization binding to the
VACM, unauthorized users won't be able to complete any operations.
Consumption of session resources is at worst a DoS issue.

(2) SNMP needs to be able to determine if the authenticated user is an
authorized user for SNMP and disconnect the SSH session if the user is
not authorized.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Jul 2006 20:41:20 +0200

> authorized user for SNMP and disconnect the SSH session if the user is

Yes, there are two levels here - authorization to use a service like
SNMP in general and authorization to perform a given operation on a
given object (object level access control like VACM).

And yes, the scope of this question is broader than ISMS since at
least NETCONF will have the same issues (with the difference that
NETCONF does not have an access control model yet).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 06 Jul 2006 13:11:49 -0700

>>>>> On Thu, 6 Jul 2006 20:41:20 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> Yes, there are two levels here - authorization to use a service like
Juergen> SNMP in general and authorization to perform a given operation on a
Juergen> given object (object level access control like VACM).

Though you may desire to extract one from the other.  Specifically,
authorization to use the "SNMP service in general" can be derived by
seeing if any authorization is allowed to the object model.  Whether
this is desired on not remains to be seen, but it is adding another
configuration variable that isn't necessary (technically) and may lead
to configuration errors.

What scares me about this conversation is that it sounds like everyone
is winding the way to adding another configuration variable.

When would you want to allow the SNMP session in general to be used if
they couldn't do anything with the service?
  - Likely never

When would you want to allow the SNMP objects to be used but not the
SNMP/SSH session?
  - Likely never, but:
  - Maybe only allow other security models.
    - But this is also already possible with VACM and doesn't need
      separate configuration.
  - To quick-disable a user and leave the more complex OID
    include/exclude mappings in place to re-enable it in the future.
    - But this is also already defined by VACM and doesn't need
      separate configuration.
-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 6 Jul 2006 15:29:26 -0400

So can we agree on terminology for two types of authorization?

"service authorization" or "session authorization", in which an SSH
server is authorized to establish an SSH subsystem of type "snmp" on
behalf of an authenticated SSH principal?

"operations authorization", in which an SNMP application is authorized
to perform specific SNMP operations on specific sets of SNMP data on
behalf of an authenticated SNMP principal?

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 2:41 PM
> To: Nelson, David
> Cc: [email-masked]
> Subject: Re: [Isms] SNMP "access control" terminology
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 06 Jul 2006 17:25:27 -0400

> this instance, SNMP is the application.

This is an oversimplification.  If the step that SSH calls "user 
authentication" succeeds, then you get to open a session.  That step is 
understood to include both authentication of the client and authorization 
of the client to start an ssh session with a particular identity (an ssh 
username).  The former is performed using a protocol specified by the 
particular userauth method in use; the latter is largely 
implementation-dependent.

An SSH server which uses RADIUS to back userauth can indeed take RADIUS 
attributes into account when making its authorization decision.  It can 
even use that information to decide what programs or subsystems the client 
is allowed to launch(*).  OpenSSH makes this sort of decision today based 
on authorization data included in authorized_keys files; an implementation 
could easily do the same thing with RADIUS.

> determine the user's authorization to invoke/use SNMP, how should this

I think it's up to SNMP, and particularly the access control model, to 
decide what users are allowed to perform what operations.  Whether a user 
is allowed to access SNMP at all is effectively up to the security model. 
In the case of a TMSM, we can and IMHO should push that functionality all 
the way down to the underlying transport, which in this case is SSH.

Now, we can argue all you want about whether it's necessary for SSH or any 
part of SNMP to provide any sort of coarse-grained "can this user use SNMP" 
authorization, but ultimately, I think that's an implementation and 
deployment decision.  Given the existence of the SNMP access control model, 
there is no security reason why we need to require such functionality. 
There's also no reason to prohibit it, and if we did, we'd be ignored, 
since nearly all SSH implementations at least provide "is this user allowed 
to access the system at all"-level authorization.

So, can we stop arguing about whether coarse- or fine-grained access 
controls are a good idea or not, accept that people will want and deploy 
both, and move on to some actual protocol design?

-- Jeff

(*) There seems to be some confusion about what "authentication" and 
"authorization" mean.  These terms have well-established meaning in the 
security community; the first means proving the identity of some entity; 
the second, deciding what that entity is or is not allowed to do.  Deciding 
whether a client can perform operations like "start an SNMP session" and 
"update MIB object foo" are both authorization decisions; they differ only 
in scope, not kind.  I think it would be best if we used the unqualified 
terms "authentication" and "authorization" only in this general sense, and 
always used qualifiers when a narrower meaning is intended.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 6 Jul 2006 17:21:27 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Nelson, David" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 06, 2006 1:11 PM
...
> is winding the way to adding another configuration variable.
...

A simple hack to avoid adding another configuration variable would
be to just check the vacmSecurityToGroupTable to see whether
there is an entry for the user.  If there is none, then the session could
be terminated.  Of course, this violates modularity, bypasses existing
ASIs, and would only work with VACM.  But it *would* be simple, do
the right thing, and not require additional configuration.

Randy