Re: [Isms] Moving into some design/architecture issuesofExtendedVACM

["David Harrington" <ietfdbh at comcast.net>]

Hi,

At the risk of repeating myself ;-) ...

If you design an ACM that operates with a totally different set of
assumptions, then you are designing a new ACM, not extending an
existing one. 

If you want an ACM that operates following RADIUS, rather than SNMPv3,
assumptions, then I think you need to design a new ACM and that means
you need to address the issue that the SNMPv3 WG did not provide an
ACM selector. 

That will take significantly more time to address than simnply adding
some RADIUS attributes to allow dynamically provisioning the existing
VACM models.

I expect there would be other significant problems to solve besides
the selector to get RADIUS-like assumptions built into SNMPv3; The
SNMPv3 WG **deliberately** split authorization from authentication,
using only the ASIs for bindings. I think you will effectively be
trying to design a new SNMP architecture based on AAA assumptions if
we follow your reasoning here. The RADIUS and SNMP architectures do
not match, and ISMS has not been authorized to totally redesign SNMP
and its assumptions.

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Dave Nelson
> Sent: Monday, June 15, 2009 11:27 PM
> To: isms at ietf.org
> Subject: Re: [Isms] Moving into some design/architecture 
> issuesofExtendedVACM
> 
> Randy Presuhn writes...
> 
> > Repeating myself: this would interact badly with security policy
> > updates. It is much safer for changes to vacmGroupName in a
> > vacmSecurityToGroupEntry to behave just like they would if they
> > had been set.
> 
> I think we're talking at cross purposes.
> 
> You seem to be talking about maintaining consistency between 
> RADIUS usage
> and manual security administration.  IIRC, the whole premise 
> of the ISMS
> work is that many operators feel that SNMPv3 security is simply too
> complicated to deploy.  So they don't.  They want something 
> ties into their
> existing infrastructure.
> 
> We're talking about two different audiences, those who like 
> SNMPv3 security
> and use it as defined today and those who don't.  The ISMS 
> work address the
> "those who don't" audience.  I think, by definition, there aren't
any
> operational conflicts to be resolved.
> 
> Beyond that, I think you need to seriously consider other 
> examples of how
> local, static authentication and authorization is integrated 
> with remote,
> dynamic authentication and authorization.  There are 
> precedents.  The UNIX
> login usage (NIS vs. /etc/passed file) is just one.
> 
> I too am repeating myself, and it seems that we simply look 
> at this problem
> very differently.
> 
> 
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>