Review of Management Authorization -00 document

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Section 3

  Framed Management means management of an entity by means of a non-
  interactive, non-CLI-style method.  The management information is
  typically formatted in a binary or textual protocol, such as HTTP or
  SNMP.  While remote management by interactive CLI sessions are
  carried over protocols, such as Telnet, Rlogin, and SSH, these
  protocols are primarily for the delivery of terminal, or pseudo-TTY
  services.  Command Line Interface, Menu Interface, or other ASCII
  (UTF-8) terminal emulation interfaces are not considered to be Framed
  Management protocols, as used in this document.  Examples of Framed
  Management protocols include HTTP, HTTPS, and SNMP.

  To support the authorization and provisioning of Framed Management
  access to managed entities, this document introduces a new value for
  the Service-Type attribute [RFC2865], and one new attribute.  The new
  value for the Service-Type attribute is Framed-Management.  The
  definition of this service is the provisioning of remote device
  management via a Framed Management protocol, as described in this
  section.  The new attribute is Framed-Management-Protocol, the value
  of which specifies a particular protocol for use in the remote
  management session.


This seems to imply that SSH would not be an acceptable value for
Framed-Management-Protocol.  Is that right?

Section 7.2

I am not clear that all combinations of Framed-Management-Protocol
and Transport-Protocol make sense.

For example, are the following combinations possible?

Example 1:

Framed-Management-Protocol = HTTPS/TLS (3)
Transport-Protocol != TLS (3)

Example 2:

Framed-Management-Protocol = HTTP (2)
Transport-Protocol = TLS (3)

How is this different from Framed-Management-Protocol = HTTPS/TLS?

Example 3:

Framed-Management-Protocol = SFTP (4) or SCP (5)
Transport-Protocol != SSH (2)

If Framed-Management-Protocol and Transport-Protocol are really orthogonal, 
then
I'd suggest that Framed-Management-Protocol not include any implied 
transports
and that the Transport-Protocol list be expanded.  For example:

Framed-Management-Protocol

1      SNMP
2      HTTP
3      FTP
4      CP

Transport-Protocol

1  UDP
2  TCP
3  SSH over TCP
4  TLS over TCP
5  TLS over UDP

Section 7.3

  The Management-Policy-Id attribute indicates the name of the
  management access policy for this user.  Zero or more Management-
  Policy-Id attributes MAY be sent in an Access-Accept packet.
  Identifying a policy by name allows the policy to be used on
  different NASes without regard to implementation details.

What does it mean if multiple Management-Policy-Id attributes are included?
How are the policies merged?  If this is implementation-specific, isn't
the result undefined?

Section 8


      *  Service-Type (6) = Administrative (6)
      *  Transport-Protocol (xx) = None (1)

Is the Transport-Protocol really none??

Section 9

  What this specification says about the applicability of the
  attributes for RADIUS Access-Request packets applies in Diameter to
  AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072].  What is said
  about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or
  Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to
  DIAMETER_MULTI_ROUND_AUTH.

  What is said about Access-Accept applies in Diameter to AA-Answer or
  Diameter-EAP-Answer messages that indicate success.  Similarly, what
  is said about RADIUS Access-Reject packets applies in Diameter to AA-
  Answer or Diameter-EAP-Answer messages that indicate failure.

  What is said about COA-Request applies in Diameter to Re-Auth-Request
  [RFC4005].

I'm not clear that these statements make sense because there typically is
no authentication in these AAA exchanges, right?

Section 12

  This document contains placeholders ("TBA") for assigned numbers
  within the RADIUS Attributes registry, to be assigned by IANA at the
  time this document should be published as an RFC.  Assignement of
  additional values for attributes defined in this document are to be
  processed as described in [RFC3575].

RFC 3575 specifies "First come, first served", which requires no review.  Is
this really what you want?



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