RE: RADEXT WG Last Call on NAS Management Authorization Specification

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

David Harrington writes...

> I have reviewed draft-ietf-radext-management-authorization-02.txt
> for the WGLC and have comments.

Thanks you!

> "Note that" is usually unnecessary.

OK.  That's a bit of flowery writing that isn't needed.

> 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."

OK.

> section 6:
> OLD: "To aid in understanding of this document, it"
> NEW: "It"

Sure.  The point I was trying to convey here is that this document is not
creating the usage being described here, but simply reporting 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?

I'm not sure what you are trying to ask.  We acknowledge an existing
practice and indicate that it is compatible with the usages defined in this
document.

> section 8.2
> s/The acronyms used/The names used/

OK.
 
> 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 protocol MUST protect against unauthorized
> disclosure of information.  The secure transport MUST provide
> encryption.

OK.  I think that confidentiality implies the use of encryption, unless the
medium of communication is physically secured, but I have no objection to
your suggested text.

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

Both, which one depending upon context.

> Will IANA know just which TBA should be replaced with which assigned
> type or value?

IANA gets to make up the numeric values, and hopefully can tell which is an
Attribute ID code and which is a value, but we could use a notation such as
TBA-A (for attribute IDs) and TBA-V (for values), if you think that would be
helpful.

> section 14:
> this mentions accounting, but accounting is explicitly out of 
> scope for this document.

Not entirely.  Section 12 indicates that some attributes may be included in
Accounting-Request packets.
 
> Author's Address:
> Greg has no address.

Well, he does have one -- he just hasn't provided it the current draft.
This omission will be corrected eventually -- certainly during AUTH84, if
not before.

> Requested changes:
> Section 3:
> OLD: "NETCONF (XML over HTTP/BEEP/SOAP)"
> NEW: "NETCONF (XML over SSH/BEEP/SOAP)"

Well, OK, I guess.  Does NETCONF not have a profile for transport over HTTP?
I'm a bit confused on that point.

> Section 4:
> VACM is composed of multiple tables
> OLD: (VACM) table [RFC3415],
> NEW: (VACM) [RFC3415],

OK.

> section 8.1 (and elsewhere)
> Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or
> HTML/HTTP?

Uh, yes...

> Isn't HTTPS Framed-Management-Protocol=HTTP plus Transport-Protocol=TLS?

Yes, but in the -02 revision the Management-Transport-Protocol Attribute has
been removed, because it seemed like unnecessary over-specification, and
replaced with the Management-Transport-Protection Attribute.  For that
reason, your suggestion doesn't quite work.

> Should we develop acronyms 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?

Well, the tradition of RADIUS documents is that we describe how to provision
existing services using RADIUS Attributes.  We stay away from actually
defining the services being provisioned, and simply provide references as
appropriate.  In that light, I think it might be inappropriate to define new
acronyms for such services in this document.

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

In the interest of backward compatibility, it seems like de default should
be no security.

> section 8.3
> The first paragraph says zero or more, while the fourth paragraph
> says you should not send two or more.
> OLD" "Zero or more"
> NEW: "Zero or one"

OK.

> Paragraph 3 says what to do if one is received; and paragraph talks
> about receiving more than one. What if zero are received?

If zero are received no management policy is applied to the provisioned
service.  That's universally true of RADIUS service provisioning Attributes.
The absence of an Attribute generally has no significance; it does not cause
any action at the NAS.

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

What management protocol?  Are you alluding to something like the SNMP VACM?

> If the mgmt protocol defines an error condition for incorrectly 
> formatted rules, that error won't be sent because the session is 
> rejected, right?

Well, this is a bit murky.  Traditionally, RADIUS Servers provision a
service to be delivered to the user at the NAS, and the NAS is responsible
for delivering that service, and not some other.  If the NAS cannot deliver
the service (and it knows what it is) then traditionally the NAS has been
required to reject access altogether.   The access protocol may or may not
have an error channel for the NAS to signal to the user that the service has
been denied.

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

Probably not.  The NAS might know, because the term "NAS" describes the
entirety of the network device or host device that contains the RADIUS
Client.  The RADIUS Client would almost certainly not know.

In view of this, it may be better or omit the phrase "or the policy rules
are 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.

Well, it's just that sort of "mapping" that this attribute was introduced to
avoid.  There are a significant number of currently deployed implementations
that provision CLI access control using an integer-valued parameter.  It is
what it is.  This is simply an attempt to recognize that practice and
provide a way to provision that type of access control via RADIUS.  We are
not attempting (not should we) to redefine how CLI access control works in
NASes, just how RADIUS can be use to provision it.

> This is a great opportunity to suggest standard names for privilege 
> levels, and then vendors can map those standard names to the internal 
> routines.

Hmmm...  I think that type of standardization crosses the line into
"defining the service" and would be out of scope for this document.  I'd
like to solicit some additional WG comment on this suggestion, before we go
down that path.

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

Well, NAS-Prompt is the non-privileged CLI service and Administrative is the
privileged CLI service.  While implementations may vary, my understanding is
that NAS-Prompt has no privileges and Administrative has all privileges
(like root).  Since there are only two choices, this is pretty much a binary
thing -- on or off.

> Wouldn't this simply be implementation-dependent?

It might be...
 
> 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?

The ability to specify particular transport protocols has been removed from
the -02 version, and thus there is no way to specify a particular version of
a particular transport protocol.  I think this comes down to what is
necessary and sufficient to solve the "80% problem", i.e. what will work
sufficiently well in 80% of the possible deployment scenarios and use cases.
I think we can easily fall into the trap of over-specifying the solution,
and adding way more complexity than anyone will ever actually use
(correctly).

> I would change Example #4 to use a Management-Policy-ID="Level 15"
> rather than a Management-Privilege-Level=15

This is dependent on resolution of a previous comment.

> 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 think that the "v3" is as editing artifact, left over from the -01 version
of the draft.

> 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."

OK, that's fine.  We can use text along those lines.

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

Well, there's something else wrong with Example 6.  It still uses the
removed [Management-]Transport-Protocol attribute.  (There are several
examples with this problem.)  I think that this should be revised to
indicate SNMP access using a particular protection level (i.e.
Management-Transport-Protection).

I'll submit some suggested text in a separate message dealing with errata in
the examples.  Perhaps we can continue the discussion on that basis?
 
> Example#8 doesn't mention which transport protocol should be used to
> provide security services.

Once again, the Management-Transport-Protocol attribute has been removed
from the -02 version of the draft.

> Should it, or is it intentional to allow any transport protocol to be 
> used that can provide Confidentiality-Protection?

It is intended that any transport protocol that can meet or exceed the
specified minimum security protection requirement (integrity or integrity
and confidentiality) can be used for the session.

Thanks, once again, for your thorough and insightful review comments.

Regards,

Dave Nelson


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