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

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

Hi,

OK. We can simplify this if we do not change the assumptions in the
basic VACM model.

We need to allow RADIUS to provision the VACM user-to-group table, or
to provision a second table for user-to-group mapping, with an
admin-configured precedance table. I think the simplest approach is to
treat thia as a VACM extension, and that means it happens between the
isAccessAllowed() interface and the VACM elements of procedure. 

We add a second mapping table, and a precedence table, and some EOP
that immediately check the precedence table to determine which mapping
table to use. The only thing the precedence table decides is which
user-to-group mapping table to use. Once we have the correct table,
then VACM elements of procedure work as designed.

We can choose to not support a fallback approach; if RADIUS-authz
fails, well, it fails. An operator can try a different username, such
as root, to connect if RADIUS is not available. 

In this way, we do not need to add a "continue" option to
isAccessAllowed, and we are not changing any of the existing RFCs, or
any ASIs. We are merely developing an optional augmenting MIB module
for VACM with associated elements of procedure.

How an access control model decides to map users to policies has
always been considered the purview of the specific access control
model. All we are doing is adding some flexibility to VACM's decision
mechanism.

If we want to ensure there are no competing admins, but help admins
understand what is happening regarding authorization, we can make the
RADIUS mapping table into a read-only MIB module; only RADIUS can
alter it. 

I think the ACM precedence should be assigned per group. So you might
have most operators assigned groups in the RADIUS table, while a
select few operators (superusers) are configured to use statically
configured VACM. So it is a manual fallback design.

dbh


> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwaelder at jacobs-university.de] 
> Sent: Tuesday, June 16, 2009 11:06 AM
> To: David Harrington
> Cc: 'Randy Presuhn'; isms at ietf.org
> Subject: Re: [Isms] Moving into some design / architecture 
> issuesofExtendedVACM
> 
> 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/>
>