Subject: RE: [Isms] Re: modularity

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 1 Aug 2005 13:59:28 -0700

Tom,

I agree with you about VacmGroup mappings. My primary hope for ISMS is
to leverage existing authentication systems for SNMP authentication and
authorization. If those systems support "roles" then roles (including
RBAC) is also supported. However, because these issues are determined by
the authentication system, which is external to SNMP, and the specific
authentication and authorization schema should be transparent to SNMP
itself. 

The issues that I am struggling with from these many recent postings are

(1) "what are the SNMP interfaces to that external authentication
system?" and 
(2) "How much does ISMS leverage SNMPv3 USM and VACM? I.e., does it do
'security level' in the traditional way or has all security been
'outsourced' to another element?"

Reading the various postings, it seems to me that the WG still doesn't
have a common model in mind for these fundamental -- and core -- design
issues. I am particularly alarmed that some still want to make minimal
changes to SNMPv3 USM and VACM and others want to make major
replacements to USM and VACM. Can we please reach consensus on that
fundamental point, which, to me, are much more fundamental than whether
we use SSH or TLS or DTLS?

--Eric

-----Original Message-----
From: Tom Petch [mailto:[email-masked]] 
Sent: Monday, August 01, 2005 10:31 AM
To: Randy Presuhn; [email-masked]
Subject: Re: [Isms] Re: modularity

I find myself thinking that user to VacmGroup mapping does not belong in
either SM or ACM and that that is the crux of the problem.  Integration
with existing security structure means, for me, that the authoritative
engine for this mapping is elsewhere, in the organisation's security
server, eg in RADIUS, so that placing it in either SM or ACM is or will
be a problem for SM or ACM or both.  Rather, SNMP should only be caching
this information for as little time as it needs it, be that in
'manager', 'agent' or whereever, a bit like the state references in the
ASIs..

As I have commented before, SNMPv3 sets out to do everything for itself,
to be complete in itself, and that is no longer the market place we are
in.

The actual access rules within VACM are a different matter, because they
are so SNMP specific so I do see them as properly part of an ACM MIB in
the engine of the Command Responder..

Tom Petch

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 1 Aug 2005 17:45:30 -0400

Hi Eric,

> fundamental point

The SNMPv3 WG did have consensus on a common model, and documented
that consensus. To be consistent with the RFC3411 architecture, both
USM and VACM should remain unchanged, and be able to coexist with
supplementary security and access control models, such as those that
outsource the security to other elements. The MIB module for USM
should be used only by USM, and the MIB module for VACM should be used
only by VACM, and any new secuirty model or new AC model should define
its own MIB module, and only it should access that model-specific MIB
module.

Regarding scalability, the SNMPv3 WG reached consensus on the
following design decision:
"      - Controlled Complexity
         It is recognized that producers of simple managed devices
want
         to keep the resources used by SNMP to a minimum.  At the same
         time, there is a need for more complex configurations which
can
         spend more resources for SNMP and thus provide more
         functionality.  The design tries to keep the competing
         requirements of these two environments in balance and allows
         the more complex environments to logically extend the simple
         environment."

USM's local accounts represents the simple model, which is suitable
for simple environments; interfacing to external security
infrastructure for scalability is a requirement of a more complex
environment, and can be achieved by designing a separate,
supplementary security model, and a separate supplementary access
control model.

David Harrington
[email-masked]
co-chair IETF SNMPv3 WG, concluded