FW: [Isms] FW: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification

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

Forwarding for Dave Harrington.  The wrong address was used for the RADEXT
WG mailing list.

> -----Original Message-----
> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of
> David Harrington
> Sent: Saturday, March 29, 2008 11:53 AM
> To: 'David B. Nelson'; radiusext@ietf.org
> Cc: isms@ietf.org
> Subject: Re: [Isms] FW: RADEXT WG Last Call on NAS
> ManagementAuthorizationSpecification
> 
> Hi,
> 
> I have reviewed draft-ietf-radext-management-authorization-02.txt for
> the WGLC and have comments.
> 
> ---------------------May fix editorial-------------------
> Description of issue
> Submitter name: David Harrington
> Submitter email address: ietfdbh@comcast.net
> Date first submitted: 3-29-08
> Reference: URL to e-mail describing problem, if available
> Document: draft-ietf-radext-management-authorization
> Comment type: E
> Priority: '1' Should fix
> Section: various
> 
> Requested changes:
> throughout:
> "Note that" is usually unnecessary. Don't we want readers to note
> everything in the document, or we wouldn't have said it?
> section 3:
> OLD: "While remote management by interactive CLI
>    sessions is carried over protocols, such as Telnet, Rlogin, and
> SSH,
>    these protocols are primarily for the delivery of terminal, or
>    pseudo-TTY services.  Note that, in this context, "SSH" means the
>    remote terminal service of SSH, not the more general protected
>    transport service of SSH."
> NEW: While remote management by interactive CLI
>    sessions is carried over protocols, such as Telnet, Rlogin, and the
> 
>    remote terminal service of SSH, these protocols are used in this
> context
>    for the delivery of terminal, or pseudo-TTY services."
> 
> section 6:
> OLD: "To aid in understanding of this document, it"
> NEW: "It"
> 
> section 6:
>    It is expected that the additional features of this document with
>    respect to remote access to the CLI of a NAS will be used in
>    conjunction with the existing practice regarding the NAS-Port-Type
>    attribute described in this section.
> Should this also be expected of other management interfaces if this is
> existing practice for the vendor?
> 
> section 8.2
> s/The acronyms used/The names used/
> 
> I suggest the descriptions of the values should identify the threats
> and the mitigation provided, in a clear and unambiguous manner. For
> example,
> OLD: 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.
> NEW: The transport ptotocol MUST protect against unauthorized
> disclosure of information.  The secure transport MUST provide
> encryption.
> 
> 
> section 13:
> I have made it a practice to identify the specific registries to be
> modified, and the specific changes that need to be made to each
> registry. This is easier for IANA, and removes the chance of IANA
> misinterpreting what is needed. You say "RADIUS Attributes registry" -
> is that the RADIUS Attribute Types registry, or the RADIUS Attribute
> Values registry, or both?
> 
> Will IANA know just which TBA should be replaced with which assigned
> type or value?
> 
> section 14:
> this entions accounting, but accounting is explicitly out of scope for
> this document.
> 
> Author's Address:
> Greg has no address.
> 
> 
> ---------------------Should fix editorial-------------------
> Description of issue
> Submitter name: David Harrington
> Submitter email address: ietfdbh@comcast.net
> Date first submitted: 3-29-08
> Reference: URL to e-mail describing problem, if available
> Document: draft-ietf-radext-management-authorization
> Comment type: E
> Priority: '1' Should fix
> Section: various
> 
> Requested changes:
> Section 3:
> OLD: "NETCONF (XML over HTTP/BEEP/SOAP)"
> NEW: "NETCONF (XML over SSH/BEEP/SOAP)"
> 
> Section 4:
> VACM is composed of multiple tables
> OLD: (VACM) table [RFC3415],
> NEW: (VACM) [RFC3415],
> 
> 
> 
> ---------------------Technical Issues-------------------
> Description of issue
> Submitter name: David Harrington
> Submitter email address: ietfdbh@comcast.net
> Date first submitted: 3-29-08
> Reference:
> Document: draft-ietf-radext-management-authorization
> Comment type: T
> Priority: '1' Should fix
> Section: various
> 
> section 8.1 (and elsewhere)
> Shouldn't Framed-Managament-Protocol "Web-based" (2) be HTTP or
> HTML/HTTP? Isn't HTTPS Framed-Management-Protocol=HTTP plus
> Transport-Protocol=TLS?
> Should we develop acronymns NETCONFS and SNMPS and CLIS so we can just
> lump the non-secure and secure versions into Configuration-based, and
> Polling-based names and so on?
> 
> Should SFTP and SCP be listed separately or lumped together?
> 
> section 8.2
>    The same "No Protection"
>    semantics are conveyed by omitting this attribute from an Access-
>    Accept packet."
> Why is this the default behavior? Wouldn't it be better to default to
> full security if the attribute is not present?
> 
> section 8.3
> The first paragrapgh says zero or more, while the fourth paragraph
> says you should not send two or more.
> OLD" "Zero or more"
> NEW: "Zero or one"
> 
> Paragraph 3 says what to do if one is receiverd; and paragraph talks
> about receiving more than one. What if zero are received?
> 
> Paragraph 3 says if "the policy rules are incorrectly
>    formatted, the NAS MUST treat the packet as if it had been an
> Access-
>    Reject."
> Doesn't this potentially override what the management protocol says
> should be done if the rules are incorrectly formatted? If the mgmt
> protocol defines an error condition for incorrectly formatted rules,
> that error won't be sent because the session is rejected, right? What
> happens if it is considered incorrect formatting to have an empty
> table of rules, but the operator is trying to gain mgmt access to set
> the policy rules into the table? Would RADIUS even know whether the
> rules were incorrectly formatted?
> 
> section 8.4
> I don't understand why we need a special Management-Privilege-Level
> attribute. This should be able to specified as a named policy in the
> Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and
> "2" and "3". Implementations simply need to map between the policy
> name and their  privilege-level policy implementation.
> 
> Different implementations might handle priivilege levels differently -
> some might use integers internally, others might use a different range
> of values (0-15 vs 1-16). Using Management-Policy-ID makes this simply
> a mapping exercise. This is a great opportunity to suggest standard
> names for privilege levels, and then vendors can map those standard
> names to the internal routines. If vendors provide an API, operators
> could name the policies as they wanted and map them to the vendors'
> APIs for invoking different privilege levels.
> 
> I do not understand "Using the Management-
>    Privilege-Level attribute with a Service-Type attribute with a
> value
>    of NAS-Prompt will have the effect of increasing the minimum
>    privilege level.  Conversely, it is NOT RECOMMENDED to use this
>    attribute with a Service-Type of Administrative, which may require
>    decreasing the maximum privilege level."
> How does it increase the minimum privilege level or decrease the
> maximum security level? Wouldn't this simply be
> implementation-dependent?
> 
> section 9:
> I have a concern about protocol versions. What if I want SSHv2 because
> I don't think SSHv1 is adequate? Should I be able to make the
> distinction? or is that simply an operator-provisioning task to
> disallow SSHv1 to the device?
> 
> I would change Example #4 to use a Management-Policy-ID="Level 15"
> rather than a Management-Privilege-Level=15
> 
> Example #5 mentions SNMPv3, but the attribute says only SNMP. If the
> operator should be permitted to decide which SNMP version can be used,
> then we need these specified as different management protocols. I
> think it would be better to leave the message-version decision to the
> SNMP standard. So I would change the example from "SNMPv3 access" to
> simply "SNMP access".
> 
> I would change the paragraph in example #5:
> OLD:   Note that there is currently no standardized way of
> implementing
>        this management policy mapping within SNMPv3.  Such mechanisms
>        are implementation specific.
> NEW: "A standardized way of mapping from Management-Policy-ID to a
> particular access control policy in SNMP is under research."
> 
> Example #6 talks about using the Secure Shell Transport Model, but
> most existing SNMP implementations do not support this yet. The
> "transport model" approach supports a binding between the SSH
> authenticated identity and the SNMP database access controls. Some
> SNMP implementations support running SNMP (any version) over an SSH
> tunnel, but they provide no such binding. I think it is an SNMP
> internal matter for SNMP access controls to say "they must use
> transport model to get database access". So I would remove the mention
> of the Secure Shell Transport Model from the example:
> OLD:    6.  SNMP secure Transport Model access, using the Secure Shell
>        Transport Model:
> NEW:    6.  SNMP access, via a fully-protected secure tunnel of SSH,
> to an
>         undefined management access level:
> 
> Example#8 doesn't mention which transport protocol should be used to
> provide security services. Should it, or is it intentional to allow
> any transport protocol be used that can provide
> Confidentiality-Protection?
> 
> David Harrington
> dbharrington@comcast.net
> ietfdbh@comcast.net
> dharrington@huawei.com
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@ietf.org
> https://www.ietf.org/mailman/listinfo/isms


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