Re: [Isms] Moving into some design/architecture issuesofExtendedVACM
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.