RE: review of draft-ietf-radext-management-authorization-00.txt

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

Juergen Schoenwaelder writes...

> I have reviewed <draft-ietf-radext-management-authorization-00.txt>.

Thanks!

> a) p1: s/more granular/granular/
> 
>    If you keep the word more, you have to make it clear to what you
>    compare things...

"More" is subjective and I'll remove it.

> b) I am generally not clear what HTTP means as a management protocol
>    and think this should be defined. I assume you mean a human GUI
>    interface running over HTTP but since you just say HTTP, it becomes
>    confusing if you have for instance NETCONF/SOAP/HTTP.

It means a web-based interface, which may be graphical or may be tabular.  I
think this should refer to any presentation in which the NAS is managed via
an embedded web server (in the NAS) and the management station is simply any
web browser.

> c) p3: s/ASCII-text/text-based/
> 
>    I think it does not really matter whether its ASCII or UTF8 or...

OK.

> d) Are HTTP and HTTPS really two different framed management
>    protocols? Or is HTTPS just HTTP with a transport of TLS?

Right.  This needs to be clarified.  Others have registered similar
comments.  I'll propose some revised text to the list that better separates
the selection of application layer protocols from the selection of transport
layer protocols.

> e) p3: Add NETCONF to the examples of framed management protocols
>    and include RFC 4741 in the references.

OK.

> f) p4: s/containing policy name/containing a policy name/

OK.

> g) p6: The list of framed management protocols probably needs some
>    thought. Here is what is in the ID:
> 
>          The Value field is four octets.
> 
>          1      SNMP-Transport-Model
>          2      HTTP
>          3      HTTPS/TLS
>          4      SFTP (via SSH)
>          5      SCP (via SSH)
> 
>    As mentioned above, why are HTTP and HTTPS different management
>    protocols? If you include file transfer protocols, you should
>    perhaps also include FTP and TFTP (as many existing boxes use
>    them).  Perhaps we should call "SNMP-Transport-Model" simply
>    SNMP/TSM. Perhaps we should also add SNMP/USM (even though we
>    currently do not have a defined way to generate RADIUS requests
>    from USM). And as mentioned above, we should include NETCONF (but
>    then I note that NETCONF can run over SSH, BEEP, and SOAP).

Agreed.  See above.

> h) p6: s/Telnet carried within Secure Shell/Secure Shell/
> 
>    I do not think SSH really carries telnet in the sense of the telnet
>    protocol.

Yes.  Better text is required to distinguish the remote terminal service of
SSH from the secure transport service of SSH.

> i) p7 says:
> 
>      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.
> 
>    Why is the expected behaviour when sending multiple
>    Management-Policy-Id attributes? Can the client choose one of them
>    in whatever way and apply it? Or was the client allowed to cache
>    this information and to switch freely between these policies
>    without further request to the Radius server?


Others have raised this issue.  The proposed resolution is to follow the
guidance of the RADIUS Issues and Fixes draft with regard to Filter-ID, i.e.
it is NOT RECOMMENDED to include multiple instances in one Access-Accept
message, because the behavior is undefined.

> j) p8: s|SSH/telnet|SSH|g

OK, taking into account (h) above.

> k) p9: Would it be possible to indicate CLI access via telnet over
>    tls?

Umm.  I don't see why not.  Is this a common use case?  Let me craft some
proposed text.

> l) p12 has text that says:
> 
>      This specification describes the use of RADIUS and Diameter for
>      purposes of authentication, authorization and accounting for
>      management access to devices within local area networks.
> 
>    Why restrict this to "local area networks"? Does it really matter
>    whether this is used on a LAN, MAN, or WAN? If yes, explain why.

Should not be restricted to LANs.  Will fix.



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