Subject: a question about Management Authorization -01 document

From: li chunxiu <[email-masked]>
Date: Tue, 18 Dec 2007 11:08:06 +0800

Hello, David
In the RADIUS NAS Management Authorization Draft，the added attribute
Management-Privilege-Level is an integer-valued attribute for use with CLI
access methods, I have a question about it, does it apply to the
Framed-Management-Protocol?
 For example, in access control of SNMP protocol or Netconf protocol, is it
necessary to use the Management-Privilege-Level attribute?

Thanks,
Chunxiu li

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 18 Dec 2007 09:09:13 -0500

Li Chunxiu writes...

> Management-Privilege-Level is an integer-valued attribute for use with
> CLI access methods, I have a question about it, does it apply to the

The Management-Privilege-Level attribute was added to address a review
comment and a long standing use case.

In the -01 draft, we made it clear that the Management-Policy-Id attribute
was to be a flat, simple name of local scope, and that the field was not to
be overloaded with other kinds of elements, all in the name of good
interoperability.  To address a need that might have tempted vendors to
overload the Management-Policy-Id attribute and to provide a way to
provision a long standing CLI management parameter, we added the new
attribute.

The use case is that of integer valued-privilege level for CLI usages, as
exemplified by the "enable' levels in Cisco's IOS.  This use is common in
other vendor's products, as well.

I don't see any reason that the Management-Privilege-Level attribute could
not be made applicable to Framed-Management sessions, but I don't see any
compelling reason for doing so.  Having it available as a matter of protocol
symmetry might be nice, but is there actually a use case that it would
support?  

> For example, in access control of SNMP protocol or Netconf protocol, is
> it necessary to use the Management-Privilege-Level attribute?

It seems to me that the named policy of Management-Policy-Id would be
sufficient for uses such as SNMP or Netconf.  Can you suggest a situation
where it would be desirable to have an integer-valued parameter for
provisioning access control via either of these methods?

Regards,

Dave

---

From: li chunxiu <[email-masked]>
Date: Wed, 19 Dec 2007 10:46:36 +0800

> provisioning access control via either of these methods?
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"
2. NETCONF access, defined by a policy:
      *  Service-Type (6) = Framed-Management (xx)
      *  Framed-Management-Protocol (xx) = NETCONF(3)
      *  Management-Policy-Id (xx) = "group1 Read-only"
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  ... ...
I think the 3rd example using the Management-Privilege-Level attribute
clarifies the use methods of Management-Privilege-Level attribute. 
What is your opinion?

 Regards, 
Li chunxiu

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Dec 2007 08:41:53 +0100

> clarifies the use methods of Management-Privilege-Level attribute. 

Since NETCONF right now does not have a defined access control system,
the discussion is kind of pointless since implementations can do
whatever they like. That said, let me say that I personally find a
combination of Management-Policy-Id and Management-Privilege-Level
somewhat strange.

/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: "David B. Nelson" <[email-masked]>
Date: Wed, 19 Dec 2007 08:57:01 -0500

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

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

> clarifies the use methods of Management-Privilege-Level attribute.

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?

---

From: li chunxiu <[email-masked]>
Date: Thu, 20 Dec 2007 11:08:03 +0800

> Dave writes...
I agree with the point of view of a local policy named "read-only-group1"
and another named "read-write-group1". 
If the Access Control is mainly done in NAS, the Access Control policy in
Radius may be very simple, and the pattern of "read-only-group1" is ok.
If the Radius needs to participate in the Access Control, there may be some
complicate policies. If the policies are too complicated to be expressed in
one Management-Policy-Id, which expression is better? Will the policies be
separated to several parts in each Management-Policy-Id within each
Access-Accept? And these parts will be composed to be whole policies in the
NAS to accomplish the Access Control, right? 
> polices in the NAS.  That is also feasible to do.
This needs to be researched.
> specified, the result may be unpredictable.
I agree.
Comments on this?

Li chunxiu

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Dec 2007 08:31:21 +0100

> NAS to accomplish the Access Control, right? 

Section 4 defines the purpose and scope of the access control policy
attributes. In particular, note that the Management-Policy-Id and
Management-Privilege-Level attributes are not meant to carry accress
control rules; they merely identify which locally known access control
rules to apply.

/js

---

From: li chunxiu <[email-masked]>
Date: Thu, 20 Dec 2007 16:21:26 +0800

> control rules; they merely identify which locally known access control

Thank you for clarify this two concepts. 
But in the SNMP/Netconf Access Control process, there are 3 entities, agent,
NAS and Radius server. Could you please explain how to define the "local
scope" concept? 
Thanks,
Li chunxiu

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Dec 2007 09:28:25 +0100

> NAS and Radius server. Could you please explain how to define the "local

For me, the agent and the NAS are effectively the same thing. From the
SNMP perspective, a manager talks to an agent. From a RADIUS
perspective, the agent acts as a NAS to the RADIUS server. See also
draft-ietf-isms-radius-usage-01.txt.

/js

---

From: li chunxiu <[email-masked]>
Date: Thu, 20 Dec 2007 18:01:04 +0800

> j/s wrote:

Maybe there is need to define the "local scope" concept in the
draft-ietf-radext-management-authorization-01.

Regards
Li chunxiu

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 20 Dec 2007 08:16:56 -0500

Li Chunxiu writes...

> draft-ietf-radext-management-authorization-01.

We could certainly do that.  I'll add that to the issues list.  It works
exactly like the Filter-Id attribute, which also relies on rules of local
scope.  Therefore, it's a well understood RADIUS operational paradigm.  The
rules are provisioned on all that NASes that are likely to need to know and
apply them by some out of band means, such as via a MIB using SNMP, via the
CLI or via FTP.

Note that there is work in RADEXT to define attributes that supplement
Filter-Id by provisioning and defining the rules at the same time.  That is
to say, defining a RADIUS filter rule attribute that actually contains the
rules.  This work leverages work done previously for Diameter. See RFC 4849.

So far, there has been no effort to define similar self-contained management
policy rules.