Subject: [Isms] RE: Should ACM close a subsystem?

From: "Nelson, David" <[email-masked]>
Date: Wed, 28 Jun 2006 16:01:19 -0400

David Harrington writes... 

> It was suggested that an ACM model querying a RADIUS service might be
> advised that a principal is not permitted to perform SNMP to the
> device, and that the ACM model should request that the SSH subsystem
> be closed.
> 
> I strongly disagree with this.
> 
> We want a separation between authentication and authorization. And we
> want ACM models to be independent of the transport used.
> 
> If an implementer wants to optimize their implementation to do this,
> fine, but it should not be part of the standard.

So it doesn't concern you that unauthorized users are able to open SSH
sessions and receive SNMP service?  It is (hopefully) true that these
unauthorized users won't be able to actually access any objects, because
ACM is blocking them.  This doesn't strike me as a good "defense in
depth" design approach, however.

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 Jun 2006 17:34:06 -0400

> depth" design approach, however.

Only an authorized user will be permitted to open the SSH session.
That is, they will be authorized to open an SSH session, not
necessarily to perform SNMP operations. It might be possible for SSH
to restrict that further - only those authorized to open an SSH "snmp"
subsystem will be allowed to open an SSH "snmp" subsystem. It is fine
with me that a user authorized to open an "snmp" subsytem is permitted
to do so.

It is fine with me that an admin may configure the ACM model to deny
the rights to actually do anything using SNMP, for a user authorized
to open an SSH "snmp" subsystem.

Let's consider a company with multiple operators authorized to get
SNMP access to devices. Now let's consider that the company might have
multiple locations, say Rochester and Andover, and that some operators
are permitted to modify the SNMP configurations in Rochester, but only
to read those in Andover, i.e. they are authorized to open an SSH
"snmp" subsystem in either location. 

The company can distribute different static VACM configurations to the
devices in Rochester and Andover, with the securityName of the
particular admin assigned to groupname "super-user" or
"read-only-user", depending on where the device is located. Or the
VACM config could deny them the right to do anything at all with SNMP
to that device, not even read SNMP. I don't really care if they can
open the "snmp" subsystem, as long as they can only do the SNMP
operations on that device that VACM allows.

Note that I am talking about whether a user should be allowed to open
a session, even if the VACM configuration prevents them from doing
anything.

I am not talking about whether distributing different static VACM
configs to different locations is the best approach; I think there are
better ways, but I think they are independent of whether the user can
open an "snmp" subsystem and then not be permitted to do anything.

Defense in depth is nice, but what happens if the user has access to
the system both via SSH and USM and SNMPv1 communities? Why do we want
to depend on SSH to determine whether the user can access the data? I
want to depend on the ACM whose very purpose is to make that specific
determination.

dbh