Re: [Isms] Moving into some design / architecture issues ofExtendedVACM

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Tue, Jun 16, 2009 at 03:03:00PM +0200, David Harrington wrote:

> I assume the ACM precedence table must be preconfigured, just as the
> policies are. I do think there will be plenty of problems forcing one
> ACM to always have precedence, and I can envision admins wanting one
> system to have precedence for some users (e.g., the IT staff, in case
> of the need to override RADIUS), while other users should always be
> controlled under the RADIUS approach. But setting precedence by user
> would require preconfiguration of the users. ACM Precedence probably
> needs to be by group. Setting precedence might be able to be added for
> a user/group mapping by adding an ACM selector to the RADIUS
> attributes. That might not work for the it-group, though. I think the
> precedence table needs to be similar to a capabilities negotiation; an
> admin can configure the table to say "RADIUS takes precedence for this
> group if it is available; otherwise USM MAY be used by this group."
> For non-emergency uses, RADIUS could specify the precedece order for a
> group, but somehow, the security admin needs to be able to say that
> "this group needs authorization to override a RADIUS rejection".

Way too complex if you ask me. Such an ACM precedence table should be
as minimal as we can make it - and Randy believes even that is way too
complicated because of ACM optimizations some SNMP toolkits do for
performance reasons. For me, the minimal solution is a table
consisting of a priority column and an ACM identification column.

If I would have a configured precedence like try first RVACM (Radius
VACM) and then VACM, then RVACM might return a statusInformation of
the isAccessAllowed() allowed that tells my code to 'continue' with
the next ACM. However, VACM does not have such a continue return code
defined (RFC 3415 page 7) so I would assume that a VACM decision is
always final (access/failure). In other words, the precedence VACM and
then RVACM would never reach RVACM.

Here is what this exercise boils down to:

a) A control table needs to be defined that specifies the precedence
   order in which ACMs are consulted.

b) A very slight change to the isAccessAllowed() ASI since the
   statusInformation would be "success or errorIndication or continue"
   for new ACMs.

c) Updates would be needed to section 3.2 of RFC 3413 step (5) where
   isAccessAllowed() is called from Command Responder applications

d) Updates would be needed to section 3.3 of RFC 3413 step (2) and (3)
   where isAccessAllowed() is called from Notification Originator
   applications

Putting my chair hat on, the question is whether ISMS is chartered to
do such a piece of work that affects several core SNMPv3 documents.
So far, work on new access control models was clearly out of scope for
this WG. The proposed new charter text also talks pretty clearly about
"a binding between a user and preconfigured VACM policies via dynamic
additions to the securityToGroupname table." So if this charter gets
approved, I believe the work outlined above falls out of the charter
and we have to come up with some other sensible ways to deal with
conflicts that can happen if RADIUS is asked to overwrite existing
table entries.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>