Subject: Re: [Isms] securityName

From: "Tom Petch" <[email-masked]>
Date: Mon, 25 Jul 2005 14:59:11 +0200

<at the bottom>

Tom Petch
----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 25, 2005 5:15 AM
Subject: RE: [Isms] securityName

> Hi Tom,
>
> Let me provide some historical background before I address your
> concerns:
>
> SNMPv3 was deliberately made modular so different portions of the
> SNMPv3 standard could be upgraded independently of other pieces. From
> RFC 3411: "This modularity allows, for example, Security Models,
> authenication and privacy mechanisms, and message formats to be
> upgraded and supplemented as the need arises."
>
> The authentication subsystem has been deliberately kept separate from
> the access control subsystem. They are related only in that the output
> of the authentication subsystem is securityModel, securityName, and
> securityLevel, and the input to the access control subsystem is
> securityModel, securityName, and securityLevel.
>
> In the same way, the application subsystem has been kept separate from
> the access control subsystem. They are related via the
> IsAccessAllowed() ASI. The access control model does not know which
> application is asking the question, and the application does not know
> the details of how the answer to the IsAccessAllowed() question is
> arrived at.
>
> The SNMPv3 standard was developed with a set of initial models for
> each subsystem, to prove that the pieces could be developed following
> the modularity rules, and so the system could be implemented and "put
> to the test" so we could determine what problems needed to be
> resolved, and then resolve those problems by the development of other
> models for those subsystems. The initial models all have proven to be
> usable (to varying degrees), but not convenient, especially for large
> networks.
>
> The single largest complaint is that all the initial models require
> configuration via SNMP MIB modules (which can be populated via the
> SNMP protocol or via other means within the instrumentation). This ia
> a problems for a number of reasons - 1) many implementations do not
> support SNMP SETs, 2) many deployments do not allow SNMP SETs, and 3)
> many have considered the use of SNMP MIB modules to be "static"
> configuration that is hard to keep synchronized with other existing
> infrastructure. Many have expressed the desire that SNMPv3 standard
> models be developed that automate the configuration by leveraging
> existing non-SNMP infrastructure to make the dynamic information
> available to SNMP entities, rather than populating MIB modules
> dynamically via SNMP.
>
> Some of the reported problems with the initial models:
> 1) Using USM for SNMPv3 authentication requires SNMP "static"
> configuration.
> 2) Using VACM for access control requires SNMP "static" configuration.
> 3) Using the SNMP-TARGET-MIB (RFC 3413) requires SNMP static
> configuration.
> 4) Using the SNMP-NOTIFICATION-MIB (RFC 3413) requires static
> configuration.
> 5) Using the SNMP-PROXY-MIB (RFC 3413) requires static configuration.
>
> **These are separable problems and, by SNMPv3 architectural design,
> separate problems.**
>
> To address your concerns:
> 1) ISMS has currently been chartered to resolve the problem that using
> USM for SNMPv3 authentication requires SNMP static configuration.
> 2) ISMS has explicitly NOT been chartered to resolve the problem that
> using VACM for access control requires static configuration.
>
> And concerns that you might get around to considering as well:
> 3) ISMS has NOT been chartered to resolve the problem that using the
> SNMP-TARGET-MIB (RFC 3413) requires static configuration.
> 4) ISMS has NOT been chartered to resolve the problem that using the
> SNMP-NOTIFICATION-MIB (RFC 3413) requires static configuration.
> 5) ISMS has NOT been chartered to resolve the problem that using
> SNMP-PROXY-MIB (RFC 3413) requires static configuration.
>
> I don't think anybody believes that simply solving the problem that
> using USM for SNMPv3 authentication requires static configuration will
> make SNMPv3 imminently deployable. The VACM problam also needs to be
> resolved. Once these two problems are solved, SNMPv3 might be more
> deployable, but the other problems of static configuration will
> probably need to be resolved as well.
>
Mmmm I think I was hoping for rather more from isms.  Reminding myself of the
charter, it
identifies two problems as inhibiting the deployment of SNMPv3:
- distributing and maintaining VACM rules is difficult in large-scale
environments.
- addition of yet another authentication system specific to SNMPv3 that needs to
be maintained across all networking devices
so my hope was that we would fix the second and SNMPv3 would be imminently
deployable except where fine-grained access control was also needed.  (I do not
have concerns about the static configuration of the TARGET-, PROXY- and
NOTIFICATION- MIB; need fixing but less urgent for me so you won't hear me
mentioning them again:-).

<snip>

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