Re: [Isms] RADEXT WG Last Call on NAS ManagementAuthorizationSpecification
"David B. Nelson" <dnelson@elbrysnetworks.com> Mon, 31 March 2008 17:57 UTC
Return-Path: <isms-bounces@ietf.org>
X-Original-To: isms-archive@megatron.ietf.org
Delivered-To: ietfarch-isms-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0C33A6988; Mon, 31 Mar 2008 10:57:35 -0700 (PDT)
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E1828C13B for <isms@core3.amsl.com>; Mon, 31 Mar 2008 10:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJwzC0CVItjZ for <isms@core3.amsl.com>; Mon, 31 Mar 2008 10:57:32 -0700 (PDT)
Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id AFEF83A6856 for <isms@ietf.org>; Mon, 31 Mar 2008 10:57:30 -0700 (PDT)
Received: (qmail 22229 invoked from network); 31 Mar 2008 13:57:26 -0400
Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 31 Mar 2008 13:57:26 -0400
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: 'David Harrington' <ietfdbh@comcast.net>, radiusext@ietf.org
References: <1b1701c8793d$0de1ffe0$011716ac@NEWTON603> <09a301c891b4$ec440280$6c02a8c0@china.huawei.com>
Date: Mon, 31 Mar 2008 13:55:29 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <016001c89358$683d44b0$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQBhifgaAAZwwaIA==
In-Reply-To: <09a301c891b4$ec440280$6c02a8c0@china.huawei.com>
Cc: isms@ietf.org
Subject: Re: [Isms] RADEXT WG Last Call on NAS ManagementAuthorizationSpecification
X-BeenThere: isms@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/isms>
List-Post: <mailto:isms@ietf.org>
List-Help: <mailto:isms-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms
- [Isms] FW: RADEXT WG Last Call on NAS Management … David B. Nelson
- Re: [Isms] FW: RADEXT WG Last Call on NAS Managem… David Harrington
- Re: [Isms] RADEXT WG Last Call on NAS ManagementA… David B. Nelson
- Re: [Isms] RADEXT WG Last Call on NAS Management … David B. Nelson
- Re: [Isms] RADEXT WG Last Call on NAS ManagementA… David Harrington
- Re: [Isms] RADEXT WG Last Call on NAS ManagementA… David B. Nelson