[secdir] secdir review of draft-ietf-netconf-access-control-06

Carl Wallace <carl@redhoundsoftware.com> Mon, 28 November 2011 21:48 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B961521F8C28; Mon, 28 Nov 2011 13:48:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68v7-G-0IyEY; Mon, 28 Nov 2011 13:48:53 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 097EE21F8D2F; Mon, 28 Nov 2011 13:48:52 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so5835505vcb.31 for <multiple recipients>; Mon, 28 Nov 2011 13:48:52 -0800 (PST)
Received: by 10.220.142.8 with SMTP id o8mr5391828vcu.38.1322516932508; Mon, 28 Nov 2011 13:48:52 -0800 (PST)
Received: from [192.168.1.5] (pool-173-79-170-49.washdc.fios.verizon.net. [173.79.170.49]) by mx.google.com with ESMTPS id df14sm36986668vdb.0.2011.11.28.13.48.50 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 13:48:51 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.13.0.110805
Date: Mon, 28 Nov 2011 16:48:38 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: draft-ietf-netconf-access-control.all@tools.ietf.org
Message-ID: <CAF70484.E7EA%carl@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-netconf-access-control-06
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-netconf-access-control-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2011 21:48:53 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

This document defines such an access control model to restrict NETCONF
protocol access for particular users to a pre-configured subset of all
available NETCONF protocol operations and content.

I am not familiar with NETCONF or YANG so my review may be off-base.

I found the frequent references to "recovery sessions" and "non-recovery
sessions" unnecessary and somewhat confusing.  Couldn't this concept be
described once and omitted from the various lists of steps?  There are
probably some inconsistencies in the RFC 2119 language around the
"recovery session" concept.  For example, section 3.4.4 provides a
bulleted list of steps that MUST be followed.  Included in this list is an
exception for recovery sessions.  Section 3.3.1 says a "server MAY support
a "recovery session" mechanism".  Should 3.3.1 be a MUST?

Section 3.1.1 references both "recovery session" and the ability to
disable the entire access control model "during operation, in order to
debug operational problems".  What does the latter bullet that mentions
debugging refer to in the model?  Is this bullet just a second reference
to recovery session?

In section 3.2.4, copy operations may be partially performed while "nodes
to which the client does not have read access are silently omitted".  Why
is this OK?  It seems inconsistent with section 3.1.3, which says "If the
user is authorized to perform the requested access operation on the
requested data, then processing continues", implying that processing does
not continue otherwise.  The same silent skipping of items appears
elsewhere as well, including edit config.  At a minimum, some rationale
describing why these silent omissions are acceptable should be provided.