Network Configuration Protocol (NETCONF) Access Control Model
draft-ietf-netconf-access-control-07

[Ballot comment]
1) in section 3.5, the one sentence refers to section 3.5. I don't think the sentence adds anything, even if you meant to point to the YANG module in 3.5.2.

[Ballot discuss]
I plan to ballot YES once a few concerns are addressed.

1) in 3.4.3, a server must not include sensitive information. How does one determine what is sensitive? Should the server check the sensitivity marker in the mib module? without clear definition of sensitive, the "MUST NOT" doesn't make much sense, since the implementation cannot implement such a rule in an interoperable manner

2) in 3.4.5, the securituy considerations section should discuss the potential for misuse of adding groups from the transport. This effectively overrides the constraints pre-configured by an admin in the nacm. Should there be an enable/disable object that allows an admin to say "do NOT consider the groups specified by transport"? (ISMS had a long discussion about whether RADIUS or the pre-configured VACM rules should be dominant.)

3) section 3.4.6 says nacm configuration for notifications is out of scope of this document. Is there a document that does address this?

4) SNMPv3's VACM describes how to apply rules to notifications. If nacm for notifications is content-ignorant, then the security considerations should advise admins to be aware that any user authorized to receive notifications has access to any data that might be included in the notification. This could cause inadvertently disclose to a user information that should be subject to privacy rules (and potentially privacy laws), or other sensitive data that should not be sharable across users.

[Ballot comment]
#1) I agree with Stephen & Peter.

#2)

s2.6: It might be nice to clarify this somewhat:

It ought to be possible to disable part or all of the access control
model without deleting any access control rules.

s3.1.1: and here:

  o  The entire ACM can be disabled during operation, in order to debug
      operational problems.

I agree it ought to be possible but it ought to be possible only by appropriately authorized users (i.e., the admin).

#3) s3.1.2: Contains the following:

  It is expected that the mandatory transport
  mapping NETCONF Over SSH [RFC6242] is also supported by the server,
  and that the server has access to the user name associated with each
  session.

Why isn't this a MUST/SHOULD kind of sentence:

  Servers MUST support the NETCONF Over SSH [RFC6242] It is expected that
  the mandatory transport mapping, and the server MUST have access to the
  user name associated with each session.

[Ballot comment]
I concur with Stephen Farrell's comments about the incompleteness and vagueness of the text about derivation and handling of user names and group names.

[Ballot comment]
- I'd still be happier if there were more text advising developers
to be careful mapping from an authenticated identity to a NACM user
name and associated groups, and in particular calling out a pitfall
or two in doing that (e.g. i18n in names, null characters in
authenticated identity). That is there by reference (to RFC 6241 I
guess) but it'd be better to be explicit I think. (In section 3.3.1
ideally.)

- Its still not quite clear to me how the "transport layer" can
provide group memberships properly. RFC 6421 doesn't say and 2.5
just says that something "such as a RADIUS server" could be used.  I
think you could add a security consideration saying that unless you
have the same level of security in how you get the username and
group membership information, then you might be in trouble. E.g. if
SSH provides the username with fairly good security, but then RADIUS
is used for group memberships with less good security, then you may
have a problem.

- typo: 3.7.1 s/contents enabled,/contents is enabled,/

State changed to In Last Call from IESG Evaluation.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Network Configuration Protocol (NETCONF) Access Control Model) to Proposed Standard


The IESG has received a request from the Network Configuration WG
(netconf) to consider the following document:
- 'Network Configuration Protocol (NETCONF) Access Control Model'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The standardization of network configuration interfaces for use with
  the NETCONF protocol requires a structured and secure operating
  environment that promotes human usability and multi-vendor
  interoperability.  There is a need for standard mechanisms to
  restrict NETCONF protocol access for particular users to a pre-
  configured subset of all available NETCONF protocol operations and
  content.  This document defines such an access control model.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/


No IPR declarations have been submitted directly on this I-D.

IANA understands that, upon approval of this document, there are two
IANA actions which must be completed.

First, in the IETF XML namespace registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new URI will be registered as follows:

ID: ietf-netconf-acm
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
Registration template: [ as provided in section 3.6 of the approved
document ]
Reference: [ RFC-to-be ]

Second, in the YANG Module Names registry contained in the YANG
Parameters registry located at:

http://www.iana.org/assignments/yang-parameters/yang-parameters.xml

the following registration will be added to the registry:

Name: ietf-netconf-acm
Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
Prefix: nacm
Module: [ left blank ]
Reference: [ RFC-to-be ]

IANA understands these to be the only actions required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Network Configuration Protocol (NETCONF) Access Control Model) to Proposed Standard


The IESG has received a request from the Network Configuration WG
(netconf) to consider the following document:
- 'Network Configuration Protocol (NETCONF) Access Control Model'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The standardization of network configuration interfaces for use with
  the NETCONF protocol requires a structured and secure operating
  environment that promotes human usability and multi-vendor
  interoperability.  There is a need for standard mechanisms to
  restrict NETCONF protocol access for particular users to a pre-
  configured subset of all available NETCONF protocol operations and
  content.  This document defines such an access control model.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the 
      Document Shepherd personally reviewed this version of the 
      document and, in particular, does he or she believe this 
      version is ready for forwarding to the IESG for publication?

     
      I, Bert Wijnen, am the Document Shepherd for this document.
      I have personally reviewed this version of the document and I
      believe it is ready for publication.
     
      Adequate review has occurred from WG members. We've gone to a
      couple of WG Last Calls, which resulted in comments and
      corrections/clarifications to the current document. The issues
      raised in the reviews have been discussed on the mailing list
      and fixed in the last versions.
       
(1.b) Has the document had adequate review both from key WG members 
      and from key non-WG members? Does the Document Shepherd have 
      any concerns about the depth or breadth of the reviews that 
      have been performed?     

      The document has had adequate review from working group and
      non-working group members, mostly from NETCONF and NETMOD WGs. 
      I do not have any concerns about the depth or breadth of review. 

(1.c) Does the Document Shepherd have concerns that the document 
      needs more review from a particular or broader perspective, 
      e.g., security, operational complexity, someone familiar with 
      AAA, internationalization or XML?

      No. We tried very hard to get review from our Security Advisor
      but he seemed to be too busy. We then got the preliminary
      review from the Security ADs and their comments have been
      addressed in the latest revision.

(1.d) Does the Document Shepherd have any specific concerns or 
      issues with this document that the Responsible Area Director 
      and/or the IESG should be aware of? For example, perhaps he 
      or she is uncomfortable with certain parts of the document, or 
      has concerns whether there really is a need for it. In any 
      event, if the WG has discussed those issues and has indicated 
      that it still wishes to advance the document, detail those 
      concerns here. Has an IPR disclosure related to this document 
      been filed? If so, please include a reference to the 
      disclosure and summarize the WG discussion and conclusion on 
      this issue.

      There are no concerns about the technical merit of the document.
      There are no IPR disclosures filed on this document.

(1.e) How solid is the WG consensus behind this document? Does it 
      represent the strong concurrence of a few individuals, with 
      others being silent, or does the WG as a whole understand and 
      agree with it?
 
      There is strong consensus in the WG to publish this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme 
      discontent? If so, please summarise the areas of conflict in 
      separate email messages to the Responsible Area Director. (It 
      should be in a separate email because this questionnaire is 
      entered into the ID Tracker.)

      No.

(1.g) Has the Document Shepherd personally verified that the 
      document satisfies all ID nits? (See 
      http://www.ietf.org/ID-Checklist.html and 
      http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
      not enough; this check needs to be thorough. Has the document 
      met all formal review criteria it needs to, such as the MIB 
      Doctor, media type and URI type reviews?
     
      Yes. There are no nits in this draft.
 
(1.h) Has the document split its references into normative and 
      informative? Are there normative references to documents that 
      are not ready for advancement or are otherwise in an unclear 
      state? If such normative references exist, what is the 
      strategy for their completion? Are there normative references 
      that are downward references, as described in [RFC3967]? If 
      so, list these downward references to support the Area 
      Director in the Last Call procedure for them [RFC3967].

      The document has both normative references and informative
      references, and they have been provided properly.

(1.i) Has the Document Shepherd verified that the document IANA 
      consideration section exists and is consistent with the body 
      of the document? If the document specifies protocol 
      extensions, are reservations requested in appropriate IANA 
      registries? Are the IANA registries clearly identified? If 
      the document creates a new registry, does it define the 
      proposed initial contents of the registry and an allocation 
      procedure for future registrations? Does it suggest a 
      reasonable name for the new registry? See [RFC5226]. If the 
      document describes an Expert Review process has Shepherd 
      conferred with the Responsible Area Director so that the IESG 
      can appoint the needed Expert during the IESG Evaluation?

      IANA considerations are complete and consistent with RFC 3688.
      The draft requests to register one XML namespace URN and one
      module name in the 'YANG Module Names' registry.

(1.j) Has the Document Shepherd verified that sections of the 
      document that are written in a formal language, such as XML 
      code, BNF rules, MIB definitions, etc., validate correctly in 
      an automated checker?

      The YANG module in the document has been checked for validity
      and is syntactically correct.

(1.k) The IESG approval announcement includes a Document 
      Announcement Write-Up. Please provide such a Document 
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval 
      announcement contains the following sections:           

      Technical Summary 

      This document addresses access control mechanisms for the
      Operation and Content layers of NETCONF, as defined in
      RFC6241.  It contains three main sections:

          1.  Access Control Design Objectives
          2.  NETCONF Access Control Model (NACM)
          3.  YANG Data Model (ietf-netconf-acm.yang)

      Working Group Summary 

      The document has been extensively discussed in the Working Group,
      including several WG Last Calls. The comments and reviews helped
      to improve the document a lot and the current version reflects the
      consensus of the Working Group.
      The Security ADs have also reviewed revision 5 of the document.
      We specifically asked for a Detailed Security review, because
      the content of this document is all about access control and
      secure and properly authorized access to the NETCONF protocol and
      content. The last WGLC did raise only minor issues. The changes
      have been accepted by the WG.

      Document Quality

      mplementations of earlier drafts do (partially) exist and it
      is expected that NETCONF implementations will be extended once
      this document gets published as proposed standard.

Bert Wijnen
Document Shepherd