Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT)

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Dec 16, 2011 at 04:17:15PM -0800, Andy Bierman wrote:

> >I suggest you add text that saya "Since an administrator may define
> >the user-to-group mappings to constrain a user' rights, an
> >administator MUST be able to configure NACM to not consider
> >the dynamically-reported extra user-to-group mappings reported by the
> >underlying NETCONF transport in the detrmination of user permissions."
> >(i.e., a switch that says NACM can consider the INTERSECTION of the
> >pre-configured and dynamic mappings, but not the UNION of the two. The
> >default is to consider the union.)
> >
> >Remember COPS-PR, and its global lock that prevented an admin from
> >overriding the policy server, inclduing with other NM protocols?
> 
> Yes I remember it well.
> NETCONF nor NACM is anything like the all-or-nothing limitations of COPS-PR.
> An admin could hard-wire the user to group mappings in the local tables
> and set the global switch to off.
> 
> But I agree your individual switches are better, so I'm OK with that.

My understanding is that with ISMS, local configured mappings
overwrite mappings obtained from other sources. If that is the
behaviour we want, we should make it so. Switches that turn on/off
_all_ dynamic mappings associated with a given transport are rather
course grained and operationally likely not very helpful to resolve
conflicts.

In VACM, a (security name, security model) pair maps to exactly one
group. This is rather different in NACM where a user name can be in
multiple groups and dynamic group mappings provided by the transport
are currently simply added to the set of groups a user belongs to. As
a consequence, the solution likely needs to be different in that we
might need to be able to configure in NACM

(a) at a course grained level whether dynamically learned groups are
    used at all (global on/off switch)

(b) at the level of a given transport whether we trust all of the
    transport's provided dynamic group mappings (this is what DBH
    suggested I think)

(c) at the fine grained level of specific user entries whether we
    accept dynamically learned group entries

It might be operationally relevant to allow a configuration that
generally rejects dynamic group mappings (for a given transport)
except for a white list of users where we trust the transport to do
the right thing.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>