Network Configuration Protocol (NETCONF) Access Control Model
draft-ietf-netconf-access-control-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the Yes position for David Harrington |
2012-01-23
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-01-23
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-01-20
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-01-12
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2012-01-11
|
07 | (System) | IANA Action state changed to In Progress |
2012-01-11
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2012-01-11
|
07 | Amy Vezza | IESG has approved the document |
2012-01-11
|
07 | Amy Vezza | Closed "Approve" ballot |
2012-01-11
|
07 | Amy Vezza | Approval announcement text regenerated |
2012-01-11
|
07 | Amy Vezza | Ballot writeup text changed |
2012-01-11
|
07 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
2011-12-23
|
07 | David Harrington | [Ballot discuss] |
2011-12-23
|
07 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to Yes from Discuss |
2011-12-23
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-12-23
|
07 | (System) | New version available: draft-ietf-netconf-access-control-07.txt |
2011-12-04
|
07 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Carl Wallace. |
2011-12-01
|
07 | Cindy Morgan | Removed from agenda for telechat |
2011-12-01
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead. |
2011-12-01
|
07 | David Harrington | [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 … [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. |
2011-12-01
|
07 | David Harrington | [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 … [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. |
2011-12-01
|
07 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded |
2011-12-01
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-12-01
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-12-01
|
07 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded |
2011-11-30
|
07 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-30
|
07 | Sean Turner | [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 … [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. |
2011-11-30
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-30
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-29
|
07 | Peter Saint-Andre | [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 … [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. |
2011-11-29
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-29
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-29
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-28
|
07 | Stephen Farrell | [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 … [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,/ |
2011-11-28
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-28
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-28
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-11-22
|
07 | Dan Romascanu | Last call sent |
2011-11-22
|
07 | Dan Romascanu | 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 … 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. |
2011-11-22
|
07 | Dan Romascanu | Placed on agenda for telechat - 2011-12-01 |
2011-11-22
|
07 | Dan Romascanu | State changed to IESG Evaluation from In Last Call. |
2011-11-22
|
07 | Dan Romascanu | Approval announcement text regenerated |
2011-11-22
|
07 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu |
2011-11-22
|
07 | Dan Romascanu | Ballot has been issued |
2011-11-22
|
07 | Dan Romascanu | Created "Approve" ballot |
2011-11-14
|
07 | Amanda Baber | 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 … 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. |
2011-11-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2011-11-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2011-11-08
|
07 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2011-11-08
|
07 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2011-11-07
|
07 | Amy Vezza | 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: … 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. |
2011-11-07
|
07 | Dan Romascanu | Last Call was requested |
2011-11-07
|
07 | Dan Romascanu | State changed to Last Call Requested from AD Evaluation. |
2011-11-07
|
07 | Dan Romascanu | Last Call text changed |
2011-11-07
|
07 | (System) | Ballot writeup text was added |
2011-11-07
|
07 | (System) | Last call text was added |
2011-11-07
|
07 | (System) | Ballot approval text was added |
2011-11-07
|
07 | Dan Romascanu | State changed to AD Evaluation from Publication Requested. |
2011-11-04
|
07 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (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 |
2011-11-04
|
07 | Cindy Morgan | Draft added in state Publication Requested |
2011-11-04
|
07 | Cindy Morgan | [Note]: 'Bert Wijnen (bertietf@bwijnen.net) is the document shepherd.' added |
2011-10-31
|
06 | (System) | New version available: draft-ietf-netconf-access-control-06.txt |
2011-10-04
|
05 | (System) | New version available: draft-ietf-netconf-access-control-05.txt |
2011-06-15
|
04 | (System) | New version available: draft-ietf-netconf-access-control-04.txt |
2011-03-11
|
03 | (System) | New version available: draft-ietf-netconf-access-control-03.txt |
2011-02-03
|
02 | (System) | New version available: draft-ietf-netconf-access-control-02.txt |
2010-10-25
|
01 | (System) | New version available: draft-ietf-netconf-access-control-01.txt |
2010-09-02
|
00 | (System) | New version available: draft-ietf-netconf-access-control-00.txt |