RE: [Isms] charter proposal user-group mapping

["David B Harrington" <ietfdbh at comcast.net>]

Hi Tom,

 

> So an end user logs onto a server running an SNMP Command 
> Generator, is
> authenticated and as part of that, the security server 
> specifies authorisations,
> access permissions, rights etc which are mostly defined by 
> being a member of a
> group.  The Command Generator now has everything the Command 
> Responder needs to
> know and so passes it, end user identity plus group 
> membership, to the Command
> Responder in a secure manner (ssh transport, security 
> parameters, authenticated,
> with
> integrity) which uses it to access the access control rules.
> 
> Obviously this does not yet exist for SNMPv3 but there are 
> parallels for other
> aspects of network management.  Again, I have no brief for 
> those who would
> implement such code but if we provide the protocol, I believe 
> it is a simple
> step forward.

We have provided the protocol - it is called SNMPv3, and we provided a
standards-based set of MIBs to hold such configuration information.
Making the security remotely configurable was a definite design
decision of the SNMPv3 WG.

It certainly would be possible for a network management application (a
Command Generator) to authenticate itself to the managed entity using
USM (user=HPOV) and then, assuming it had appropriate rights via VACM,
populate the USM tables and the VACM user-to-group mappings for the
person who has authenticated themselve to the application (using OS
security mechanisms). Then the application can perform all SNMP
operations as the individual requesting the operation. 

All of this is imminently doable already, using industry standard
mechanisms (SNMPv3/MIBs) already resident on the networking devices of
most major equipment vendors, and readily available in many toolkits
with host management capabilities.

The application models exist in an application subsystem and new
applications can be developed. Do you want to develop a security model
or new command generator application that performs this type of
forwarded security configuration?

Do you think the application should pass the OS-authentication
username/credentials to the managed entity? I think this would be a
bad practice security-wise. 

Passing OS credentials to a managed device could be a mess
configuration-wise because host-side authentication is typically not
vendor-neutral, and would be difficult to support for all variations
of LDAP server, ActiveDirectory, etc. 

Do you think the application should pass some type of vendor-neutral
authentication credentials into the managed system? Do you think the
protocol to pass on the information should be secure? If so, why not
use SNMPv3 to do so? That's why we provided a standards-based protocol
and data schema for this purpose.

> 
> Likewise, my knowledge of standards-based systems leads me to 
> believe that this
> could be done with them (although not necessarily with all of them).

standards are great, everybody should own one?
Why not use a vendor-neutral standard, such as SNMPv3?

> 
> I do believe that retrieving the group membership at the time 
> the SNMPv3
> principal is authenticated is the key function and that 
> everything else needs to
> stem from it. 

I question the need to do this. If HPOV is an authenticated entity
with manageent rights on a remote device, and a user authenticates to
HPOV, why not simply let HPOV request the SNMP operations for the
user? That would minimize the amount of remote configuration needed.
Why go through the whole process of configuring the user credentials
into the managed device and then sending messages using the
authentication information of that principal? Why not just act as a
trusted proxy for that principal (which you would be doing in either
case)?

Oh, because we want to track who made what changes to which managed
objects? I've heard this for years and have never seen it actually
done. How does one do this? I am aware of no standard mechanism that
provides the promised logging or auditing of SNMP operations.
Certainly HPOV could track which requests it performed for which
authenticated users, and that would make it a non-requirement for the
managed station to maintain such auditing info. 

So do we really gain anything by having a Command Generator populate
user info or user-to-group mappings at the time of authentication?

David Harrington
dbharrington at comcast.net




_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms