RE: a question about Management Authorization -01 document

["David B. Nelson" <d.b.nelson@comcast.net>]

> Li Chunxiu writes...

> Here is a situation:
> 1.NETCONF access, defined by a policy:
>       *  Service-Type (6) = Framed-Management (xx)
>       *  Framed-Management-Protocol (xx) = NETCONF(3)
>       *  Management-Policy-Id (xx) = " Read-only group1"

I take it that in this example the Management-Policy-Id is composed of two
separate elements, "Read-only" which provides an over-riding access control
policy of read only, and "group1", which provides some other access control
policy, perhaps based on access to certain branches of the management tree.

This is exactly the type of implementation that we discourage in the -01
text.  The content of Management-Policy-Id should be exactly one name of a
policy of local scope to the NAS.  It should not be composed of sub-strings,
each of which separately names a different policy element.  You could
certainly have a local policy named "read-only-group1" and another named
"read-write-group1".  That might accomplish your objective.

> 3. NETCONF access, defined by a policy, with the Management-Privilege-
> Level
> attribute:
>       *  Service-Type (6) = Framed-Management (xx)
>       *  Framed-Management-Protocol (xx) = NETCONF(3)
>       *  Management-Policy-Id (xx) = "group1 "
>       *  Management-Privilege-Level (xx) = 15
> Comment:15 denotes Read-only
>         16 denotes create  ... ...

This could be workable, in that the Management-Policy-Id is restricted to a
single, flat name of local scope (no sub-fields).  It is possible to define
a scenario in which two access control provisioning attributes are used in
the same Access-Accept, but...  It would be necessary to define the
precedence relationship between them, should there be any conflicts in the
underlying access control rules that would result from application of the
polices in the NAS.  That is also feasible to do.

> I think the 3rd example using the Management-Privilege-Level attribute
> clarifies the use methods of Management-Privilege-Level attribute.
> What is your opinion?

My question is whether it is necessary to support the application of two (or
more) separately defined (and named) access control policies in the NAS at
one time?  In any case where multiple, separate policies are applied, it is
also possible to create a single name for the combined policy.  Of course,
if there are a large number of such sub-policies that can be combined, the
number of unique, flat names to represent them becomes combinatorially
large.  However, I think it is a true statement that organizations using a
form of role-based access control policy will typically only define a
hand-full of really distinct roles.  For that reason, I think that the
"mix-and-match" capability of provisioning multiple local policies via
RADIUS, either in separate attributes or as sub-elements of a single
attribute, creates added complexity disproportionate to the practical value.
But that's just my opinion.

The only use case that I can come up with in which it might be beneficial to
apply disparate, separately named management policies in a single
Access-Accept is the proxy RADIUS case, in which the operator of NAS and the
first hop proxy RADIUS server may wish to overlay restrictions on the access
control provisioned by the operator of the home RADIUS server.  Unless these
policies are well coordinated, and the precedence relationships well
specified, the result may be unpredictable.

I tend to agree with Juergen Schoenwaelder's comments on whether this kind
of approach will ever be required by NETCONF.

However, if the WG members think that addressing the proxy RADIUS server
(e.g. the access outsourcing) use case is important, we could do that, in a
couple of different ways.

Comments on this?




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>