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

From: "Nelson, David" <[email-masked]>
Date: Wed, 28 Jun 2006 15:35:43 -0400

David Harrington writes...

> I'll present my understanding of the RFCs and the intentions
> of the authors to clarify this. This message is about the term
> "access control" in SNMP.

Thanks for explaining.
 
> The access control subsystem, the ACM, permits multiple models
> of access control. An access control model advises applications
> about who is allowed to do what operations to which objects in
> which subsets of data.

So here's some dumb questions:  Is "access control" optional in SNMP?
For example, is there a default that all authenticated principals get
full access to all objects and operations?

> SNMP traditionally has not worked with a session approach, 
> so there is no concept of authorizing an snmp session in RFC3411.
> It has been argued that authentication via USM implies authorization
> to use SNMP at that engine. I believe that is incorrect. SNMPv3 
> has no concept that a user is "authorized" by USM to perform SNMP
> operations.

If I understand this, any principal that can authenticate itself has the
use of the SNMP engine, up to the point where an application might
choose to deny access, based on consulting with the ACM.

I think my point was that, with USM, no "unauthorized" principals 
are likely to be configured in the usmUserTable, so users who "aren't on
the list" don't get as far as making a request to an application.  If we
effectively export the "list", the analog of the usmUserTable, to a
multi-purpose, enterprise-wide AAA system, there are likely to be lots
of "unauthorized" users "on the list".  Your point is that it is the
function of the ACM to weed them out from the authorized users.  Point
taken.  This presumes that the ACM obtains some authorization
information from the AAA service, either directly, or via the SSH
server.  We need to describe how that happens.

> For example, in an engine that only supports USM and VACM, "dbh"
> could have an entry in the usmUserTable, and I might be able to
> authenticate myself to an engine, but if VACM has no assignment
> for the securityName "dbh" to an authorized group, then I am not
> authorized to perform any SNMP operations on any objects in any
> contexts at that entity. It is the VACM access control subsystem
> that makes this determination, not the USM security model.

So this part is clear.

> So, when we talk about access control in SNMP, we really should
> restrict that terminology to refer to the functionality provided by
> the ACM subsystem.

OK.  Let's go with that.

> RADIUS has the ability to advise a server which services should
> be permitted when a client connects to a server. I think referring
> to this as "access control" within an SNMP engine will cause 
> nothing but problems.

There may be a terminology issue, with how SNMP defines "access
control", but there is a valid issue with the need for a RADIUS/AAA
server to be able to provision services on the NAS.

> The decision to permit access to an SSH subsytem called
> "snmp" is based on a transaction between a RADIUS advisor, 
> and an SSH enforcer (or "snmp" service provider).

That would be a very nice way to implement the system.  However, the
problem with this approach is that it places normative requirements on
SSH, at least SSH as used for SNMP.  I don't think our charter allows us
to proscribe such requirements.  This would be under the title of
"SSH-RADIUS Integration".  I think this is a very good thing, and have
in fact described RADIUS attributes that could be used to provision SSH
in such a fashion.

Are we in agreement that what I have called "base-level" service
provisioning (the NAS providing SNMP service) should be enforced
(implemented) in the SSH server?  If so, does ISMS have leave to
describe that behavior in a Standards Track RFC?

> SNMP does not enter into this decision at all. SNMP will never
> even see a message that comes to an SSH server, if the SSH server 
> does not permit the "snmp" service.

True, but this creates requirements for changes to existing SSH server
implementations, I believe.  Is this OK?

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 Jun 2006 16:52:47 -0400

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
>  > 

1) access control is optional, to a degree. It is an advisory
functionality used by an application. Not all applications are
required to ask the isAccessAllowed() question, and I think not all
implementations are required to not permit an operation for which the
answer is "no". This was done because there are some unusual
circumstances that needed to be accommodated. I recall something about
printers, but I do not recall just what the circumstances were. I
think all the standard applications abort the operation if
isAccessAllowed() returns "no".

2) The default configuration of VACM is determined by an administrator
(and the ability of an implementation to support their decision). If
an admin wants to set up their ACM to permit all users to do all
things to all data, I suppose they could. If an admin wants to accept
whatever the implementer configured, I suppose they could.

I would need to walk through the Installation portion of RFC3415 to
know whether the installation configuration suggested supports a
"permit all" approach. 

> choose to deny access, based on consulting with the ACM.

I believe that is correct.
Not necessarily desirable, but correct.

> the list" don't get as far as making a request to an 
> application.  

Failure to authenticate when msgFlags says "auth" would cause
processing to stop.
I would assume most administartors would not include "unauthorized"
principals in the usmUsertable.

But I believe all an admin needs to do to stop an existing
"authorized" principal from being authorized subsequently would be to
remove the securityname-groupame mapping in VACM. The usm entries and
the other vacm entries could exist, but without a
securtyname-groupname mapping they would get nothing. I didn't look
this up to double-check it, but I'm fairly sure this is the case.

> If we

It presumes that the ACM has or obtains information about the ACM
policies to apply.

It would be incorrect to assume that the policies MUST come from a AAA
server, or from the same AAA server that was part of the
authentication process. It would be acceptable that the policies MAY
come from the same server, or another AAA, or from another source
altogether. Any "binding" between the authentication and authorization
in SNMP is done via the securityName/securityModel parameters.

> server to be able to provision services on the NAS.

I have no qualms with the fact that an SSH server may ask a RADIUS
server for advice about whether to permit the establishment of an
"snmp" subsystem associated with the SSH user-name.

> in fact described RADIUS attributes that could be used to 

What are the normative requirements you mention?
Let me be clear that SSH does NOT need to use RADIUS at all. The
choice to do so is a deployment decision made by the operator. SNMP in
no way requires it, and SNMP should not even know about the RADIUS
connection if SSH does use RADIUS to perform authentication.

> describe that behavior in a Standards Track RFC?

1) SSH provides an "snmp" subsystem. I'm not sure NAS is appropriate
here. I'm not sure whether your "base-level" service provisioning goes
beyond that.
2) I'll let the chairs and AD decide what ISMS has leave to do in a
Standard Track RFC.
3) If SSH chooses to use a RADIUS server to advise it whether to
provide the "snmp" subsystem requested by the SSH user, then SNMP
should know nothing about the fact that SSH chose to consult RADIUS.

> implementations, I believe.  Is this OK?

What changes are you referring to? 
It requires that the SSH server used must be able to open an "snmp"
subsystem.
I'm not sure what other changes are required to SSH.

There are other changes that COULD be made to an SSH server. For
example, such an SSH server might support the "managament" attributes
you have proposed. But I'm not sure that is a requirement.

dbh