Re: [Isms] FW: RADEXT WG Last Call on NAS Management AuthorizationSpecification

["David Harrington" <[e-mail]>]

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: [e-mail]
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: [e-mail]
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: [e-mail]
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
[e-mail]
[e-mail]
[e-mail]


_______________________________________________
Isms mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/isms