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

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 6 Jul 2006 09:54:31 -0400

>> It's important to remember that in VACM, the only access control
model
>> we have, if a user has no entry in the vacmSecurityToGroupTable [RFC
3415],
>> then no operations of any kind are permitted.
>
>Why should a user who is not authorized to use the system be allowed
>to create and keep an open SSH session? And why should such a user be
>allowed to send SNMP packets even if they will return just exceptions?

Because he is allowed to login as a system user, and you opted for a
common auth strategy? So he's perfectly OK to login via SSH, but not OK
to use SNMP?

>I consider an SSH connection establishment failure a clearer signal
>that someone is not authorized to talk to a system than letting the
>establishment of the secure channel succeed and then get just
>application layer access exceptions.

If you aren't allowed SSH - clearly you aren't allowed SSH-based SNMP.
The reverse isn't true.

>> I haven't been able to think of a reason why one might want to
>> create VACM entries for users who have no access rights to a system.
>
>You might have VACM entries for users which currently do not have
>authorization to access the agents but which had authorization in the
>past (and which might get it again in the future - e.g. a third party
>company helping an organization to manage boxes).

No. Such users would be removed as their authorization expires. It is
*extremely* poor security to leave the credentials (access rights) in,
and just "turn the login off".

>The motivation for RADIUS is to be able to control from a centralized
>system which authenticated user has the right to manage a device.

The danger is - local and central repositories of users diverging. 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Jul 2006 19:18:36 +0200

> common auth strategy? So he's perfectly OK to login via SSH, but not OK

Sorry, I was not clear. What I wrote "keep an open SSH session" I
actually meant "keep an open SSH session to an SNMP subsystem".

My thinking is biased by our prototype which uses an SSH library that
is integrated into the SNMP agent and thus a connection to managed by
this SSH library implicitely is a connection to the SNMP subsystem.
 
> If you aren't allowed SSH - clearly you aren't allowed SSH-based SNMP.

I am not even sure the first is generally true.

> The danger is - local and central repositories of users diverging. 

Exactly. This is why you want to have _all_ accounts controlled by
whatever central service you use (except a few emergency accounts).

/js

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