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

From: "David B Harrington" <[email-masked]>
Date: Fri, 16 Dec 2011 18:28:07 -0500

This didn't get to the list.

dbh 

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Friday, December 09, 2011 10:44 AM
To: 'Bert Wijnen (IETF)'
Cc: 'Martin Bjorklund'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: David Harrington's Discuss on
draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT)

Hi,

I don't think that's adequate.

The way NACM is written, additional groups can be specified by any
transport [model].
So it is not just RADIUS that is a concern; it is ANY transport
(model) that might provide groups.
Somebody could rewrite netconf/SSH and somehow add a group thing to it
(I have no idea how).

Security is a process. The ability to control addon groups must work
across all transport models.
An admin might want to disable the addon-groups feature globally.
An admin might want to control specific transport models and not
others.
If a transport model is developed that supports the addon-group
feature but doesn't offer an enable/disable capability, and NACM
doesn't have a global switch, then we have a problem. 
The admin cannot configure either approach.

I think the right way to handle this is to 1) provide a global switch,
and 2) make it a requirement of NACM that *if** a transport model
supports the passing of addon-groups for NACM, in whatever way, then
it MUST offer an administratively configurable knob to enable/disable
the functionality
for that transport model.

In 2.5, you have this text:
   The ACM needs to support the concept of administrative groups, to
   support the well-established distinction between a root account and
   other types of less-privileged conceptual user accounts.  These
   groups needs to be configurable by the administrator.

   It is necessary that the user-to-group mapping can be delegated to
a
   central server, such as a RADIUS server [RFC2865] [RFC5607].  Since
   authentication is performed by the NETCONF transport layer, and
   RADIUS performs authentication and service authorization at the
same
   time, the underlying NETCONF transport needs to be able to report a
   set of group names associated with the user to the server.

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?
In ISMS, the RADIUS folks argued that RADIUS should override the
administrator; the SNMP folks argued that a configuration done by the
human administrator should take precedence over what RADIUS says,
because the human might know something that RADIUS doesn't. same
debate: Policy-server versus human; who gets precedence? In ISMS we
settled on a way to determine user-to-group mappings that RADIUS could
not override (those that were not explicitly marked volatile in the
MIB). In ISMS, we have a 1:1 user-to-group constraint; as a result, if
there was a non-volatile entry for a user, RADIUS could not modify or
add on additional user-to-group mappings.

Netconf, however, doesn't have a 1:1 constraint, and doesn't have a
MIB for NACM user-to-group bindings that gets modified when a
transport layer reports user-to-group bindings; apparently the
expectation is that the addon-groups will only be implemented as a
temporary binding associated with the session rather than a change to
the NACM pre-configuration. So the admin has no way to control these
addon bindings; they cannot set the pre-configured user-to-group
bindings as non-volatile to prevent dynamically changing the set of
groups a user belongs to; they cannot disable the dynamic addon-group
feature of NACM when they are in the process of debugging
misconfigurations or tracking down a security problem. 

The only way, currently, for an operator to shut off the policy-driven
group-addons is to go to the (RADIUS) policy server to remove the
addon groups [which is equivalent to having to modify a COPS-PR policy
at the policy server as the only way to override COPS-PR; even COPS-PR
had a global switch for disabling policy that netconf does not).

So I think, based on the long discussions we've already had in IETF
about policy-driven versus human-configured, there needs to be a
global switch to disable this dynamic user-to-group policy feature in
NACM, and (if the WG wants this extra complexity) each transport that
offers dynamic user-to-group mappings MUST have a knob at the
policy-enforcement-point, that allows an operator to do a
dynamic-policy-override, either manually or by pre-configuration of
NACM user-to-group bindings that cannot be modified (including adding
on extra user-to-group bindings) by THAT transport.

dbh

> -----Original Message-----
> From: Bert Wijnen (IETF) [mailto:[email-masked]] 
> Sent: Friday, December 09, 2011 8:53 AM
> To: David Harrington
> Cc: Martin Bjorklund; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: David Harrington's Discuss on 
> draft-ietf-netconf-access-control-06: (with DISCUSS and COMMENT)
> 
> David, W.r.t. to this discuss item, I check (as per below) with
> the editor/author Martin, and I think that doing a YANG module
> for aka radius-for-netconf migth make sense, and if we do so
> then we can include such a leaf to disable the usage of the
> Management-Policy-ID attribute.
> 
> But I doubt we should do radius specific stuff in the NACM
> module itself.
> 
> So the proposal is to just add the suggested text to the
> security considerations. Will that work for you and clear
> your discuss?
> 
> Thanks,
> Bert
> Document Shepherd
> 
> 
> On 12/9/11 9:35 AM, Martin Bjorklund wrote:
> > "Bert Wijnen (IETF)"<[email-masked]>  wrote:
> >>
> >>
> >> On 12/9/11 9:05 AM, Martin Bjorklund wrote:
> >>> For bullet 1 below, I suggested:
> >>>
> >>>       An administrator needs to be aware of the security 
> properties of
> >>>       any AAA protocol used by the NETCONF transport protocol to
> >>>       determine group names.  For example, if the AAA 
> protocol does not
> >>>       protect against man-in-the-middle attacks, an 
> attacker might be
> >>>       able to inject group names that are configured in 
> NACM, so that a
> >>>       user gets more permissions than it should.  In such 
> cases, the
> >>>       administrator may wish to disable the usage of such 
> group names in
> >>>       the AAA protocol.
> >>>
> >>
> >> Does that not just mean to disable the "AAA protoco;" for use by
> >> NETCONF server?
> >> Is that then not a AAA issue?
> >
> > Right; at least an AAA-specific issue, when the AAA protocol is
used
> > with NETCONF.  But disabling it completely doesn't solve 
> the problem.
> > The issue is this:
> >
> > Suppose an administrator descides to use RADIUS for authentication
> > only.  He sets up his RADIUS server to just do 
> authentication.  On the
> > NETCONF device, he configures a "guest" group, to which all remote
> > users are mapped.  Now, an attacker manages to do a 
> man-in-the-middle
> > attack, where he modifies the reply from the RADIUS server to also
> > inclue a Management-Policy-ID attribute with the value "admin".
The
> > NETCONF server picks it up, and assigns this remote user to the
> > "admin" group which has full access to the entire box.
> >
> > So, IMO, the "radius-for-netconf" YANG module should 
> contain a leaf to
> > disable the usage of the Management-Policy-ID attribute.
> >
> > Making a global leaf is to coarse, since if one AAA protocol is
> > secure, and another one is not, then disabling this for both is
not
> > useful.
> >
> >
> > /martin
> >
> >
> >
> >> Sure we could add something to NETCONF too, but do we have 
> to do so at this
> >> stage in the process?
>  >>
> >>  Bert
> >>
> >>> To which dbh replied:
> >>>
> >>>     Good, but you need to make the object for 
> enabling/disabling the
> >>>     functionality a must-implement, or it won't be there when an
> >>>     operator needs it.
> >>>
> >>>
> >>> Can we tweak the text I suggested somehow so that it 
> makes him happy
> >>> without us adding this global leaf?  It is a bit hard to add
> >>> must-implement objects in the Security Consideration...
> >>
> >
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Dec 2011 16:17:15 -0800

> This didn't get to the list.

I'm trying to catch up with these details -- see inline...

> dbh

Andy

> An admin might want to disable the addon-groups feature globally.

We have this knob.  I hope that is not the issue.

> An admin might want to control specific transport models and not

I don't know if we need this knob, but I'll take your word for it.

> for that transport model.

This seems OK to me.
I think we could actually construct a YANG module (using an identityref ID)
so individual switches could be added for new transport protocols without
rewriting the NACM module.

> 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.

> on extra user-to-group bindings) by THAT transport.

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 17 Dec 2011 11:31:01 +0100

> 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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 17 Dec 2011 12:49:04 +0100 (CET)

Hi,

>     used at all (global on/off switch)

This was what dbh suggested, and we believe this is a good idea.  So
we propose we add this.

Furthermore, Andy suggested that the entire concept of "allow
dynamically learned groups" should be a YANG feature.  I.e., optional
to implement.

>     transport's provided dynamic group mappings (this is what DBH

This is what I personally think makes most sense; since it depends on
the transport if you trust it to do the right thing or not.

In any case, this is outside the scope of NACM.

>     accept dynamically learned group entries

Hmm.  I was thinking it might be useful to do this on a group basis.
I.e. maybe you don't want the "superuser" group to be added
dynamically.

/martin