RE: review of NAS-Management-authorization

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

David Harrington writes...

> I think limiting it to one policy name would be the simplest, 
> and most deterministic, approach.

<snip>

> I would rather see a single policy-name so there is no ambiguity
> in the RADIUS authorization.

If there is no objection, I will include language to that effect, making
this consistent with the Filter-Id usage.

> > I propose that we add language indicating that such usages
( sub-fields)
> > are NOT RECOMMENDED or SHOULD NOT, in the interests of multi-
> > vendor interoperability.
> 
> I agree.>

If there is no objection, I will add language to that effect, as well.

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

Since this is a common use case, I propose to add and additional attribute
to explicitly provision integer privilege level.  That text would look like:

7.x.  Management-Privilege-Level

   The Management-Privilege-Level attribute indicates the integer
   Privilege level to be assigned for management access for the
   Authenticated user.   Many NASes provide the notion of 
   differentiated management privilege levels denoted by an integer
   value.  The specific access rights conferred by each value are
   implementation dependent.  It MAY be used in both Access-Request
   and Access-Accept packets.

   A summary of the Management-Privilege-Level attribute format is 
   Show below.  The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |             Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Value (cont)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         (TBA) for Management-Privilege-Level.

      Length

         6


      Value

         The Value field is an Integer, denoting a management
	   privilege level.

Further thoughts on this proposal?

> I thought about this a bit more. If the assumption is that the
> Management Policy ID is only provided when RADIUS is doing the
> authentication, and this only occurs if the mgmt protocol is using
> a RADIUS-secured transport, then this should be explained. This 
> should be true of any mgmt protocol, not just SNMP, so you probably
> should not specify SNMP-Transport-Model, but simply SNMP. The 
> Transport-Model attribute identifies the transport, and SNMP can 
> use that to determine the transport model.

You mean the Management-Transport-Protocol (nee Transport-Protocol)
attribute?

That seems reasonable to me.

> The (database) access control subsystem in the RFC3411 SNMP
> architecture requires a securityModel, and the VACM model uses
> the securityModel in making its authorization decision. So requiring
> a particular securityModel would make architectural (and security)
> sense.

OK.
 
> So, if the intent is to specify the required security mechanism to
> qualify for this authorization (which makes more sense than 
> required transport), then this should be the SNMP SecurityModel 
> rather than the transport-model. In SNMP, we have an SNMPv1 security
> model plus and SNMPv2c security model, and potentially multiple
> security models that can be used with an SNMPv3 message (currently
> USM and the ISMS TSM).  These are designed to be independent of the
> transport used. So using the security model could allow in an 
> authorization-only mode for "raw" SNMP.

Um...  That makes sense for SNMP, but may not be applicable to other
management protocols.  We could add an attribute specifically for SNMP to
carry the SNMP securityModel, but it might be more general to specify the
security "wrapper" in a management protocol independent fashion.  I agree
that this is not exactly the same thing as specifying the [secure]
transport, since some of the SNMP securityModels do not use a distinct
transport (e.g. SNMP V1 and V2c both use UDP).

I'll need to give this a little more thought.

> There is a desire to have an authorization-only mode for SNMP 
> (and possibly other mgmt protocols). So I think being able to ask
> RADIUS for the mgmt policy ID even when the transport is non-secure
> makes sense. I think it makes sense to allow for UDP, TCP, SCTP, etc.
> The mgmt-protocol security "model" (regardless of protocol) might 
> utilize assumptions about the transport used in making a security 
> decision, so I think we should not just lump them together as 
> "generic non-secure", but allow the specification of which is 
> actually used.

OK.  If there is no objection, I will add commonly used transports you
mention to the enumeration.

> I would avoid requiring a session, since some SNMP is sessionless.
> Other mgmt protocols built atop UDP, such as syslog, also might be
> sessionless, and I would prefer not to limit the policy-ID to
> session-based mgmt.

OK.

> The phrasing that recommends "using" UDP-8 is not inconsistent
> with mandatory-to-implement UDP-8.  There is a real 
> interoperability problem if a sender uses UDP-8 and the receiver
> does not support it. If you want to recommend using UDP-8, then 
> receivers should be required to accept UDP-8 when it is used.

What you say makes sense.  Is there any objection to making UTF-8 mandatory
to implement, in this document, even though the base RADIUS documents do not
go that far?



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