RE: review of NAS-Management-authorization

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

David Harrington writes...

> section 3.
> Should netconf be included in the list of framed-protocols?

Yes, I suppose it should.  

> section 4.
> "contain the name of a management access rights policy"
> "containing policy name"
> can this be more than one policy name?

That's a good question, especially in light of the clarifications we've
included in the RADIUS Issues & Fixes draft regarding interpretation of
multiple instances of the Filter-Id attribute within an Access-Accept.

Here's what we say about that:

   In practice the behavior of a RADIUS client receiving multiple
   Filter-ID attributes is implementation dependent.  For example, some
   implementations treat multiple instances of the Filter-ID attribute
   as alternative filters; the first Filter-ID attribute having a name
   matching a locally defined filter is used, and the remaining ones are
   discarded.  Other implementations may combine matching filters. 

I could support defining the Management-Policy-Id in one of the following
ways:

(1) Similar to Filter-ID, as modified above, i.e. multiple instances provide
undefined behavior at the NAS, and ought to be avoided.

(2) Multiple alternative policies, from which the NAS selects the first
occurrence of this attribute that matches the name of a locally configured
policy.  All other occurrences of this attribute are ignored.

(3) Multiple additive policies, which the NAS will attempt to apply in a
consolidated form.  Any conflicts in the underlying rules contained in the
named policies stored in the NAS will be resolved based on the precedence of
attribute occurrence, wherein rules from polices named by the earlier
instances of this attribute that appear in an Access-Accept take precedence
over rules from policies named by later instances of the attribute.  This
relies on the fact that RADIUS proxies are prohibited form re-ordering
instances of the same attribute type within messages.

Does anyone have a preference?

On a related note, I had a side conversation regarding the content of the
Management-Policy-Id, in which the question was asked whether this was
always a "single, flat name" that maps to a single policy-set in the NAS, or
whether implementers could define separate sub-fields, along the lines of
"filter=some_filter_name, privilege_level=4, access_type=remote".  I think
it would lead to very poor interoperability if implementers were to create
sub-fields of this attribute.  I propose that we add language indicating
that such usages are NOT RECOMMENDED or SHOULD NOT, in the interests of
multi-vendor interoperability.

If there are requirements for other forms of management access control
policy, such as the commonly used integer privilege level indicator, I think
we should add a separate attribute to cover that use case, using a RADIUS
data type of Integer.

> section 5
> Is Transport-Protocol really only valid for the CLI?

No, that's an editing mistake.  In the second sentence it indicates that it
applies to Framed-Management.  I'll remove the restriction to CLI usages.

> section 7.1
> I have not yet walked through the various combinations of SNMP
> components (message formats vs transports).
> I think SNMP-Transport-Model only covers a small set of possibilities.
> More research is needed on this.

Well, earlier versions of this draft included enumerated values for SNMP
(both V1/v2c and V3).  It was pointed out that there were no standardized
ways for RADIUS to provision "generic" SNMP engines, and that the only
standards work in this area is the ISMS work on SNMP Transport Models.

If it is useful to specify "raw" SNMP as a Framed-Management-Protocol as
provisioned by RADIUS, we can certainly put these values back into the
enumeration.  Thoughts?

> section 7.2
> Should this be named Management-Transport-Protocol to differentiate
> it from other service-related parameters?

Given that the RADIUS data dictionary is "flat", yes, I think that change
would be a good idea to reduce possible confusion.

> While we definitely want this with SSH and TLS, is there a case for
> having this with SNMPv1/UDP and other non-secure transports?

The value of "None" was intended to indicate that no _secure_ transport was
required, not that no transport is to be used (that would be silly).  Does
the usage of "None" to indicate non-secure transport(s) work for you?
Should we change that to "Generic-Non-Secure-Transport"?  Or do you really
think we need to specify each non-secure transport by name?

> section 7.3
> SNMP does not support sessions, although the transport over which SNMP
> runs may have sessions.
> Does the term session here refer to an SNMP session? If so, that is a
> problem.

It refers to the session of the underlying secure transport (e.g. SSH), as
used in the ISMS work.  If we want to open up the usage to "raw" SNMP as a
protocol/transport, then this indeed becomes an issue.

> /NAS SHOULD treat the packet/NAS MUST treat the packet/? Under what
> circumstances would it be acceptable to not reject?

Is the consensus that we want to change this to MUST?
 
> "It is recommended" to use UTF-8. Should UTF-8 support be mandatory to
> implement?

This phrasing is pervasive throughout RADIUS.  I'm not sure if we want to
start down that path now.  Thoughts?

> section 9
> "what this specification says" and "what is said" seem quaint ways of
> describing this. Would it be better to specify the sections where
> things are said, or is this language a common approach for
> RADIUS-Diameter coordination?

This language is a common approach, and this text was purloined from other
drafts.
 
> section 10
> /proxy environments/RADIUS proxy environments/ to differentiate this
> from SNMP proxy environments.

Good point.  Will do.
 
> section 13
> "within local area networks" - I'm not sure this can be justified.
> Many protocols originally designed for use only within local area
> networks actually get used over the Internet. Do we actually have any
> mechanism to prevent this from happening, or is it just recommended
> that it be restricted to use in a LAN?

No, this text is taken from elsewhere.  I don't think that the scope of this
document is limited to LANs.  If there is no objection, I'll delete that
text.

> I think the last paragraph should include a statement at the end,
> recommending that management protocols should support data access
> controls to prevent the disclosure of information to help prevent
> unauthorized management access.

This document specifies how to provision management access to NASes and
similar devices, using RADIUS attributes.  We are always careful to avoid
creating requirements for, or specifications of, the underlying service that
we are provisioning in a RADIUS document.  That specification has to occur
elsewhere, in a document that specifies the service.  While what you suggest
is a Good Idea (tm), I think it is out of scope for this document.
 
> Throughout
> There are mentions of VACM. These should be couched as examples, since
> SNMP can theoretically support multiple ACMs.

Yes.  Good Point.  I'll make it clear that VACM is just an example.



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