Subject: RE: [Isms] Evaluation status [and more]

From: "David B Harrington" <[email-masked]>
Date: Sat, 29 Jan 2005 12:12:49 -0500

Hi Martin,
 
I haven't seen anybody suggest that any proposal mentioned would solve
everybody's problems. VACM is granular and complex so it can be
configured to meet a wide range of needs. But having a highly
granular, complex access control system also doesn't solve everybody's
problems if many of the targeted users cannot figure out how to
migrate to it, and the implementations provided by vendors make it
hard to configure to meet operators' needs.
 
We need to help users who don't need all the complexity to use it in a
simple manner, and to standardize some vendor-neutral defaults to
simplify the migration from the SNMPv1 approach to the SNMPv3
approach.
 
dbh

  _____  

From: Martin Soukup [mailto:[email-masked]] 
Sent: Saturday, January 29, 2005 9:21 AM
To: 'David T. Perkins'; David B Harrington
Cc: [email-masked]
Subject: RE: [Isms] Evaluation status [and more]

I definitely support the specification of a base set of capabilities
and their use on the device to provide simplicity and commonality to
the administration of simple devices, but it would be a real shame to
think that this would solve everyone's problems. I thought the point
of VACM is to provide a significant range of possible access control
models depending on the granularity and complexity required?

Martin. 

> -----Original Message----- 
> From: [email-masked]
[mailto:[email-masked]] On 
> Behalf Of David T. Perkins 
> Sent: January 28, 2005 5:25 PM 
> To: David B Harrington 
> Cc: [email-masked] 
> Subject: RE: [Isms] Evaluation status [and more] 
> 
> HI, 
> 
> Interesting... 
> Lets say there are three "roles" or "capabilities", 
> which would correspond to VACM groups. Given 
> these, the standards track documents containing MIB modules 
> could indicate which objects and notifications should 
> be available for access type for each role. Given this 
> info in RFCs, it would be a mechanical process to 
> create entries in the view, and access tables. 
> That is, entries in table vacmViewTreeFamilyTable, 
> and table vacmAccessTable. 
> 
> Entries would be created in tables usmUserTable and 
> vacmSecurityToGroupTable when support for a new a user 
> is added. And entries would be created in tables 
> snmpCommunityTable and vacmSecurityToGroupTable 
> when support for a new community string is added. 
> 
> 
> On Fri, 28 Jan 2005, David B Harrington wrote: 
> > > -----Original Message----- 
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Randy Presuhn 
> > > 
> > > If I understand you correctly, you're making a couple of claims:

> > > 
> > >     1) the number of groups in most VACM configurations would be

> > >         two or three.  (For a lot of equipment, I believe 
> > > this to be true.) 
> > > 
> > >     2) the decision about which bits of management information 
> > should 
> > >         be accessible to which of these groups does not need to
be 
> > >         under control of the security administrator. 
> > > 
> > >     3) equipment manufacturers will decide which groups get 
> > > which access, 
> > >         and it would be acceptible if this could be changed only
by 
> > a 
> > >         firmware/software upgrade 
> > > 
> > > Did I get this much right? 
> > > If so, do you think a standard policy for these could be 
> > > formulated as an 
> > > addendum to RFC 3415 appendix A.1? 
> > > 
> > > Randy 
> > > 
> > I believe this is fairly accurate as a representation of what
exists. 
> > And I think we coul dhelp the SNMP community migrate from
communities 
> > to VACM much more than we have by defining incremental migration 
> > paths. 
> > 
> > We could do a service to operators by defining some standard
access 
> > control templates for VACM groups, comparable to public (r-o
most), 
> > private (r-w-most), and super-user (r-w-all).  This would help
admins 
> > accustomed to the traditional SNMPv1 communities to migrate to
VACM 
> > access control. Then admins could expand the group assignments
from 
> > that point if desired. I would consider adding a new
security-admin 
> > (r-w security mibs, such as VACM and USM and RADIUS) as well. 
> > 
> > I think it would help admins if we discussed how applications can 
> > serve as SNMPv3 USM users, for all their users. Some applications 
> > already provide user-level access control. I don't like this as
much 
> > as agent-access-control, but it is easier to configure USM with a
few 
> > applications than with larger number of users, while ISMS tries to

> > improve ease-of-use. On a side note, Spectrum used to provide 
> > something like nine levels of user access control, and now only 
> > provide three because customers never used the extra six levels. 
> > 
> > In SNMPv1, the immutable assignments were made to communities, but
I'm 
> > not sure whether contexts, views or groups are the right answer in

> > SNMPv3. Contexts are the immutable entities, so I think contexts
might 
> > be the right answer. I think we could help the vendors provide
default 
> > assignment of mib modules to public/private/root contexts by
providing 
> > a list of IETF mib modules, and recommend which context they
should be 
> > associated with. 
> > 
> > David Harrington 
> > [email-masked] 
> 
> Regards, 
> /david t. perkins 
> 
> 
> _______________________________________________ 
> Isms mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/isms 

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

---

From: "Martin Soukup" <[email-masked]>
Date: Sat, 29 Jan 2005 09:20:46 -0500

I definitely support the specification of a base set of capabilities and
their use on the device to provide simplicity and commonality to the
administration of simple devices, but it would be a real shame to think that
this would solve everyone's problems. I thought the point of VACM is to
provide a significant range of possible access control models depending on
the granularity and complexity required?

Martin.

> From: [email-masked] [mailto:[email-masked]] On
> > >         be accessible to which of these groups does not need to be
> > >         and it would be acceptible if this could be changed only by
> > a
> > I believe this is fairly accurate as a representation of what exists.
> > And I think we coul dhelp the SNMP community migrate from communities
> > We could do a service to operators by defining some standard access
> > control templates for VACM groups, comparable to public (r-o most),
> > private (r-w-most), and super-user (r-w-all).  This would help admins
> > accustomed to the traditional SNMPv1 communities to migrate to VACM
> > access control. Then admins could expand the group assignments from
> > that point if desired. I would consider adding a new security-admin
> > already provide user-level access control. I don't like this as much
> > as agent-access-control, but it is easier to configure USM with a few
> > In SNMPv1, the immutable assignments were made to communities, but I'm
> > SNMPv3. Contexts are the immutable entities, so I think contexts might
> > be the right answer. I think we could help the vendors provide default
> > assignment of mib modules to public/private/root contexts by providing
> > a list of IETF mib modules, and recommend which context they should be
> > associated with.
> >
> > David Harrington
> > [email-masked]
> 
> Regards,
> /david t. perkins
> 
>