[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D Action:draft-ietf-radext-management-authorization-02.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> This draft is a work item of the RADIUS EXTensions Working Group of the
> IETF.
>
> Title : Remote Authentication Dial-In User Service
> (RADIUS) Authorization for Network Access Server (NAS) Management
> Author(s) : D. Nelson, G. Weber
> Filename : draft-ietf-radext-management-authorization-02.txt
> Pages : 20
> Date : 2008-02-24
>
> This document describes Remote Authentication Dial-In User Service
> (RADIUS) attributes for the authorization and service provisioning of
> local and remote management of embedded systems and other managed
> entities, generally referred to as Network Access Servers (NASes).
> Specific provisions are made for remote management via framed
> management protocols, for granular levels of access rights and
> management privileges, and for specification of a protected transport
> protocol.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-management-
> authorization-02.txt
I'm forwarding a list of the open issues that I culled from the RADEXT
mailing list, in preparing the -02 version of this draft. All of the open
issues listed below have been addressed in one fashion or another.
I would like to call attention to one change in particular.
One particularly thorny issue with the -01 draft is the relationship (or
lack thereof) between the application layer management protocols, as
provisioned in the Framed-Management-Protocol attribute, and the protected
transport protocols, as provisioned in the Management-Transport-Protocol
attribute. Part of the confusion is whether the latter attribute should
include "traditional" Layer 4 network transports (e.g. TCP, UDP, SCTP, etc.)
or only "protected transports" (TLS, DTLS, SSH, etc.) The other part of the
confusion is which transports can be use with which management applications.
I think the -01 version suffers from "creeping complexity", caused partly by
various review comments along the way, and partly by muddled thinking on my
part. Having been away from this document for some months, it occurred to
me that the problem was that the Management-Transport-Protocol attribute was
simply over-specifying the problem. I don't think that anyone really needs
to micro-manage the choice of protected transport protocol, any more than we
need to micromanage the selection of remote terminal protocol in providing
the NAS-Prompt service.
The resolution to this particular set of comments was to change the
attribute to Management-Transport-Protection, and only provision that which
is important -- the level of protection required for the remote management
session. The four possible values of this attribute are:
o No-Protection: No transport protection is required. Accept
connections via any supported transport.
o Integrity-Protection: The management session requires protection
in a secure or protected transport, that is supported by the
management access protocol and implementation. The secure
transport MUST provide Integrity Protection.
o Confidentiality-Protection: The management session requires
protection in a secure or protected transport, that is supported
by the management access protocol and implementation. The secure
transport MUST provide Confidentiality Protection.
o Integrity-Confidentiality-Protection: The management session
requires protection in a secure or protected transport, that is
supported by the management access protocol and implementation.
The secure transport MUST provide both Integrity Protection and
Confidentiality Protection.
The complete list of issues addressed in the -02 revision is as follows:
-- Further explain the distinction between web-based management (HTML over
HTTP) vs. other methods, such as NETCONF (XML over HTTP).
Done.
-- Provide informational text listing the "default" transport for each of
the management protocols specified by Framed-Management-Protocol (e.g. for
SNMP it's unprotected UDP).
The "default" transport is no longer at issue. The
Management-Transport-Protocols attribute has been re-cast as the
Management-Transport-Protection attribute.
-- Further explain what protocols (e.g. telnet, rlogin) are involved in
providing the NAS-Prompt Service-Type with each value of
Management-Transport-Protocol.
No longer applicable.
-- Explain the current remote console usage model of NAS-Port-Type of
Virtual with Service-Type of NAS-Prompt.
Done.
-- Should Management-Privilege-Level apply to Framed-Management-Protocol?
E.g. for access control of SNMP or NETCONF?
No. Done.
-- Would the locally stored policies referenced by Management-Policy-Id ever
be too complicated to be stored on the NAS, requiring multiple policy and
access control attributes from the RADIUS server to express that complexity?
No. Done.
-- Clarify the "local scope" of policy definitions on the NAS referenced by
Management-Policy-Id?
Done.
-- The proposed RADIUS attributes do not carry what really counts - the
security level, e.g. I might accept SNMP access as long as the actual
security level is providing authPriv, regardless how this is achieved.
Done? I think the Management-Transport-Protection attribute addresses this
issue.
-- The two new attributes Framed-Management-Protocol and Transport-Protocol
are enumerations that may need to be extended (e.g. NETCONF is missing in
the first one already). I suggest that the IANA section spells out the rules
for extending these enumerations, e.g. by requiring a specification.
Done.
-- Are HTTP and HTTPS really two different framed management protocols? Or
is HTTPS just HTTP with a transport of TLS?
Done.
-- I do not think SSH really carries telnet in the sense of the telnet
protocol.
Done.
-- Would it be possible to indicate CLI access via telnet over tls?
No longer applicable.
-- I think that the way you would specify the secure remote terminal service
of SSH would be using Service-Type=NAS-Prompt,
Management-Transport-Protocol=SSH.
No longer applicable.
-- With respect to TLS/DTLS, what mode is intended? Mutual auth with certs?
Server-only auth? TLS-PSK?
No longer applicable.
-- I thought you need to specify what "default" means for each
Framed-Management entry.
No longer applicable.
-- The NAS-Prompt Service-Type works for all of: local console
connections, telnet, rlogin, ssh, (and more) remote connections.
Done.
-- The only thing we are trying to specify here is whether the remote
terminal service is being carried over a secure transport. Do we really
care what the transport layer protocol is? I think that what we care about
is whether it over a secure or non-secure transport.
Done.
As always, further comments are welcome. Hopefully you will find that this
draft version has addressed your open issues in a satisfactory manner.
--
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/>