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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 31 Jan 2005 12:40:22 +0100

I am really a bit appalled by the continued suggestions/discussions
that VACM is too complex for those who want to keep things simple. 

If you look at appendix of RFC3415, there are suggested configs that 
are (in my view) VERY SIMPLE and VERY STRAIGHTFORWARD for those who
do not need a fine grained access control.

Is that just me?

And it is also pretty straight forward to define a few users that
have access with the simple access control setup.

I agree that it is quite complicated if anyone wants to use all the
capabilities of USM and VACM.

I will also agree that we could specigfy some more default configs
that may help operators even more than the initial configs
in the current RFCs. But I do not buy the idea that doing
a simple access control is all that difficult.

Bert
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of David B Harrington
Sent: Saturday, January 29, 2005 18:13
To: 'Martin Soukup'; 'David T. Perkins'
Cc: [email-masked]
Subject: RE: [Isms] Evaluation status [and more]

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: "David B Harrington" <[email-masked]>
Date: Mon, 31 Jan 2005 08:10:29 -0500

Hi bert,

The problem isn't that VACM is too complex; it's that there is
complexity and an associated learning curve, and we aren't helping
peolle scale the learning curve. For somebody that already understands
VACM, it may seem simple, but for people who have a different mind-set
about how to do access control, changing to the mind-set required by
VACM can be a deterrent to adoption. It is not a simple learning
curve.

People who have always managed their networks using communities need
to change their mindset to think in terms of views and contexts and
groups. Think about the large number of people who run using the
current defaults of "public", "private" and "superuser" communities
because the vendors didn't make it easy to change the community names
on their devices, or because SNMP security hasn't been their highest
priority because there are so many other security problems they need
to work on. And if you get the migration from communities to context,
views, and groups wrong, they could endanger the security or the
manageability of the network. And you expect them to just "grok" VACM
from the examples in the appendix of RFC3415?

If I am used to thinking in terms of public, private and superuser
communities to provide access control, and I suddenly need to
configure SNMPv3 in my devices, show me where in Appendix A you tell
me how to create public, private, and superuser "communities" in VACM.
I see descriptions of a default context "" and an "initial" group, and
"restricted" views, etc. But I'm used to getting my devices with
preconfigured communities and MIB modules already assigned into
different communities and so on. How do I transition from the way I
typically think of the problem to this new way (and of course, I'm
also at the same time trying to learn about MD5 authentication, and
DES encryption, and trying to solve the problem of updating the keys
across the whole system simultaneouly, and other aspects of SNMPv3 as
well).

Now a vendor needs to determine how to preconfigure its assignment of
mib modules to ... What? To views? To contexts? To groups? We cannot
even agree amongst ourselves whether vendors need to pre-assign the
mib modules to contexts or views or groups in order to parallel the
community approach, but somehow we expect that the vendors will just
somehow get it right? And if different vendors do it different ways,
then the operators have to sort out the mess, but we should be
appalled that people suggest VACM is complex?

We should help make the trasnition easier by defining VACM defaults
that are consistent with the way users view the world already, and
then they can extend it in more advanced ways as they're ready. Users
do not currently think in terms of "", "initial",
"initial-semi-secure-configuration", "minimum-secure", "semi-secure"
and so on; they think in terms of public, private and superuser
communities. 

Defining defaults that correspond to the traditional concepts could
help overcome one of the thresholds that makes adoption of SNMPv3
harder.

David Harrington
[email-masked]

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Monday, January 31, 2005 6:40 AM
> To: [email-masked]; 'Martin Soukup'; 'David T. Perkins'
> Cc: [email-masked]

> [mailto:[email-masked]]On Behalf Of David B Harrington
> 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
> 
> 
> 
> 
> 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. 
> [mailto:[email-masked]] On