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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 31 Jan 2005 14:42:00 +0100

Inline

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]]
> Sent: Monday, January 31, 2005 14:10
> To: 'Wijnen, Bert (Bert)'; 'Martin Soukup'; 'David T. Perkins'
> Cc: [email-masked]
> Subject: RE: [Isms] Evaluation status [and more]
> 
> 
> 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. 

Darn simple, use the default included in appendix A and you are
basically all set!

Only if you want to do more than that, that is where it becomes
a bit more complex!

> 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?
> 
YES! I am sure such is not more difficult than for me understainding
how to add certificates for SSL and SFTP to my system.

> 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. 

So you are telling me that the vendors give you a ahrd time!

> 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).
> 

The KEYS updating and MD5 and DES issue has nothing to do with VACM.
I know that USM is not easy.

> 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?
> 
And you think that that is gonna change withanything new that we 
develop in this WG ?? Vendors will keep doing things their own way.

> 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.
> 
So go ahead and write an I-D that defines that!

Bert
> David Harrington
> [email-masked]
> 
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [Isms] Evaluation status [and more]
> > 
> > 
> > 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: "Tom Petch" <[email-masked]>
Date: Mon, 31 Jan 2005 18:33:59 +0100

Yes I would be keen to see an ID along the lines given below, seeing it as an
additional appendix to RFC3415,  and would be willing to help in whatever way I
can.

But as my posts show, I lack the VACM skills to generate the technical details
(or any
software to test them with) of the ideas I have in mind..

Tom Petch
----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: <[email-masked]>; "'Martin Soukup'" <[email-masked]>; "'David T.
Perkins'" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 31, 2005 2:42 PM
Subject: RE: [Isms] Evaluation status [and more]

> > Subject: RE: [Isms] Evaluation status [and more]
<snip>
> So go ahead and write an I-D that defines that!
<more snip>