Re: [Isms] Moving into some design /architectureissuesofExtendedVACM

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Dave Nelson" <d.b.nelson at comcast.net>
> To: <isms at ietf.org>
> Sent: Thursday, June 11, 2009 6:28 AM
> Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM
...
> If there is a mismatch in policy/group names between the RADIUS server and
> the network devices, users will get authenticated, an SNMP session will
> start, e.g. over SSH, but the VACM will not provide any access to MIB
> objects.  Is there an SNMP-level error message that will inform the user
> where the problem lies?

It depends.  Assuming the group is created automatically, in response
to an SNMP operation you might get "noSuchName", which would
be indistinguishable from "the data doesn't exist", or you might get
"authorizationError", which lets you know that the access-
control system kept you away from the information.

If the group were *not* created automatically (except when there is
something, such as corresponding entries in vacmAccessTable,  to
indicate that the group is "intended" to exist) then you're guaranteed
"authorizationError" in SNMPv3 by the procedures on page 12 of RFC
3413.

Even in this latter case, the operation *might* suceed if tried again later.
Consider this scenario:  while the security administrator is in the process
of pushing the updates to the vacmAccessTable in accordance with the
procedures spelled out in that table's DESCRIPTION, the rights granted
to members of that group will only stay the same or increase with each
update, so that members of that group can be assumed to have been
granted their full rights on that system only after *all* the relevant entries
to the vacmAccessTable have been successfully pushed.

I think the upshot of this is that carving out an exception doesn't actually
make anything easier here.

Randy