RE: review of NAS-Management-authorization

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Dave Harrington writes...

> My approach is to think of privilege level as being a "policy"
> that could be named for a particular management protocol type
> (e.g. CLI).

There is a widely deployed use case of numeric (integer) privilege levels
for CLI use.  The desire is to support that scheme, without conflating it
with the more general named policy approach.

> From the ISMS perspective, we want the policy-ID to be access
> control model independent - a single policyID identifies a policy
> to be applied, and then it is up to the specific access control 
> model that decides what the policy name actually means...

Sure.

> ... (and we will produce standards, like RFC3415's VACM, for 
> specification and interpretation of named policies).

The name of a policy means nothing.  It's just a label.  It's a name for
something that is locally defined and configured within the NAS.  The types
of rules in the policy set, and their interpretation by the NAS, will be
dependent upon the capabilities of the NAS.  If we desire to standardize the
way the rules in a policy are to be specified and provisioned, we could
write a MIB, or we could look to a document such as
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt
for a description of a formal syntax for rule specification.

> Maybe the structured parameter approach should be allowed, and 
> then some standards should be defined to make those structured 
> parameters interoperable across vendors.

I think that is needlessly complex, but that is my opinion.

> Or we can require a single word as the policy, and then people can
> make up names like "operator-priv12", which they would do anyway if
> we don't support structured parameters.

There is nothing to prevent folks from using mnemonic names for polices that
describe their effect.  I think we should disallow the parsing of
sub-strings (structured parameters) in a single policy name in an attempt to
apply a compound policy synthesized from multiple individual policy
definitions.  If we want to do that, it is much better, IMO, to have
multiple instances of the attribute.



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