From internet-drafts@ietf.org Tue Oct 4 10:10:53 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4542A21F8DA1; Tue, 4 Oct 2011 10:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UbF+DhpoSN0T; Tue, 4 Oct 2011 10:10:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA73021F8D92; Tue, 4 Oct 2011 10:10:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2011 10:10:52 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:10:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group o= f the IETF. Title : Network Configuration Protocol (NETCONF) Access Control = Model Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-access-control-05.txt Pages : 52 Date : 2011-10-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-05.txt From bertietf@bwijnen.net Wed Oct 5 00:52:37 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C3921F8A62 for ; Wed, 5 Oct 2011 00:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 athvD6lma0E4 for ; Wed, 5 Oct 2011 00:52:37 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id EA76721F8A56 for ; Wed, 5 Oct 2011 00:52:36 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RBMKJ-0000jB-Mt for netconf@ietf.org; Wed, 05 Oct 2011 09:55:42 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RBMKJ-0005Qp-Hp for netconf@ietf.org; Wed, 05 Oct 2011 09:55:39 +0200 Message-ID: <4E8C0D7B.40807@bwijnen.net> Date: Wed, 05 Oct 2011 09:55:39 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: netconf References: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> In-Reply-To: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48883960ae0f5d24834b2f26cbde4fdef Subject: [Netconf] Fwd: I-D Action: draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 07:52:37 -0000 -------- Original Message -------- Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-05.txt Date: Tue, 04 Oct 2011 10:10:52 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: netconf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Access Control Model Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-access-control-05.txt Pages : 52 Date : 2011-10-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-05.txt _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Wed Oct 5 04:46:47 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7B821F8CEA for ; Wed, 5 Oct 2011 04:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 es+LNG7EkCoG for ; Wed, 5 Oct 2011 04:46:46 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 965AD21F8CE9 for ; Wed, 5 Oct 2011 04:46:43 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RBPyu-00047D-Ml for netconf@ietf.org; Wed, 05 Oct 2011 13:49:50 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RBPyu-0002CY-G0 for netconf@ietf.org; Wed, 05 Oct 2011 13:49:48 +0200 Message-ID: <4E8C445B.7080201@bwijnen.net> Date: Wed, 05 Oct 2011 13:49:47 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: netconf References: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> In-Reply-To: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4f15e6623b7382228ef92e14f88c5fd65 Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control-05.txt - runs till okt 21st 2011 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 11:46:47 -0000 Dear WG members, last night a new revision of the Access Control Model document wat posted (revision 05). The changes (as documented) in the ID itself are listed below. A quick browse of the document does show that the text has been touched quite a bit. So a good and detailed review is important. Please do check if all your comments have been addressed. Send you reviews and comments no later than 21 Okt 2011. Just letting us know that you have read the document and can approve of it or have no objections, also that is useful for us (WG chairs) to determine review activity and consensus. If this WGLC passes without too much serious issues, then the next step will be IETF wide LC. Possibly even before the next IETF meeting. Changelog for rev 4 to rev 5. Updated Security Considerations section. Changed term 'operator' to 'administrator'. Used the terms "access operation" and "protocol operation" consistently. Moved some normative text from section 2 to section 3. Also made it more clear that section 2 is not a requirements section, but documentation of the objectives for NACM. Renamed "nacm:secure" to "nacm:default-deny-write", and "nacm:very- secure" to "nacm:default-deny-all". Explained that "nacm:default- deny-write" is ignored on rpc statements. Described that and behave as if specified with "nacm:default-deny-all". Bert and Mehmet From ietfc@btconnect.com Wed Oct 5 06:26:45 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3280B21F8CDE for ; Wed, 5 Oct 2011 06:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] 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 8S2Ph0YH0b-M for ; Wed, 5 Oct 2011 06:26:44 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 373D721F8CD9 for ; Wed, 5 Oct 2011 06:26:43 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr09.btconnect.com with SMTP id ESA79170; Wed, 05 Oct 2011 14:29:46 +0100 (BST) Message-ID: <017401cc8359$d5882860$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Alan Luchuk" References: <201109301850.OAA14004@adminfs.snmp.com> Date: Wed, 5 Oct 2011 14:22:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E8C5BCA.0001, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.5.121814:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4E8C5BCB.01A9,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 13:26:45 -0000 ---- Original Message ----- From: "Alan Luchuk" To: Cc: Sent: Friday, September 30, 2011 8:50 PM > > >I think this is what we do need. > >How does RFC 6353 deal when certificates include multiple instances of the > >subjectAltName (refer to Wes example, multiple rfc822Names)? > > RFC 6353 has a defined mechanism for handling different fields of the > subjectAltName extension (e.g.; rfc822Name, dNSName, iPAddress), but I > think it is silent about handling multiple instances of the same field > (e.g.; multiple instances of the rfc822Name). I've taken a quick scan > over RFC 6353 again, and do not immediately notice anything about multiple > instances of the same field. I'd have to re-read carefully to make sure. Alan This issue came up when the I-D was being reviewed and Jeff said "I'm not sure what this is supposed to do. It sounds like "pick any arbitrary SAN you see in the certificate, and turn it into a securityName". But that leaves unspecified which one to pick if there is more than one, and how to turn arbitrary otherName types into an SNMP securityName." which is what we have ended up with. But the onus is on the generator of the certificate. The intention is that fields such as SAN are an identifier for the party in question and that the certificate provides a cryptographic binding between key and identifier, with the protocol, such as TLS, providing proof of possession of the key, so if the identifier does not identify, then that is a problem with the certificate issuer. For example, every organisation that has ever employed me has given me an employee number and that (or SSN), coupled with an organisation identifier, would uniquely identify me in a certificate, which would then identify the netconf or SNMP client to the server. Tom Petch > In the case where a certificate contains multiple instances of the same > subjectAltName field, it would be easier for our implementation if a > single NETCONF username was produced from a certificate. That is, the > mapping code prioritizes and selects the NETCONF username, rather than > producing a set of NETCONF usernames that are handed up and must be > prioritized by a higher layer in the code. I would suspect this would > be true for other NETCONF/TLS implementations as well. > > Perhaps you have posted this already, but do you have a suggested mechanism > for handling multiple instances of the same field in the subjectAltName > extension? If so, I would envision this as just another mapping choice, > with perhaps another mapping configuration parameter. > > Regards, > --Alan > From bertietf@bwijnen.net Thu Oct 6 03:09:25 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA2321F8C21 for ; Thu, 6 Oct 2011 03:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7MYDzcr10o75 for ; Thu, 6 Oct 2011 03:09:24 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 3E41F21F8C1F for ; Thu, 6 Oct 2011 03:09:22 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RBkwI-0006n9-6g for netconf@ietf.org; Thu, 06 Oct 2011 12:12:31 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest187.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RBkwH-0004Ao-BD for netconf@ietf.org; Thu, 06 Oct 2011 12:12:29 +0200 Message-ID: <4E8D7F0D.3070701@bwijnen.net> Date: Thu, 06 Oct 2011 12:12:29 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: netconf References: <20111004171052.18527.45783.idtracker@ietfa.amsl.com> <4E8C445B.7080201@bwijnen.net> In-Reply-To: <4E8C445B.7080201@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd426eb2a286010cd562c81d47cb4fa4868 Subject: [Netconf] my review for WG Last Call for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 10:09:25 -0000 The following are my comments/questions after my first read of draft-ietf-netconf-access-control-05.txt. The are provided with my individual/technical contributor hat on. In general, I think this document is ready to pass to the next stage, i.e. send it to our AD for consideration to publish as PS RFC. On page 13, 2nd bullet it says: o If the configuration datastore or conceptual state data is accessed by the protocol operation, then the data node access MUST be authorized. If the user is authorized to perform the requested access operation on the requested data, then processing continues. So my question: is an error returned if access is NOT authorized? Or if part of the data is authorized and not other parts. I think it becomes clearer on the following pages, but possibly adding some text here to explain that non-accessible data-nodes are skipped (on read at least). Or are you meaning that "at least to one data node access MUST be authorized" in order to continue processing. Remains the question: will there be an an error returned if that is not the case? Maybe the once sentence to add here could be: See following pages which (if any) error is returned in case there is no authorization. Section 3.2, 2nd para: Only the standard NETCONF datastores (candidate, running, and startup) are controlled by the ACM. Local or remote files or datastores accessed via the parameter are optional to support. "are optional to support". From a security standpoint? I suspect that you mean to say that support is an optional capability in the NETCONF protocol, and that if that capability is supported, that the security/access-control to those datastores is an implementation specific method? If so, maybe we should make that clearer. Pure editorial: Step 7 on page 26 * The rule does not have a "rule-type" defined, or the "rule- type" is "notification" and the "notification-name" is "*", equals the name of the notification. s/equals/or equals/ I think Section: 3.5. Data Model Definitions This section defines the semantics of the conceptual data structures found in the data model in Section 3.5. So that last "Section 3.5" is a self-reference? Middle of page 38: NACM requires some a user name in each NACM group mapping. An s/some // ?? Page 48: permit-interface: This rule gives the "admin" group read-write access to all acme . entries. This is an example of an unreachable rule because the "mod-3" rule already gives the "admin" group full access to this data. which "mod-3" rule? It was specified/used in revision 4 of the doc, but not in this revision. Bert From bertietf@bwijnen.net Thu Oct 6 04:42:48 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0598821F8AF0 for ; Thu, 6 Oct 2011 04:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 NxPXW8DMHbej for ; Thu, 6 Oct 2011 04:42:47 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 38AAD21F8549 for ; Thu, 6 Oct 2011 04:42:47 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RBmOg-0007Hj-4n for netconf@ietf.org; Thu, 06 Oct 2011 13:45:56 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest187.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RBmOf-00022Z-PP for netconf@ietf.org; Thu, 06 Oct 2011 13:45:54 +0200 Message-ID: <4E8D94F1.1070705@bwijnen.net> Date: Thu, 06 Oct 2011 13:45:53 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: netconf References: <20110807165910.14868.70087.idtracker@ietfa.amsl.com> In-Reply-To: <20110807165910.14868.70087.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110807165910.14868.70087.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47125ebaa7d9b390645f827348de65976 Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 11:42:48 -0000 Dear WG participants, I thought I had already re-issued a new WG LC for this revision 5 of the system notifications document. But it seems I did not do that. Revision 5 came out soon after our Quebec IETF session. It is supposed top address all WGLC comments on revision 4. So... this is a formal WG Last Call for document draft-ietf-netconf-system-notifications-05.txt. Pls send your comments/reviews/question no later than Oct 21st 2011. The next step after this WGLC is to pass this to our AD for consideration to publish as PS RFC. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] I-D Action: draft-ietf-netconf-system-notifications-05.txt Date: Sun, 07 Aug 2011 09:59:10 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: netconf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Base Notifications Author(s) : Andy Bierman Filename : draft-ietf-netconf-system-notifications-05.txt Pages : 16 Date : 2011-08-07 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-05.txt _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Thu Oct 6 04:54:44 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C29821F8C4B for ; Thu, 6 Oct 2011 04:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 UYfsa+bDFT5C for ; Thu, 6 Oct 2011 04:54:43 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A166C21F8C3C for ; Thu, 6 Oct 2011 04:54:43 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AC74F1200D1E; Thu, 6 Oct 2011 13:57:52 +0200 (CEST) Date: Thu, 06 Oct 2011 13:57:52 +0200 (CEST) Message-Id: <20111006.135752.1891507190391608102.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4E8D94F1.1070705@bwijnen.net> References: <20110807165910.14868.70087.idtracker@ietfa.amsl.com> <4E8D94F1.1070705@bwijnen.net> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 11:54:44 -0000 Hi, "Bert Wijnen (IETF)" wrote: > Dear WG participants, > > I thought I had already re-issued a new WG LC for this revision > 5 of the system notifications document. So did I... > Pls send your comments/reviews/question no later than Oct 21st 2011. Please consider my comments: http://www.ietf.org/mail-archive/web/netconf/current/msg07108.html http://www.ietf.org/mail-archive/web/netconf/current/msg07110.html as WGLC comments for -05. /martin From bwijnen@ripe.net Thu Oct 6 11:14:16 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB921F8DC1 for ; Thu, 6 Oct 2011 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 gV2WG2LgOXXD for ; Thu, 6 Oct 2011 11:14:16 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id E529721F8DBD for ; Thu, 6 Oct 2011 11:14:15 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RBsVX-00029v-DL; Thu, 06 Oct 2011 20:17:24 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RBsVX-0003CI-7E; Thu, 06 Oct 2011 20:17:23 +0200 Message-ID: <4E8DF0B2.80807@ripe.net> Date: Thu, 06 Oct 2011 20:17:22 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Andy Bierman References: <4E8D9C0A.4030101@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.4 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e5c4182b489a906b8c47ac191581aaac4 Cc: netconf Subject: Re: [Netconf] Quention on IANA considerations in system-notifcations-o5 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:14:16 -0000 I was wondering if there was a special reason. I think it is best if we're consistent in how we do this. Probably best to keep a note that if/when you make any more changes, then maybe change this as well. Bert On 10/6/11 4:58 PM, Andy Bierman wrote: > I can change it if you want > > -----Original Message----- > From: Bert Wijnen [mailto:bwijnen@ripe.net] > Sent: Thursday, October 06, 2011 5:16 AM > To: Andy Bierman > Cc: Ersue, Mehmet (NSN - DE/Munich) > Subject: Quention on IANA considerations in system-notifcations-o5 > > Andy, I see > > > URI: urn:ietf:params:xml:ns:yang:ietf-netconf-notifications > > Registrant Contact: The NETCONF WG of the IETF. > > XML: N/A, the requested URI is an XML namespace. > > > Where as in the access-contold 05 document I see: > > URI: urn:ietf:params:xml:ns:yang:ietf-netconf-acm > Registrant Contact: The IESG. > XML: N/A, the requested URI is an XML namespace. > > > So why do we not use IESG as Registrant Contact, As I believe > we have always done sofar? The NETCONF WG will be closed at some > point in the future, no? > > Bert From ietf@andybierman.com Thu Oct 6 11:51:57 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB18821F8A6F for ; Thu, 6 Oct 2011 11:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 kgog6TqrFuAF for ; Thu, 6 Oct 2011 11:51:56 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB6321F899F for ; Thu, 6 Oct 2011 11:51:54 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p96IsxwR013036 for ; Thu, 6 Oct 2011 14:55:01 -0400 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:34953] helo=[192.168.0.6]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C5/AA-04444-289FD8E4; Thu, 06 Oct 2011 14:54:59 -0400 Message-ID: <4E8DF981.8070106@andybierman.com> Date: Thu, 06 Oct 2011 11:54:57 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Bert Wijnen References: <4E8D9C0A.4030101@ripe.net> <4E8DF0B2.80807@ripe.net> In-Reply-To: <4E8DF0B2.80807@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] Quention on IANA considerations in system-notifcations-o5 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:51:57 -0000 On 10/06/2011 11:17 AM, Bert Wijnen wrote: > I was wondering if there was a special reason. > I think it is best if we're consistent in how > we do this. I probably wasn't paying attention again ;-) No real reason to pick NETCONF WG. > > Probably best to keep a note that if/when you make > any more changes, then maybe change this as well. > OK > Bert > Andy > On 10/6/11 4:58 PM, Andy Bierman wrote: >> I can change it if you want >> >> -----Original Message----- >> From: Bert Wijnen [mailto:bwijnen@ripe.net] >> Sent: Thursday, October 06, 2011 5:16 AM >> To: Andy Bierman >> Cc: Ersue, Mehmet (NSN - DE/Munich) >> Subject: Quention on IANA considerations in system-notifcations-o5 >> >> Andy, I see >> >> >> URI: urn:ietf:params:xml:ns:yang:ietf-netconf-notifications >> >> Registrant Contact: The NETCONF WG of the IETF. >> >> XML: N/A, the requested URI is an XML namespace. >> >> >> Where as in the access-contold 05 document I see: >> >> URI: urn:ietf:params:xml:ns:yang:ietf-netconf-acm >> Registrant Contact: The IESG. >> XML: N/A, the requested URI is an XML namespace. >> >> >> So why do we not use IESG as Registrant Contact, As I believe >> we have always done sofar? The NETCONF WG will be closed at some >> point in the future, no? >> >> Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From reid@snmp.com Wed Oct 12 06:34:26 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01A221F8C58 for ; Wed, 12 Oct 2011 06:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NC9gXaSMHtVI for ; Wed, 12 Oct 2011 06:34:26 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0467221F8BA7 for ; Wed, 12 Oct 2011 06:34:25 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA24243 for ; Wed, 12 Oct 2011 09:33:51 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA05470 for ; Wed, 12 Oct 2011 09:33:44 -0400 (EDT) Message-Id: <201110121333.JAA05470@adminfs.snmp.com> To: netconf@ietf.org Date: Wed, 12 Oct 2011 09:33:44 -0400 From: David Reid Subject: [Netconf] yang ordering X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:34:26 -0000 I have 2 questions about ordering in yang. Both questions are related to the mib to yang conversion tool I'm working on. 1. In YANG, does the order in which the leaf objects that are part of the key appear in a list matter? APPLICATION-MIB (RFC 2564) defines: applSrvInstToRunApplElmtEntry OBJECT-TYPE SYNTAX ApplSrvInstToRunApplElmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "..." INDEX { applSrvIndex, sysApplElmtRunIndex } ::= { applSrvInstToRunApplElmtTable 1 } ApplSrvInstToRunApplElmtEntry ::= SEQUENCE { applSrvIndex Unsigned32 } When I convert to yang, I put sysApplElmtRunIndex in the list before applSrvIndex, which is not the order that they are defined in the MIB INDEX or YANG key. I noticed that smidump also does it this way. Here is the yang produced: list applSrvInstToRunApplElmtEntry { smiv2:oid "1.3.6.1.2.1.62.1.1.3.1"; key "applSrvIndex sysApplElmtRunIndex"; description "..."; leaf sysApplElmtRunIndex { type leafref { path "/sysappl-mib:sysApplElmtRunTable... } } leaf applSrvIndex { smiv2:oid "1.3.6.1.2.1.62.1.1.3.1.1"; type uint32 { range "1..4294967295"; } description "..."; smiv2:max-access read-only; } I believe the yang spec requires that the encoding on the wire puts applSrvIndex first and sysApplElmtRunIndex second. I'm not sure that it matters what order they are in in the yang document. It seems to me that we should agree on an ordering that we all follow, but I'm wondering if it really matters. 2. Does the order in which objects appear in a yang module matter. The IF-MIB defines the following 5 tables in this order: ifTable ifXTable ifStackTable ifRcvAddressTable ifTestTable When I convert to yang, I sort lexigraphically before printing the yang module. That results in the yang table containers or augments in this order: ifTable ifXTable ifStackTable ifTestTable ifRcvAddressTable smidump prints the table containers first followed by the augments, resulting in this order: ifTable ifStackTable ifRcvAddressTable ifXTable ifTestTable Do we need to agree on an order? Or is it OK for different tools to produce a different ordering? -David Reid From bertietf@bwijnen.net Fri Oct 14 00:21:52 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6921F8B53 for ; Fri, 14 Oct 2011 00:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TYkvIBCbAGac for ; Fri, 14 Oct 2011 00:21:51 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 2749621F8B40 for ; Fri, 14 Oct 2011 00:21:49 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1REc5R-0007vd-1o for netconf@ietf.org; Fri, 14 Oct 2011 09:21:48 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest187.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1REc5Q-0000JI-6R for netconf@ietf.org; Fri, 14 Oct 2011 09:21:44 +0200 Message-ID: <4E97E308.60103@bwijnen.net> Date: Fri, 14 Oct 2011 09:21:44 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netconf References: <4E8C445B.7080201@bwijnen.net> In-Reply-To: <4E8C445B.7080201@bwijnen.net> X-Forwarded-Message-Id: <4E8C445B.7080201@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42b28c9a6164afefc396576c46e17155d Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control-05.txt - runs till okt 21st 2011 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 07:21:52 -0000 Gentle reminder! Please do review and post your comments/questions/support/objections by Friday 21st of October. We explicitly ask you to ALSO let us know if you have read and support or agree with the document. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control-05.txt - runs till okt 21st 2011 Date: Wed, 05 Oct 2011 13:49:47 +0200 From: Bert Wijnen (IETF) To: netconf Dear WG members, last night a new revision of the Access Control Model document wat posted (revision 05). The changes (as documented) in the ID itself are listed below. A quick browse of the document does show that the text has been touched quite a bit. So a good and detailed review is important. Please do check if all your comments have been addressed. Send you reviews and comments no later than 21 Okt 2011. Just letting us know that you have read the document and can approve of it or have no objections, also that is useful for us (WG chairs) to determine review activity and consensus. If this WGLC passes without too much serious issues, then the next step will be IETF wide LC. Possibly even before the next IETF meeting. Changelog for rev 4 to rev 5. Updated Security Considerations section. Changed term 'operator' to 'administrator'. Used the terms "access operation" and "protocol operation" consistently. Moved some normative text from section 2 to section 3. Also made it more clear that section 2 is not a requirements section, but documentation of the objectives for NACM. Renamed "nacm:secure" to "nacm:default-deny-write", and "nacm:very- secure" to "nacm:default-deny-all". Explained that "nacm:default- deny-write" is ignored on rpc statements. Described that and behave as if specified with "nacm:default-deny-all". Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Fri Oct 14 00:23:19 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6480621F8B40 for ; Fri, 14 Oct 2011 00:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3MrbQF+DYqPP for ; Fri, 14 Oct 2011 00:23:18 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 8804E21F84B8 for ; Fri, 14 Oct 2011 00:23:18 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1REc6s-0002SZ-Jv for netconf@ietf.org; Fri, 14 Oct 2011 09:23:16 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest187.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1REc6s-0000Pq-G7 for netconf@ietf.org; Fri, 14 Oct 2011 09:23:14 +0200 Message-ID: <4E97E362.4070102@bwijnen.net> Date: Fri, 14 Oct 2011 09:23:14 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netconf References: <4E8D94F1.1070705@bwijnen.net> In-Reply-To: <4E8D94F1.1070705@bwijnen.net> X-Forwarded-Message-Id: <4E8D94F1.1070705@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46bf0802a437f834701b6389df4ac9c15 Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 07:23:19 -0000 Gentle reminder! Please do review and post your comments/questions/support/objections by Friday 21st of October. We explicitly ask you to ALSO let us know if you have read and support or agree with the document. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st Date: Thu, 06 Oct 2011 13:45:53 +0200 From: Bert Wijnen (IETF) To: netconf Dear WG participants, I thought I had already re-issued a new WG LC for this revision 5 of the system notifications document. But it seems I did not do that. Revision 5 came out soon after our Quebec IETF session. It is supposed top address all WGLC comments on revision 4. So... this is a formal WG Last Call for document draft-ietf-netconf-system-notifications-05.txt. Pls send your comments/reviews/question no later than Oct 21st 2011. The next step after this WGLC is to pass this to our AD for consideration to publish as PS RFC. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] I-D Action: draft-ietf-netconf-system-notifications-05.txt Date: Sun, 07 Aug 2011 09:59:10 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: netconf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Base Notifications Author(s) : Andy Bierman Filename : draft-ietf-netconf-system-notifications-05.txt Pages : 16 Date : 2011-08-07 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-05.txt _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Fri Oct 14 09:58:36 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516621F8C55 for ; Fri, 14 Oct 2011 09:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 VDSOMBFY3nlO for ; Fri, 14 Oct 2011 09:58:36 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3179E21F8B09 for ; Fri, 14 Oct 2011 09:58:36 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9EGwYou000738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2011 18:58:34 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9EGwWQ8031557; Fri, 14 Oct 2011 18:58:33 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 18:57:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 18:57:19 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402CCCE74@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for NETCONF WG Session in IETF 82 Thread-Index: AcyKfqxhj4rSw/evRa+NbOi3TCkJFgAEpd6w From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 14 Oct 2011 16:57:20.0299 (UTC) FILETIME=[5633B7B0:01CC8A92] Subject: [Netconf] Draft Agenda for NETCONF WG Session in IETF 82 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:58:37 -0000 Dear NETCONF WG, this is the draft agenda for the NETCONF session in IETF 82 so far. Looks a bit thin for a two hours session. If there is any proposal to discuss please send us your proposal ASAP,=20 otherwise we will ask for a shorter session. Thanks. Mehmet & Bert Agenda for NETCONF WG Session -------------------------------------- IETF 82 - Taipei, Taiwan November 13-18, 2011 MONDAY, November 14, 2011 1300-1500, Afternoon Session I Room: 101D WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. Network Configuration Protocol Access Control Model - A. Bierman (?? min.)=20 http://tools.ietf.org/html/draft-ietf-netconf-access-control 2. NETCONF System Notifications - A. Bierman (?? min.)=20 =20 http://tools.ietf.org/html/draft-ietf-netconf-system-notification Non-chartered items: . . . Open mike: . . . Any topics to discuss?=20 AOB Cheers,=20 Mehmet=20 From mbadra@gmail.com Fri Oct 14 11:26:49 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA74F21F8BB3 for ; Fri, 14 Oct 2011 11:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KA21YzR0TCMK for ; Fri, 14 Oct 2011 11:26:48 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1503221F8B9D for ; Fri, 14 Oct 2011 11:26:47 -0700 (PDT) Received: by vws5 with SMTP id 5so1505495vws.31 for ; Fri, 14 Oct 2011 11:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hCcEJDQFUVPKWXLJIhrJo+JpUSsQPDq+yCOfAl1B1vg=; b=wpLTSmyP7BFdaP+PfihqFsiqCrQoc14RF4J7no+ywh4PKyxyRelURc6fXT1oP/A3AH bLUK/+MS0LqaQMA7alnOoLdNZ65UkeJGOxnygjXBFElKpcvo+BLkyTFHN3hZEoHLI0ud UOVDFC3njLV+4JLOXyAGzEyLaEwBYqE9guxK0= MIME-Version: 1.0 Received: by 10.52.17.239 with SMTP id r15mr3846780vdd.48.1318616805473; Fri, 14 Oct 2011 11:26:45 -0700 (PDT) Received: by 10.220.180.73 with HTTP; Fri, 14 Oct 2011 11:26:45 -0700 (PDT) Date: Fri, 14 Oct 2011 20:26:45 +0200 Message-ID: From: Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=bcaec502d79048fedf04af46669f Subject: [Netconf] NETCONF over TLS: username X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:26:50 -0000 --bcaec502d79048fedf04af46669f Content-Type: text/plain; charset=ISO-8859-1 Dear all, Alan Luchuk and I had prepared the following text to map a certificate to a NETCONF username. Moreover, if needed, we will add text on PSK authentication (see last section) Please don't hesitate to send your comments Best regards Badra 1) Generating NETCONF Usernames From NETCONF Client Certificates The NETCONF protocol [RFC6241] requires the transport protocol is responsible for authentication of the server to the client and authentication of the client to the server. TLS does this by exchanging and verifying the certficates presented by the peer. Additionally, the NETCONF protocol [RFC6241] requires the transport protocol's authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. Thus, an algorithm for mapping certificates to NETCONF usernames is required. The algorithm for mapping certificates to NETCONF usernames is patterned after the algorithm for mapping certificates to tmSecurityNames specified in Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) [RFC6353]. RFC6353 specifies that an SNMP agent must implement several algorithms for mapping a certificate to a tmSecurityName, and lets the agent deployer choose and configure the algorithm most suitable for the deployer's environment. The NETCONF server may map a certificate to a NETCONF username using any of the following algorithms: - Map a certificate directly to a NETCONF username; - Extract the subjectAltName's rfc822Name from the certificate and map this to a NETCONF username; - Extract the subjectAltName's dnsName from the certificate and map this to a NETCONF username; - Extract the subjectAltName's iPAddress from the certificate and map this to a NETCONF username; - Extract the subjectAltName's rfc822Name, dnsName, and iPAddress fields, and map the first matching subjectAltName value. The NETCONF server should implement all of these algorithms, and allow the deployer to choose and configure the algorithm used. How a NETCONF server is configured is implementation dependent. Although remote configuration might be useful, it is out-of-scope for this document. Conceptually, the configuration must include a means of identifying the certificate presented and the mapping algorithm. Additionally, when a certificate is mapped directly to a NETCONF username, the NETCONF username must be configurable. 2) Identifying a Certificate A client certificate has an identity: the certificate. The TLS and corresponding X.509 protocols provide an identity. The identity shows that "this client certificate has shown that it, indeed, is on the other side of the connection". With a complete certificate, the certificate receiver can be certain that for someone or something on the other side to use that certificate successfully, it has the associated private key. The problem with using the entire certificates as the identity is that it is difficult to use by people and software being configured. It is generally accepted that a fingerprint of a certificate is not likely to come up with a collision against a fingerprint of another (different) certificate. Thus, assuming a good hash algorithm, using fingerprints is a safe way to compare two certificates. How a NETCONF server identifies a certificate is implementation-dependent. It is suggested that the NETCONF server username configuration use certificate fingerprints as "likely unique index" into a mapping table. 3) Generating the NETCONF username from the subjectAltName's rfc822Name Maps a subjectAltName's rfc822Name to a NETCONF username. The local part of the rfc822Name is passed unaltered but the host-part of the name must be passed in lowercase. This mapping results in a 1:1 correspondence between equivalent subjectAltName rfc822Name values and NETCONF username values except that the host-part of the name MUST be passed in lowercase. Example rfc822Name Field: FooBar@Example.COM is mapped to NETCONF username: FooBar@example.com." 4) Generating the NETCONF username from the subjectAltName's dnsName DESCRIPTION "Maps a subjectAltName's dNSName to a NETCONF username after first converting it to all lowercase (RFC 5280 does not specify converting to lowercase so this involves an extra step). This mapping results in a 1:1 correspondence between subjectAltName dNSName values and the NETCONF username values." The subjectAltName's dNSName is mapped to a NETCONF usernames after first converting it to all lowercase (RFC 5280 does not specify these conversions, so this involves an extra step). This mapping results in a 1:1 correspondence between subjectAltName dNSName values and the NETCONF username values. REFERENCE RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. 5) Generating the NETCONF username from the subjectAltName's ipAddress The subjectAltName's iPAddress is mapped to a NETCONF username by transforming the binary encoded address as follows: a) for IPv4, the value is converted into a decimal-dotted quad address with dots replaced by underscore characters (e.g., '192.0.2.1') b) for IPv6 addresses, the value is converted into a 32-character all lowercase hexadecimal string without any colon separators. This mapping results in a 1:1 correspondence between subjectAltName iPAddress values and the NETCONF username values. 6) Generating the NETCONF username from any of the subjectAltName's rfc822Name, dNSName, or iPAddress Any of the subjectAltName fields rfc822Name, dNSName, or iPAddress are mapped to the NETCONF username using the corresponding mapping algorithms described above. The NETCONF server should allow the deployer to configure the order in which these subjectAltName fields are examined. For example, the NETCONF server should allow the deployer to configure that the subjectAltName fields be examined in any of following orders: o 1) rfc822Name, 2) dNSName, 3) iPAddress o 1) rfc822Name, 2) iPAddress, 3) dNSName o 1) dNSName, 2) iPAddress, 3) rfc822Name o 1) dNSName, 2) rfc822Name, 3) iPAddress o 1) iPAddress, 2) iPAddress, 3) rfc822Name o 1) iPAddress, 2) rfc822Name, 3) iPAddress When the certificate's ssubjectAltName fields are examined in the deployer-specified order, the first matching subjectAltName value found MUST be used when deriving the NETCONF username. The mapping algorithm specified in the previous sections MUST be used to derive the NETCONF username. This mapping results in a 1:1 correspondence between subjectAltName values and NETCONF username values. The three sub-mapping algorithms produced by this combined algorithm cannot produce conflicting results between themselves. 7) Selecting NETCONF Server Certificates From NETCONF Usernames When a NETCONF server must send a notification, the NETCONF server acts in a client role. When acting in a client role, the NETCONF server must also have a mechanism for transforming a NETCONF Username into a TLS certificate. The NETCONF server should map a NETCONF username directly to a certificate. The NETCONF server should allow the deployer to configure the mapping. How this is configured in a NETCONF server implementation dependent. Although remote configuration might be useful, it is out-of-scope for this document. 8) Generating the NETCONF username from any of the PSK Identity RFC 4279 describes pre-shared key cipher suites for TLS to support authentication based on pre-shared keys (PSKs). During the TLS Handshake, the client indicates which key to use by including a "PSK identity" in the TLS ClientKeyExchange message [RFC4279]. The PSK identity MUST be first converted to a character string, and then encoded to octets using UTF-8 [UTF8]. For instance, RFC4279 specifies encoding for three PSK identity types: o IPv4 addresses are sent as dotted-decimal strings (e.g., "192.0.2.1"), not as 32-bit integers in network byte order. o Domain names are sent in their usual text form [DNS] (e.g., "www.example.com" or "embedded\.dot.example.net"), not in DNS protocol format. o X.500 Distinguished Names are sent in their string representation [LDAPDN], not as BER-encoded ASN.1. The algorithm for mapping PSK identities to NETCONF usernames is trivial. It consists of extracting the PSK identity from the received ClientKeyExchange message and maps this to a NETCONF username. --bcaec502d79048fedf04af46669f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

Alan Luchuk and I had prepared the following text to ma= p a certificate to a NETCONF username.

Moreover, i= f needed, we will add text on=A0PSK authentication (see last section)

Please don't hesitate to send your comments

Best regards
Badra
=


1) Generating NETCONF Usernames From NETCONF Client Certificates

= =A0

= The NETCONF protocol [RFC6241] requires the transport protocol is

= responsible for authentication of the server to the client and

= authentication of the client to the server.=A0 TLS does this by

= exchanging and verifying the certficates presented by the peer.

= =A0

= Additionally, the NETCONF protocol [RFC6241] requires the

= transport protocol's authentication process MUST result in an

= authenticated client identity whose permissions are known to the

= server.=A0 The authenticated identity of a client is commonly

= referred to as the NETCONF username.=A0 Thus, an algorithm for

= mapping certificates to NETCONF usernames is required.

= =A0

= The algorithm for mapping certificates to NETCONF usernames is

= patterned after the algorithm for mapping certificates to

= tmSecurityNames specified in Transport Layer Security (TLS)

= Transport Model for the Simple Network Management Protocol (SNMP)

= [RFC6353].=A0 RFC6353 specifies that an SNMP agent must implement

= several algorithms for mapping a certificate to a tmSecurityName,

= and lets the agent deployer choose and configure the algorithm

= most suitable for the deployer's environment.

= =A0

= The NETCONF server may map a certificate to a NETCONF username

= using any of the following algorithms:

= =A0

= -=A0 Map a certificate directly to a NETCONF username;<= /p>

= =A0

= -=A0 Extract the subjectAltName's rfc822Name from the cert= ificate

= =A0 and map this to a NETCONF username;

= =A0

= -=A0 Extract the subjectAltName's dnsName from the certifi= cate

= =A0 and map this to a NETCONF username;

= =A0

= -=A0 Extract the subjectAltName's iPAddress from the certi= ficate

= =A0 and map this to a NETCONF username;

= =A0

= -=A0 Extract the subjectAltName's rfc822Name, dnsName, and= iPAddress

= =A0 fields, and map the first matching subjectAltName value.

= =A0

= The NETCONF server should implement all of these algorithms, and

= allow the deployer to choose and configure the algorithm used.

= How a NETCONF server is configured is implementation dependent.

= Although remote configuration might be useful, it is out-of-scope

= for this document.

= =A0

= Conceptually, the configuration must include a means of identifying

= the certificate presented and the mapping algorithm.=A0 Additionally,

= when a certificate is mapped directly to a NETCONF username, the

= NETCONF username must be configurable.

= =A0

= 2) Identifying a Certificate

= =A0

= A client certificate has an identity: the certificate.=A0 The TLS and

= corresponding X.509 protocols provide an identity.=A0 The identity

= shows that "this client certificate has shown that it, indeed, is on

= the other side of the connection".=A0 With a complete certificate,

= the certificate receiver can be certain that for someone or something

= on the other side to use that certificate successfully, it has the

= associated private key.

= =A0

= The problem with using the entire certificates as the identity is

= that it is difficult to use by people and software being configured.

= It is generally accepted that a fingerprint of a certificate is not

= likely to come up with a collision against a fingerprint of another

= (different) certificate.=A0 Thus, assuming a good hash algorithm, using

= fingerprints is a safe way to compare two certificates.

= =A0

= How a NETCONF server identifies a certificate is implementation-dependent.

= It is suggested that the NETCONF server username configuration use

= certificate fingerprints as "likely unique index" into a mapping table.

= =A0

= 3) Generating the NETCONF username from the subjectAltName's rfc822Name

= =A0

= Maps a subjectAltName's rfc822Name to a NETCONF username.=A0 The local part

= of the rfc822Name is passed unaltered but the host-part of the name must

= be passed in lowercase.=A0 This mapping results in a 1:1 corre= spondence

= between equivalent subjectAltName rfc822Name values and NETCONF username

= values except that the host-part of the name MUST be passed in lowercase.

= =A0

= Example rfc822Name Field:=A0 FooBar@Example.COM

= is mapped to NETCONF username: FooBar@example.com.&quo= t;

= =A0

= =A0

= 4) Generating the NETCONF username from the subjectAltName's dnsName

= =A0

= DESCRIPTION=A0 "Maps a subjectAltName's dNSName to a<= /span>

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NETCONF usern= ame after first converting it to all

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lowercase (RF= C 5280 does not specify converting to

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lowercase so = this involves an extra step).=A0 This

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mapping resul= ts in a 1:1 correspondence between

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 subjectAltNam= e dNSName values and the NETCONF username

= =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0= values."

= =A0

= The subjectAltName's dNSName is mapped to a NETCONF usernames after

= first converting it to all lowercase (RFC 5280 does not specify these

= conversions, so this involves an extra step).=A0 This mapping results in

= a 1:1 correspondence between subjectAltName dNSName values and the

= NETCONF username values.

= =A0

= REFERENCE RFC 5280 - Internet X.509 Public Key Infrastructure

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 C= ertificate and Certificate Revocation

= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 L= ist (CRL) Profile.

= =A0

= 5) Generating the NETCONF username from the subjectAltName's ipAddress

= =A0

= The subjectAltName's iPAddress is mapped to a NETCONF username by

= transforming the binary encoded address as follows:

= =A0

= a)=A0 for IPv4, the value is converted into a decimal-dotted quad address

= =A0=A0 with dots replaced by underscore characters (e.g., '= ;192.0.2.1')

= =A0

= b)=A0 for IPv6 addresses, the value is converted into a 32-character all

= =A0=A0 lowercase hexadecimal string without any colon separato= rs.

= =A0

= This mapping results in a 1:1 correspondence between subjectAltName

= iPAddress values and the NETCONF username values.

= =A0

= =A0

= 6) Generating the NETCONF username from any of the subjectAltName's

= =A0 rfc822Name, dNSName, or iPAddress

= =A0

= Any of the subjectAltName fields rfc822Name, dNSName, or iPAddress are

= mapped to the NETCONF username using the corresponding mapping algorithms

= described above.

= =A0

= The NETCONF server should allow the deployer to configure the order in

= which these subjectAltName fields are examined.=A0 For example, the

= NETCONF server should allow the deployer to configure that the

= subjectAltName fields be examined in any of following orders:

= =A0

= o=A0 1) rfc822Name,=A0 2) dNSName,=A0=A0=A0=A0 3) iPAddress

= =A0

= o=A0 1) rfc822Name,=A0 2) iPAddress,=A0=A0 3) dNSName

= =A0

= o=A0 1) dNSName,=A0=A0=A0=A0 2) iPAddress,=A0=A0 3) rfc822Name

= =A0

= o=A0 1) dNSName,=A0=A0=A0=A0 2) rfc822Name,=A0 3) iPAddress

= =A0

= o=A0 1) iPAddress,=A0=A0 2) iPAddress,=A0=A0 3) rfc822Name

= =A0

= o=A0 1) iPAddress,=A0=A0 2) rfc822Name,=A0 3) iPAddress

= =A0

= =A0

= When the certificate's ssubjectAltName fields are examined in the

= deployer-specified order, the first matching subjectAltName value

= found MUST be used when deriving the NETCONF username.=A0 The mapping

= algorithm specified in the previous sections MUST be used to derive

= the NETCONF username.

= =A0

= This mapping results in a 1:1 correspondence between subjectAltName

= values and NETCONF username values.=A0 The three sub-mapping algorithms

= produced by this combined algorithm cannot produce conflicting results

= between themselves.

= =A0

= 7) Selecting NETCONF Server Certificates From NETCONF Usernames

= =A0

= When a NETCONF server must send a notification, the NETCONF server

= acts in a client role.=A0 When acting in a client role, the NE= TCONF

= server must also have a mechanism for transforming a NETCONF Username

= into a TLS certificate.

= =A0

= The NETCONF server should map a NETCONF username directly to a

= certificate.=A0 The NETCONF server should allow the deployer to

= configure the mapping.=A0 How this is configured in a NETCONF = server

= implementation dependent.=A0 Although remote configuration might be

= useful, it is out-of-scope for this document.

= =A0

= 8) Generating the NETCONF username from any of the PSK Identity

= =A0

= RFC 4279 describes pre-shared key cipher suites for TLS to support=A0

authentication= based on pre-shared keys (PSKs).

= =A0

= During the TLS Handshake, the client indicates which key to use by=A0

including a "PSK= identity" in the TLS ClientKeyExchange message=A0

[RFC4279].

= =A0

= The PSK identity MUST be first converted to a character string, and=A0

then encoded to oct= ets using UTF-8 [UTF8]. For instance, RFC4279=A0

specifies encoding for three PSK= identity types:

= =A0

= =A0o=A0 IPv4 addresses are sent as dotted-decimal strings (e.g.,=A0

"192.0.2.1"), not a= s 32-bit integers in network byte order.

= =A0

= =A0o=A0 Domain names are sent in their usual text form [DNS] (e.g.,=A0

&= quot;www.example.com" or "= embedded\.dot.example.net"), no= t in DNS=A0=A0

protocol format.

= =A0

= =A0o=A0 X.500 Distinguished Names are sent in their string representation=A0=A0

=

= [LDAPDN], not as BER-encoded ASN.1.

= =A0

= The algorithm for mapping PSK identities to NETCONF usernames is=A0

= trivial. It consists of= extracting the PSK identity from the received=A0

ClientKeyExchange message and m= aps this to a NETCONF username.


--bcaec502d79048fedf04af46669f-- From randy_presuhn@mindspring.com Fri Oct 14 12:22:49 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484B221F8CD0 for ; Fri, 14 Oct 2011 12:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QGzXNwSuE55V for ; Fri, 14 Oct 2011 12:22:48 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7FD21F8CCC for ; Fri, 14 Oct 2011 12:22:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=I4tvvBiDHQHTBBeyXD31zt1l6ZlyOOgZc6UZxkeAWrOmw/8L1x3L/2XvOqURNSST; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.6] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1REnLB-0002Z2-0w for netconf@ietf.org; Fri, 14 Oct 2011 15:22:45 -0400 Message-ID: <010801cc8aa6$e5bee940$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Fri, 14 Oct 2011 12:24:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288e71a7c41e89819116170a2bc3bba7d59350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.6 Subject: Re: [Netconf] NETCONF over TLS: username X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:22:49 -0000 Hi - A few comments... > From: "Badra" > To: > Sent: Friday, October 14, 2011 11:26 AM > Subject: [Netconf] NETCONF over TLS: username ... > 1) Generating NETCONF Usernames From NETCONF Client Certificates > > The NETCONF protocol [RFC6241] requires the transport protocol is s/is/to be/ > responsible for authentication of the server to the client and > authentication of the client to the server. TLS does this by > exchanging and verifying the certficates presented by the peer. > > Additionally, the NETCONF protocol [RFC6241] requires the s/requires/requires that/ > transport protocol's authentication process MUST result in an > authenticated client identity whose permissions are known to the > server. The authenticated identity of a client is commonly > referred to as the NETCONF username. Thus, an algorithm for > mapping certificates to NETCONF usernames is required. s/required/needed/ > The algorithm for mapping certificates to NETCONF usernames is > patterned after the algorithm for mapping certificates to > tmSecurityNames specified in Transport Layer Security (TLS) > Transport Model for the Simple Network Management Protocol (SNMP) > [RFC6353]. RFC6353 specifies that an SNMP agent must implement s/agent/engine/ > several algorithms for mapping a certificate to a tmSecurityName, > and lets the agent deployer choose and configure the algorithm s/agent/SNMP engine/ > most suitable for the deployer's environment. > > The NETCONF server may map a certificate to a NETCONF username > using any of the following algorithms: > > - Map a certificate directly to a NETCONF username; > - Extract the subjectAltName's rfc822Name from the certificate > and map this to a NETCONF username; > - Extract the subjectAltName's dnsName from the certificate > and map this to a NETCONF username; > - Extract the subjectAltName's iPAddress from the certificate > and map this to a NETCONF username; > - Extract the subjectAltName's rfc822Name, dnsName, and iPAddress > fields, and map the first matching subjectAltName value. Just what is meant by "map" here? > The NETCONF server should implement all of these algorithms, and > allow the deployer to choose and configure the algorithm used. Is this a RFC 2119 SHOULD? If it is, I think from an interoperability perspective it would really need to be a MUST. Is it permitted for the server to employ multiple algorithms, using one or more fall-back algorithms if the first one tried fails? > How a NETCONF server is configured is implementation dependent. > Although remote configuration might be useful, it is out-of-scope > for this document. This is too ironic for words. > Conceptually, the configuration must include a means of identifying > the certificate presented and the mapping algorithm. Additionally, > when a certificate is mapped directly to a NETCONF username, the > NETCONF username must be configurable. I'm afraid I'm unable to make sense of this last sentence. Do you mean that the *mapping* needs to be configurable? > 2) Identifying a Certificate > A client certificate has an identity: the certificate. The TLS and > corresponding X.509 protocols provide an identity. The identity > shows that "this client certificate has shown that it, indeed, is on > the other side of the connection". With a complete certificate, > the certificate receiver can be certain that for someone or something > on the other side to use that certificate successfully, it has the > associated private key. > > The problem with using the entire certificates as the identity is > that it is difficult to use by people and software being configured. s/it is/they are/ s/to use by people/for people to use/ s/and software being configured// > It is generally accepted that a fingerprint of a certificate is not > likely to come up with a collision against a fingerprint of another > (different) certificate. Thus, assuming a good hash algorithm, using > fingerprints is a safe way to compare two certificates. > > How a NETCONF server identifies a certificate is implementation-dependent. > It is suggested that the NETCONF server username configuration use > certificate fingerprints as "likely unique index" into a mapping table. This seems like an internal implementation detail that would be inappropriate in a specification. > 3) Generating the NETCONF username from the subjectAltName's rfc822Name > > Maps a subjectAltName's rfc822Name to a NETCONF username. The local part > of the rfc822Name is passed unaltered but the host-part of the name must > be passed in lowercase. This mapping results in a 1:1 correspondence > between equivalent subjectAltName rfc822Name values and NETCONF username > values except that the host-part of the name MUST be passed in lowercase. Any interaction with IDNs? > Example rfc822Name Field: FooBar@Example.COM > is mapped to NETCONF username: FooBar@example.com." > > 4) Generating the NETCONF username from the subjectAltName's dnsName > > DESCRIPTION "Maps a subjectAltName's dNSName to a > NETCONF username after first converting it to all > lowercase (RFC 5280 does not specify converting to > lowercase so this involves an extra step). This > mapping results in a 1:1 correspondence between > subjectAltName dNSName values and the NETCONF username > values." > > The subjectAltName's dNSName is mapped to a NETCONF usernames after > first converting it to all lowercase (RFC 5280 does not specify these > conversions, so this involves an extra step). This mapping results in > a 1:1 correspondence between subjectAltName dNSName values and the > NETCONF username values. > > REFERENCE RFC 5280 - Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation > List (CRL) Profile. > > 5) Generating the NETCONF username from the subjectAltName's ipAddress > The subjectAltName's iPAddress is mapped to a NETCONF username by > transforming the binary encoded address as follows: > > a) for IPv4, the value is converted into a decimal-dotted quad address > with dots replaced by underscore characters (e.g., '192.0.2.1') Uh, the example doesn't match the description here. Did you mean "192_0_2_1"? > b) for IPv6 addresses, the value is converted into a 32-character all > lowercase hexadecimal string without any colon separators. > > This mapping results in a 1:1 correspondence between subjectAltName > iPAddress values and the NETCONF username values. > > 6) Generating the NETCONF username from any of the subjectAltName's > rfc822Name, dNSName, or iPAddress > > Any of the subjectAltName fields rfc822Name, dNSName, or iPAddress are > mapped to the NETCONF username using the corresponding mapping algorithms > described above. > > > The NETCONF server should allow the deployer to configure the order in > which these subjectAltName fields are examined. For example, the > NETCONF server should allow the deployer to configure that the > subjectAltName fields be examined in any of following orders: > o 1) rfc822Name, 2) dNSName, 3) iPAddress > o 1) rfc822Name, 2) iPAddress, 3) dNSName > o 1) dNSName, 2) iPAddress, 3) rfc822Name > o 1) dNSName, 2) rfc822Name, 3) iPAddress > o 1) iPAddress, 2) iPAddress, 3) rfc822Name > o 1) iPAddress, 2) rfc822Name, 3) iPAddress > > When the certificate's ssubjectAltName fields are examined in the > deployer-specified order, the first matching subjectAltName value > found MUST be used when deriving the NETCONF username. The mapping > algorithm specified in the previous sections MUST be used to derive > the NETCONF username. Does the deployer have the option of prohibiting a particular mapping / field from being used? > This mapping results in a 1:1 correspondence between subjectAltName > values and NETCONF username values. The three sub-mapping algorithms > produced by this combined algorithm cannot produce conflicting results > between themselves. > > 7) Selecting NETCONF Server Certificates From NETCONF Usernames > When a NETCONF server must send a notification, the NETCONF server > acts in a client role. When acting in a client role, the NETCONF > server must also have a mechanism for transforming a NETCONF Username > into a TLS certificate. > > The NETCONF server should map a NETCONF username directly to a > certificate. The NETCONF server should allow the deployer to > configure the mapping. How this is configured in a NETCONF server > implementation dependent. Although remote configuration might be > useful, it is out-of-scope for this document. :-) > 8) Generating the NETCONF username from any of the PSK Identity > RFC 4279 describes pre-shared key cipher suites for TLS to support > authentication based on pre-shared keys (PSKs). > During the TLS Handshake, the client indicates which key to use by > including a "PSK identity" in the TLS ClientKeyExchange message > [RFC4279]. > > The PSK identity MUST be first converted to a character string, and > then encoded to octets using UTF-8 [UTF8]. For instance, RFC4279 > specifies encoding for three PSK identity types: > > o IPv4 addresses are sent as dotted-decimal strings (e.g., > "192.0.2.1"), not as 32-bit integers in network byte order. > > o Domain names are sent in their usual text form [DNS] (e.g., > "www.example.com" or "embedded\.dot.example.net"), not in DNS > protocol format. > > o X.500 Distinguished Names are sent in their string representation > [LDAPDN], not as BER-encoded ASN.1. > > The algorithm for mapping PSK identities to NETCONF usernames is > trivial. It consists of extracting the PSK identity from the received > ClientKeyExchange message and maps this to a NETCONF username. ... Randy From j.schoenwaelder@jacobs-university.de Fri Oct 14 13:46:31 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDA721F8D01 for ; Fri, 14 Oct 2011 13:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 tpYRTEZwZ77f for ; Fri, 14 Oct 2011 13:46:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E443A21F8B76 for ; Fri, 14 Oct 2011 13:46:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D01EC20E41; Fri, 14 Oct 2011 22:46:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IHkxmAaiSiKf; Fri, 14 Oct 2011 22:46:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FE5920E3F; Fri, 14 Oct 2011 22:46:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7105E1B24B67; Fri, 14 Oct 2011 22:46:14 +0200 (CEST) Date: Fri, 14 Oct 2011 22:46:13 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20111014204613.GA32550@elstar.local> Mail-Followup-To: Badra , netconf@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF over TLS: username X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 20:46:31 -0000 On Fri, Oct 14, 2011 at 08:26:45PM +0200, Badra wrote: > The PSK identity MUST be first converted to a character string, and > then encoded to octets using UTF-8 [UTF8]. For instance, RFC4279 > specifies encoding for three PSK identity types: > > o IPv4 addresses are sent as dotted-decimal strings (e.g., > "192.0.2.1"), not as 32-bit integers in network byte order. > > o Domain names are sent in their usual text form [DNS] (e.g., > "www.example.com" or "embedded\.dot.example.net"), not in DNS > protocol format. > > o X.500 Distinguished Names are sent in their string representation > [LDAPDN], not as BER-encoded ASN.1. This text seems to be copied from RFC 4279. I think we should instead simply refer to section 5.1. of RFC 4279 for the encoding of the PSK identity. Having MUSTs spelled out in multiple places causes document update pain. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tomoyuki.iijima.fg@hitachi.com Sun Oct 16 17:30:54 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0121F8538 for ; Sun, 16 Oct 2011 17:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MISSING_HEADERS=1.292, 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 qwXJY1GQuout for ; Sun, 16 Oct 2011 17:30:54 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 31A0E21F84DD for ; Sun, 16 Oct 2011 17:30:53 -0700 (PDT) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 9AF7737AC5 for ; Mon, 17 Oct 2011 09:30:51 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id p9H0UpMW013211; Mon, 17 Oct 2011 09:30:51 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p9H0Uot7007830 for ; Mon, 17 Oct 2011 09:30:51 +0900 X-AuditID: b753bd60-9f483ba000000655-19-4e9b773aa7da Received: from gmml28.itg.hitachi.co.jp (unknown [158.213.165.131]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 961A9774266 for ; Mon, 17 Oct 2011 09:30:50 +0900 (JST) Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p9H0UmM1503352; Mon, 17 Oct 2011 09:30:48 +0900 Message-ID: <4E9B7738.2030508@hitachi.com> Date: Mon, 17 Oct 2011 09:30:48 +0900 From: Tomoyuki Iijima User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 Cc: netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6402CCCE74@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6402CCCE74@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Draft Agenda for NETCONF WG Session in IETF 82 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 00:30:54 -0000 Dear Mehmet and Bert, > If there is any proposal to discuss please send us your proposal ASAP, > otherwise we will ask for a shorter session. Thanks. I'm going to resubmit "NETCONF over WebSocket" I-D this week updated according to my experiment. I'd appreciate it if you could put it on the agenda, though it might be a 5-10 minutes presentation. Kind regards, (2011/10/15 1:57), Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > this is the draft agenda for the NETCONF session in IETF 82 so far. > Looks a bit thin for a two hours session. > > If there is any proposal to discuss please send us your proposal ASAP, > otherwise we will ask for a shorter session. Thanks. > > Mehmet& Bert > > Agenda for NETCONF WG Session > -------------------------------------- > > IETF 82 - Taipei, Taiwan > November 13-18, 2011 > > MONDAY, November 14, 2011 > 1300-1500, Afternoon Session I > Room: 101D > > > WG Chairs: > Bert Wijnen > Mehmet Ersue > > Scribes (IF no_volunteers THEN wait_forever) > Agenda bashing (2 minutes) > WG status review (5 minutes) > > Chartered items: > > 1. Network Configuration Protocol Access Control Model - A. > Bierman (?? min.) > http://tools.ietf.org/html/draft-ietf-netconf-access-control > 2. NETCONF System Notifications - A. Bierman (?? min.) > > http://tools.ietf.org/html/draft-ietf-netconf-system-notification > > Non-chartered items: > > . . . > Open mike: > . . . > Any topics to discuss? > > AOB > > > Cheers, > Mehmet > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From mehmet.ersue@nsn.com Mon Oct 17 05:32:35 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B17621F8AD8 for ; Mon, 17 Oct 2011 05:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 kFAqy-LioTyW for ; Mon, 17 Oct 2011 05:32:34 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 08C6521F8ACC for ; Mon, 17 Oct 2011 05:32:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9HCWWoU016507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Oct 2011 14:32:32 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9HCWUEr017896 for ; Mon, 17 Oct 2011 14:32:32 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 14:32:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2011 14:32:22 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402D1B982@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6402CCCE74@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for NETCONF WG Session in IETF 82 Thread-Index: AcyKfqxhj4rSw/evRa+NbOi3TCkJFgAEpd6wAI3OpTA= References: <80A0822C5E9A4440A5117C2F4CD36A6402CCCE74@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Oct 2011 12:32:23.0280 (UTC) FILETIME=[D2145F00:01CC8CC8] Subject: Re: [Netconf] Draft Agenda for NETCONF WG Session in IETF 82 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 12:32:35 -0000 Hi All, below is the updated draft agenda for the NETCONF session. Please state by October 19, 2011, if you have additional=20 topics or think a 1-hour-session would be insufficient. Mehmet & Bert (Draft) Agenda for NETCONF WG Session ----------------------------- IETF 82 - Taipei, Taiwan November 13-18, 2011 MONDAY, November 14, 2011 1300-1500, Afternoon Session I Room: 101D WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. Network Configuration Protocol Access Control Model - Andy Bierman (20 min.)=20 http://tools.ietf.org/html/draft-ietf-netconf-access-control 2. NETCONF System Notifications - Andy Bierman (10 min.)=20 =20 http://tools.ietf.org/html/draft-ietf-netconf-system-notification Non-chartered items: 1. NETCONF over TLS update - Juergen Schoenwaelder (15 min). 2. NETCONF over WebSocket - Tomoyuki Iijima (10 min). Open mike: . . . AOB > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > Ersue, Mehmet (NSN - DE/Munich) > Sent: Friday, October 14, 2011 6:57 PM > To: netconf@ietf.org > Subject: [Netconf] Draft Agenda for NETCONF WG Session in IETF 82 >=20 > Dear NETCONF WG, >=20 > this is the draft agenda for the NETCONF session in IETF 82 so far. > Looks a bit thin for a two hours session. >=20 > If there is any proposal to discuss please send us your proposal ASAP, > otherwise we will ask for a shorter session. Thanks. >=20 > Mehmet & Bert >=20 > Agenda for NETCONF WG Session > -------------------------------------- From luchuk@snmp.com Mon Oct 17 07:19:08 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3890821F8B7B for ; Mon, 17 Oct 2011 07:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1PFhrjOPMfXd for ; Mon, 17 Oct 2011 07:19:07 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA2521F8B67 for ; Mon, 17 Oct 2011 07:19:07 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA04597; Mon, 17 Oct 2011 10:19:04 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id KAA02819; Mon, 17 Oct 2011 10:18:59 -0400 (EDT) Date: Mon, 17 Oct 2011 10:18:59 -0400 (EDT) From: Alan Luchuk Message-Id: <201110171418.KAA02819@adminfs.snmp.com> To: randy_presuhn@mindspring.com Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF over TLS: username X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:19:08 -0000 Hello, >A few comments... > >> 1) Generating NETCONF Usernames From NETCONF Client Certificates >> >> The NETCONF protocol [RFC6241] requires the transport protocol is > >s/is/to be/ ...text deleted... Thanks for the detailed comments! We'll review them carefully, update the proposed text, and send the updated text out for another round of comments. Best regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From ietfc@btconnect.com Thu Oct 20 09:39:50 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4235D21F8CE6 for ; Thu, 20 Oct 2011 09:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 pEM8QtVWbx8a for ; Thu, 20 Oct 2011 09:39:49 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id D27C321F8CE4 for ; Thu, 20 Oct 2011 09:39:48 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr08.btconnect.com with SMTP id ETW93613; Thu, 20 Oct 2011 17:39:41 +0100 (BST) Message-ID: <00e401cc8f3d$cd3e7020$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Badra" , References: Date: Thu, 20 Oct 2011 14:58:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4EA04ECD.0055, actions=tag X-Junkmail-Premium-Raw: score=11/50, refid=2.7.2:2011.10.20.153620:17:11.920, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DATE_IN_PAST_03_06, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __PHISH_SPEAR_ACCOUNT_1, BODY_SIZE_10000_PLUS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL X-Junkmail-Status: score=11/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4EA04ED2.008C,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [Netconf] NETCONF over TLS: username X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:39:50 -0000 It does seem to me that we are trying to fit some square pegs into a round hole (just as we did with isms). Meanwhile, sidr has a need to issue all routers (that originate paths) with certificates and is specifying just that, expecting all RIR, LIR, ISP - most, if not all, significant networks - to become Certificate Authorities and to issue suitable End-Entity certificates to routers and others. These certificates will be suitable for routers, with fields to identify them and their properties. Do I see a faint parallel with netconf (or snmp or any operational protocol)? This protocol, like others, is primarily for use with an administrative domain, not world-wide, so a certificate, be it for client or for server, needs to uniquely identify the end point within the domain, so an employee number, perhaps employee name, a box name or box serial number, coupled with the identifier of the administrative domain, perhaps implicit in the Certificate Authority, provides a suitable identifer. (Well, if not, blame the Certificate Authority, they chose it:-). All we need is a profile to specify that. It seems to me we have the tools to solve the problem but just are not using them. The profile for router certificates is in A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests draft-turner-sidr-bgpsec-pki-profiles-02 which sidr just failed to adopt as a WG document, but that was purely a procedural error; the chair has her whip out:-) Tom Petch ----- Original Message ----- From: "Badra" To: Sent: Friday, October 14, 2011 8:26 PM Subject: [Netconf] NETCONF over TLS: username > Dear all, > > Alan Luchuk and I had prepared the following text to map a certificate to a > NETCONF username. > > Moreover, if needed, we will add text on PSK authentication (see last > section) > > Please don't hesitate to send your comments > > Best regards > Badra > > > 1) Generating NETCONF Usernames From NETCONF Client Certificates > > > > The NETCONF protocol [RFC6241] requires the transport protocol is > > responsible for authentication of the server to the client and > > authentication of the client to the server. TLS does this by > > exchanging and verifying the certficates presented by the peer. > > > > Additionally, the NETCONF protocol [RFC6241] requires the > > transport protocol's authentication process MUST result in an > > authenticated client identity whose permissions are known to the > > server. The authenticated identity of a client is commonly > > referred to as the NETCONF username. Thus, an algorithm for > > mapping certificates to NETCONF usernames is required. > > > > The algorithm for mapping certificates to NETCONF usernames is > > patterned after the algorithm for mapping certificates to > > tmSecurityNames specified in Transport Layer Security (TLS) > > Transport Model for the Simple Network Management Protocol (SNMP) > > [RFC6353]. RFC6353 specifies that an SNMP agent must implement > > several algorithms for mapping a certificate to a tmSecurityName, > > and lets the agent deployer choose and configure the algorithm > > most suitable for the deployer's environment. > > > > The NETCONF server may map a certificate to a NETCONF username > > using any of the following algorithms: > > > > - Map a certificate directly to a NETCONF username; > > > > - Extract the subjectAltName's rfc822Name from the certificate > > and map this to a NETCONF username; > > > > - Extract the subjectAltName's dnsName from the certificate > > and map this to a NETCONF username; > > > > - Extract the subjectAltName's iPAddress from the certificate > > and map this to a NETCONF username; > > > > - Extract the subjectAltName's rfc822Name, dnsName, and iPAddress > > fields, and map the first matching subjectAltName value. > > > > The NETCONF server should implement all of these algorithms, and > > allow the deployer to choose and configure the algorithm used. > > How a NETCONF server is configured is implementation dependent. > > Although remote configuration might be useful, it is out-of-scope > > for this document. > > > > Conceptually, the configuration must include a means of identifying > > the certificate presented and the mapping algorithm. Additionally, > > when a certificate is mapped directly to a NETCONF username, the > > NETCONF username must be configurable. > > > > 2) Identifying a Certificate > > > > A client certificate has an identity: the certificate. The TLS and > > corresponding X.509 protocols provide an identity. The identity > > shows that "this client certificate has shown that it, indeed, is on > > the other side of the connection". With a complete certificate, > > the certificate receiver can be certain that for someone or something > > on the other side to use that certificate successfully, it has the > > associated private key. > > > > The problem with using the entire certificates as the identity is > > that it is difficult to use by people and software being configured. > > It is generally accepted that a fingerprint of a certificate is not > > likely to come up with a collision against a fingerprint of another > > (different) certificate. Thus, assuming a good hash algorithm, using > > fingerprints is a safe way to compare two certificates. > > > > How a NETCONF server identifies a certificate is implementation-dependent. > > It is suggested that the NETCONF server username configuration use > > certificate fingerprints as "likely unique index" into a mapping table. > > > > 3) Generating the NETCONF username from the subjectAltName's rfc822Name > > > > Maps a subjectAltName's rfc822Name to a NETCONF username. The local part > > of the rfc822Name is passed unaltered but the host-part of the name must > > be passed in lowercase. This mapping results in a 1:1 correspondence > > between equivalent subjectAltName rfc822Name values and NETCONF username > > values except that the host-part of the name MUST be passed in lowercase. > > > > Example rfc822Name Field: FooBar@Example.COM > > is mapped to NETCONF username: FooBar@example.com." > > > > > > 4) Generating the NETCONF username from the subjectAltName's dnsName > > > > DESCRIPTION "Maps a subjectAltName's dNSName to a > > NETCONF username after first converting it to all > > lowercase (RFC 5280 does not specify converting to > > lowercase so this involves an extra step). This > > mapping results in a 1:1 correspondence between > > subjectAltName dNSName values and the NETCONF username > > values." > > > > The subjectAltName's dNSName is mapped to a NETCONF usernames after > > first converting it to all lowercase (RFC 5280 does not specify these > > conversions, so this involves an extra step). This mapping results in > > a 1:1 correspondence between subjectAltName dNSName values and the > > NETCONF username values. > > > > REFERENCE RFC 5280 - Internet X.509 Public Key Infrastructure > > Certificate and Certificate Revocation > > List (CRL) Profile. > > > > 5) Generating the NETCONF username from the subjectAltName's ipAddress > > > > The subjectAltName's iPAddress is mapped to a NETCONF username by > > transforming the binary encoded address as follows: > > > > a) for IPv4, the value is converted into a decimal-dotted quad address > > with dots replaced by underscore characters (e.g., '192.0.2.1') > > > > b) for IPv6 addresses, the value is converted into a 32-character all > > lowercase hexadecimal string without any colon separators. > > > > This mapping results in a 1:1 correspondence between subjectAltName > > iPAddress values and the NETCONF username values. > > > > > > 6) Generating the NETCONF username from any of the subjectAltName's > > rfc822Name, dNSName, or iPAddress > > > > Any of the subjectAltName fields rfc822Name, dNSName, or iPAddress are > > mapped to the NETCONF username using the corresponding mapping algorithms > > described above. > > > > The NETCONF server should allow the deployer to configure the order in > > which these subjectAltName fields are examined. For example, the > > NETCONF server should allow the deployer to configure that the > > subjectAltName fields be examined in any of following orders: > > > > o 1) rfc822Name, 2) dNSName, 3) iPAddress > > > > o 1) rfc822Name, 2) iPAddress, 3) dNSName > > > > o 1) dNSName, 2) iPAddress, 3) rfc822Name > > > > o 1) dNSName, 2) rfc822Name, 3) iPAddress > > > > o 1) iPAddress, 2) iPAddress, 3) rfc822Name > > > > o 1) iPAddress, 2) rfc822Name, 3) iPAddress > > > > > > When the certificate's ssubjectAltName fields are examined in the > > deployer-specified order, the first matching subjectAltName value > > found MUST be used when deriving the NETCONF username. The mapping > > algorithm specified in the previous sections MUST be used to derive > > the NETCONF username. > > > > This mapping results in a 1:1 correspondence between subjectAltName > > values and NETCONF username values. The three sub-mapping algorithms > > produced by this combined algorithm cannot produce conflicting results > > between themselves. > > > > 7) Selecting NETCONF Server Certificates From NETCONF Usernames > > > > When a NETCONF server must send a notification, the NETCONF server > > acts in a client role. When acting in a client role, the NETCONF > > server must also have a mechanism for transforming a NETCONF Username > > into a TLS certificate. > > > > The NETCONF server should map a NETCONF username directly to a > > certificate. The NETCONF server should allow the deployer to > > configure the mapping. How this is configured in a NETCONF server > > implementation dependent. Although remote configuration might be > > useful, it is out-of-scope for this document. > > > > 8) Generating the NETCONF username from any of the PSK Identity > > > > RFC 4279 describes pre-shared key cipher suites for TLS to support > > authentication based on pre-shared keys (PSKs). > > > > During the TLS Handshake, the client indicates which key to use by > > including a "PSK identity" in the TLS ClientKeyExchange message > > [RFC4279]. > > > > The PSK identity MUST be first converted to a character string, and > > then encoded to octets using UTF-8 [UTF8]. For instance, RFC4279 > > specifies encoding for three PSK identity types: > > > > o IPv4 addresses are sent as dotted-decimal strings (e.g., > > "192.0.2.1"), not as 32-bit integers in network byte order. > > > > o Domain names are sent in their usual text form [DNS] (e.g., > > "www.example.com" or "embedded\.dot.example.net"), not in DNS > > protocol format. > > > > o X.500 Distinguished Names are sent in their string representation > > [LDAPDN], not as BER-encoded ASN.1. > > > > The algorithm for mapping PSK identities to NETCONF usernames is > > trivial. It consists of extracting the PSK identity from the received > > ClientKeyExchange message and maps this to a NETCONF username. > > From j.schoenwaelder@jacobs-university.de Fri Oct 21 02:26:11 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B931721F8B28 for ; Fri, 21 Oct 2011 02:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 7-HQWQsJZVTq for ; Fri, 21 Oct 2011 02:26:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A0A2D21F88AB for ; Fri, 21 Oct 2011 02:26:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D568D20C87; Fri, 21 Oct 2011 11:26:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id c20aI8og4EUR; Fri, 21 Oct 2011 11:26:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5143820C8C; Fri, 21 Oct 2011 11:26:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 121B11B31C2C; Fri, 21 Oct 2011 11:25:52 +0200 (CEST) Date: Fri, 21 Oct 2011 11:25:52 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20111021092552.GB6530@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , netconf References: <4E8D94F1.1070705@bwijnen.net> <4E97E362.4070102@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E97E362.4070102@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:26:11 -0000 On Fri, Oct 14, 2011 at 09:23:14AM +0200, Bert Wijnen (IETF) wrote: > Gentle reminder! > > Please do review and post your comments/questions/support/objections > by Friday 21st of October. > > We explicitly ask you to ALSO let us know if you have read and > support or agree with the document. I have read the -05 version of NACM and it has significantly improved since the last version I reviewed. A great job done by the editors and I think the document is basically ready to go. I only have some nits and a clarification question / suggestion. A clarification question: My understanding of the document is that a user who is member of two groups (say A and B) with conflicting access control rule lists (say R1 of group A allows access to foo while R2 of group B denies access to foo) will either be allowed to access foo or denied access depending on the order of the rule lists. If R1 is before R2, then R1 matches and access is allowed. If R2 is before R1, then R2 matches and access is denied. Is my understanding correct? If yes, then there should perhaps be a hint in the security considerations that changing order of rules and rule lists can have significant impact on the access rights granted. Nits: - s/rules are editing directly/rules are edited directly/ - "NACM requires some a user name in each NACM group mapping." Despite the construction of the sentence, it is not even clear what the intended meaning was. I think the yang model allows a group with an empty leaf-list of users. - s/"path-stmt" values/"path-stmt" values)/ - s/ot it may/or it may/ - s/. entry/ entry/ - s/. entries/ entries/ - What is the "mod-3" rule refered to at the end of A.4? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From luchuk@snmp.com Fri Oct 21 07:47:17 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5CD21F8BE4 for ; Fri, 21 Oct 2011 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 loxHpCSGPirO for ; Fri, 21 Oct 2011 07:47:16 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5D621F8BDE for ; Fri, 21 Oct 2011 07:47:15 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA12279; Fri, 21 Oct 2011 10:47:13 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id KAA23003; Fri, 21 Oct 2011 10:47:12 -0400 (EDT) Date: Fri, 21 Oct 2011 10:47:12 -0400 (EDT) From: Alan Luchuk Message-Id: <201110211447.KAA23003@adminfs.snmp.com> To: netconf@ietf.org Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:47:17 -0000 Hello, Here is the latest proposed text for an update to RFC 5539 for deriving NETCONF usernames when using NETCONF over TLS. Thanks to all who commented on earlier version(s) of this text. Much of the text in the earlier draft has been replaced by a YANG module in this draft. This YANG module heavily borrows ideas and text from the SNMP-TLS-TM-MIB from RFC 6353. The description text in the YANG module should be more concise and clear than the deleted text. Hopefully this lastest proposal will be a more useful starting point for discussions about deriving NETCONF usernames when using TLS. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ Deriving NETCONF Usernames From NETCONF Client Certificates ----------------------------------------------------------- The NETCONF protocol [RFC6241] requires the transport protocol to be responsible for authentication of the server to the client and authentication of the client to the server. TLS does this by exchanging and verifying the certficates presented by the peer. Additionally, the NETCONF protocol [RFC6241] requires that the transport protocol's authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. Thus, an algorithm for transforming certificates to NETCONF usernames is needed. The algorithm for deriving NETCONF usernames from TLS certificates is patterned after the algorithm for deriving tmSecurityNames from TLS certificates specified in Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) [RFC6353]. RFC6353 specifies that an SNMP engine must implement several algorithms for transforming a certificate to a tmSecurityName, and lets the SNMP engine deployer choose and configure the algorithm most suitable for the deployer's environment. When a NETCONF server accepts a TLS connection from a NETCONF client, the NETCONF server must produce a NETCONF username from the certificate presented by the NETCONF client. The NETCONF server may use any of the following algorithms to produce the NETCONF username from the certificate presented by the NETCONF client: - Map a certificate directly to a NETCONF username; - Extract the subjectAltName's rfc822Name from the certificate, then use the extracted rfc822Name as the NETCONF username; - Extract the subjectAltName's dnsName from the certificate, then use the extracted dnsName as the NETCONF username; - Extract the subjectAltName's iPAddress from the certificate, then use the extracted iPAddress as the NETCONF username; - Examine the subjectAltName's rfc822Name, dnsName, and iPAddress fields in a pre-defined order, then use the first matching subjectAltName value. The NETCONF server MUST implement all of these algorithms, and allow the deployer to choose and configure the algorithm used. The certificate-to-username-transforms container in the ietf-netconf-tls-username YANG module specifies how a NETCONF server transforms an certificate into a NETCONF username. Identifying a Certificate ------------------------- A client certificate has an identity: the certificate. The TLS and corresponding protocols provide an identity. The identity shows that "this client certificate has shown that it, indeed, is on the other side of the connection". With a complete certificate, the certificate receiver can be certain that for someone or something on the other side to use that certificate successfully, it has the associated private key. The problem with using the entire certificates as the identity is that they are difficult for people to use. It is generally accepted that a fingerprint of a certificate is not likely to come up with a collision against a fingerprint of another (different) certificate. Thus, assuming a good hash algorithm, using fingerprints is a safe way to compare two certificates. If if a locally held copy of a trusted CA certificate is configured in the transformation container, and that CA certificate was used to validate the path to the presented certificate, then the NETCONF server should use that list entry in the transformation container. All presented certificates validated by the configured CA certificate will be transformed to NETCONF usernames using the same transformation algorithm. Remote Configuration -------------------- The ietf-netconf-tls-username YANG module defines objects for remotely configuring the mapping of TLS certficates to NETCONF usernames. module ietf-netconf-tls-username { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-tls-username"; prefix "tls-username"; import ietf-yang-types { prefix yang; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Mehmet Ersue WG Chair: Bert Wijnen Editor: Badra "; description "This module applies to NETCONF over TLS. It specifies how NETCONF servers transform X.509 certificates presented by clients into NETCONF usernames. It also specifies how NETCONF clients transform NETCONF usernames into X.509 certificates for presentation to NETCONF servers. This YANG module is patterned after, and closely models, parts of the SNMP-TLS-TM-MIB defined in RFC 6353. Much of the description text has been copied directly from the SNMP-TLS-TM-MIB, and modified as necessary. Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and // remove this note // RFC Ed.: please update the date to the date of publication revision "2011-10-17" { description "Initial version"; reference "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; } typedef tls-fingerprint-type { type binary { length "0..255"; } description "A fingerprint value that can be used to uniquely reference other data of potentially arbitrary length. An tls-fingerprint-type value is composed of a 1-octet hashing algorithm identifier followed by the fingerprint value. The octet value encoded is taken from the IANA TLS HashAlgorithm Registry (RFC 5246). The remaining octets are filled using the results of the hashing algorithm. This typedef allows for a zero-length (blank) tls-fingerprint-type value for use in containers where the fingerprint value may be optional. YANG definitions or implementations may refuse to accept a zero-length value as appropriate."; } // // Objects related to deriving NETCONF usernames from X.509 certificates. // leaf certificate-to-username-transform-count { type yang:gauge32; description "A count of the number of certificate-to-username-transforms."; config false; } leaf certificate-to-username-transform-last-changed { type yang:date-and-time; description "The date and time when the certificate-to-username-transforms was last modified through any means. The value 0 means the certificate-to-username-transforms has not been modified since the NETCONF server was started."; config false; } container certificate-to-username-transforms { config true; description "This container is used by a NETCONF server to map the NETCONF client's presented X.509 certificate to a NETCONF username. On an incoming TLS connection, the client's presented certificate must either be validated based on an established trust anchor, or it must directly match a fingerprint in this container. This container does not provide any mechanisms for configuring the trust anchors; the transfer of any needed trusted certificates for path validation is expected to occur through an out-of-band transfer. Once the certificate has been found acceptable (either by path validation or directly matching a fingerprint in this container), this container is consulted to determine the appropriate NETCONF username to identify with the remote connection. This is done by considering each active list entry from this container in prioritized order according to its index value. Each list entry's certificate-fingerprint value determines whether the list entry is a match for the incoming connection: 1) If the list entry's certificate-fingerprint value identifies the presented certificate, then consider the list entry as a successful match. 2) If the list entry's certificate-fingerprint value identifies a locally held copy of a trusted CA certificate and that CA certificate was used to validate the path to the presented certificate, then consider the list entry as a successful match. Once a matching list entry has been found, the NETCONF server uses the map-type value to determine how the NETCONF username associated with the session should be determined. See the map-type column's description for details on determining the NETCONF username value. If it is impossible to determine a NETCONF username from the list entry's data combined with the data presented in the certificate, then additional list entries MUST be searched looking for another potential match. If a resulting NETCONF username mapped from a given list entry is not compatible with the needed requirements of a NETCONF username, then it must be considered an invalid match and additional list entries MUST be searched looking for another potential match. If no matching and valid list entry can be found, the connection MUST be closed and NETCONF messages MUST NOT be accepted over it. Missing values of index are acceptable and implementations should continue to the next highest numbered list entry. It is recommended that administrators skip index values to leave room for the insertion of future list entries (for example, use values of 10 and 20 when creating initial list entries). Users are encouraged to make use of certificates with subjectAltName fields that can be used as NETCONF usernames so that a single root CA certificate can allow all child certificate's subjectAltName to map directly to a NETCONF usernames via a 1:1 transformation. However, this container is flexible to allow for situations where existing deployed certificate infrastructures do not provide adequate subjectAltName values for use as NETCONF usernames."; // Certificates may also be mapped to NETCONF usernames using the // CommonName portion of the Subject field. However, the usage // of the CommonName field is deprecated and thus this usage is // NOT RECOMMENDED. Direct mapping from each individual // certificate fingerprint to a NETCONF username is also possible // but requires one entry in the container per NETCONF username and // requires more management operations to completely configure a // device."; list certificate-to-username-transform { key "index"; description "A single list entry that specifies a mapping for an incoming TLS certificate to a NETCONF username."; leaf index { type uint32 { range "1..4294967295"; } description "A unique, prioritized index for the given entry. Lower numbers indicate a higher priority."; } leaf certificate-fingerprint { type tls-fingerprint-type { length "1..255"; } description "A cryptographic hash of a X.509 certificate. The results of a successful matching fingerprint to either the trusted CA in the certificate validation path or to the certificate itself is dictated by the map-type column."; } leaf map-type { type enumeration { enum specified { value 1; } enum rfc822Name { value 2; } enum dnsName { value 3; } enum ipAddress { value 4; } enum rfc822Name-dnsName-ipAddress { value 5; } enum rfc822Name-ipAddress-dnsName { value 6; } enum dnsName-ipAddress-rfc822Name { value 7; } enum dnsName-rfc822Name-ipAddress { value 8; } enum ipAddress-dnsName-rfc822Name { value 9; } enum ipAddress-rfc822Name-dnsName { value 10; } } description "Specifies the algorithm for deriving a NETCONF username from a certificate. If a mapping succeeds, then it will return a NETCONF username. If the resulting mapped value is not compatible with the needed requirements of a NETCONF username, then future list entries MUST be searched for additional NETCONF username matches to look for a mapping that succeeds. For each enumerated value listed above, the NETCONF server derives the NETCONF from the presented client certificate as described: specified Directly specifies the NETCONF username to be used for this certificate. The value of the NETCONF username to use is specified in the data leaf of the list. The data leaf must contain a non-zero length value or the mapping described in this list entry must be considered a failure. rfc822Name Maps a subjectAltName's rfc822Name to a NETCONF username. The local part of the rfc822Name is passed unaltered but the host-part of the name must be passed in lowercase. This mapping results in a 1:1 correspondence between equivalent subjectAltName rfc822Name values and NETCONF username values except that the host-part of the name MUST be passed in lowercase. Example rfc822Name Field: FooBar@Example.COM is mapped to NETCONF username: FooBar@example.com. dnsName Maps a subjectAltName's dNSName to a NETCONF username after first converting it to all lowercase (RFC 5280 does not specify converting to lowercase so this involves an extra step). This mapping results in a 1:1 correspondence between subjectAltName dNSName values and the NETCONF username values. reference: RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. ipAddress Maps a subjectAltName's iPAddress to a NETCONF username by transforming the binary encoded address as follows: 1) for IPv4, the value is converted into a decimal-dotted quad address (e.g., '192.0.2.1'). 2) for IPv6 addresses, the value is converted into a 32-character all lowercase hexadecimal string without any colon separators. This mapping results in a 1:1 correspondence between subjectAltName iPAddress values and the NETCONF username values. rfc822Name-dnsName-ipAddress rfc822Name-ipAddress-dnsName dnsName-ipAddress-rfc822Name dnsName-rfc822Name-ipAddress ipAddress-dnsName-rfc822Name ipAddress-rfc822Name-dnsName For each of these enumerations, the NETCONF server derives the NETCONF username in a similar manner. The NETCONF server derives the NETCONF username from the subjectAltName fields rfc822Name, dnsName, and ipAddress, as described in sections above. However, each of these subjectAltName fields is examined in the order specified by the enumeration name. The first matching subjectAltName value found in the certificate MUST be used when deriving the NETCONF username. For example, the rfc822Name-dnsName-ipAddress enumeration specifies the NETCONF server first examines the rfc822Name, then examines the dnsName, then finally examines the ipAddress. In contrast, the ipAddress-rfc822Name-dnsName enumeration specifies the NETCONF server first examines the ipAddress name, then examines the rfc822Name, then finally examines the dnsName. These mappings result in a 1:1 correspondence between subjectAltName values and NETCONF username values. The sub-mapping algorithms produced by these combined algorithms cannot produce conflicting results between themselves."; } // leaf map-type leaf data { type string { length "1..max"; } description "Auxiliary data used as optional configuration information for a given mapping specified by the map-type column. Only some mapping systems will make use of this column. The value in this column MUST be ignored for any mapping type that does not require data present in this column."; } } // list certificate-to-username-transform } // container certificate-to-username-transform } Pre-shared Key Authentication ----------------------------- Implementations may optionally support TLS Pre-Shared Key (PSK) authentication. RFC 4279 describes pre-shared key ciphersuites for TLS. During the TLS Handshake, the client indicates which key to use by including a PSK identity in the TLS ClientKeyExchange message [RFC4279]. On the server side, this PSK identity is used to lookup the key corresponding to the presented PSK identity. If the selected pre-shared keys match, then the client is authenticated and the PSK identity is used as the NETCONF username. For details how the PSK identity may be encoded in UTF-8, see section 5.1. of RFC 4279. From biermana@Brocade.com Fri Oct 21 08:01:14 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F86821F8B27 for ; Fri, 21 Oct 2011 08:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 3gD+iNBtceGf for ; Fri, 21 Oct 2011 08:01:13 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5E15D21F8B1A for ; Fri, 21 Oct 2011 08:01:13 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p9LF03Li001665; Fri, 21 Oct 2011 08:01:08 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id 10kayw001b-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Oct 2011 08:01:07 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 21 Oct 2011 08:08:27 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Fri, 21 Oct 2011 08:01:06 -0700 From: Andy Bierman To: Juergen Schoenwaelder , "Bert Wijnen (IETF)" Date: Fri, 21 Oct 2011 08:01:05 -0700 Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st Thread-Index: AcyP03vQYS4BsQjeR1uFqIBlYXPQdwALmIag Message-ID: References: <4E8D94F1.1070705@bwijnen.net> <4E97E362.4070102@bwijnen.net> <20111021092552.GB6530@elstar.local> In-Reply-To: <20111021092552.GB6530@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-21_06:2011-10-21, 2011-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110210137 Cc: netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:01:14 -0000 You responded to the wrong draft thread. We will try to add text to the security considerations that emphasizes what most operators already know -- the order=20 of access control rules matters. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Friday, October 21, 2011 2:26 AM To: Bert Wijnen (IETF) Cc: netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notificat= ions-05.txt - runs till oct 21st On Fri, Oct 14, 2011 at 09:23:14AM +0200, Bert Wijnen (IETF) wrote: > Gentle reminder! >=20 > Please do review and post your comments/questions/support/objections > by Friday 21st of October. >=20 > We explicitly ask you to ALSO let us know if you have read and > support or agree with the document. I have read the -05 version of NACM and it has significantly improved since the last version I reviewed. A great job done by the editors and I think the document is basically ready to go. I only have some nits and a clarification question / suggestion. A clarification question: My understanding of the document is that a user who is member of two groups (say A and B) with conflicting access control rule lists (say R1 of group A allows access to foo while R2 of group B denies access to foo) will either be allowed to access foo or denied access depending on the order of the rule lists. If R1 is before R2, then R1 matches and access is allowed. If R2 is before R1, then R2 matches and access is denied. Is my understanding correct? If yes, then there should perhaps be a hint in the security considerations that changing order of rules and rule lists can have significant impact on the access rights granted. Nits: - s/rules are editing directly/rules are edited directly/ - "NACM requires some a user name in each NACM group mapping." Despite the construction of the sentence, it is not even clear what the intended meaning was. I think the yang model allows a group with an empty leaf-list of users. - s/"path-stmt" values/"path-stmt" values)/ - s/ot it may/or it may/ - s/. entry/ entry/ - s/. entries/ entries/ - What is the "mod-3" rule refered to at the end of A.4? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Fri Oct 21 10:00:35 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9146F1F0C8C for ; Fri, 21 Oct 2011 10:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 in7tzT4aPTFf for ; Fri, 21 Oct 2011 10:00:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 537F91F0C8A for ; Fri, 21 Oct 2011 10:00:33 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 662F920C5A; Fri, 21 Oct 2011 19:00:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gyw5SgEVGXld; Fri, 21 Oct 2011 19:00:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0633520C57; Fri, 21 Oct 2011 19:00:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2AAF11B3265B; Fri, 21 Oct 2011 19:00:08 +0200 (CEST) Date: Fri, 21 Oct 2011 19:00:07 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20111021170007.GA8139@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , netconf References: <4E8D94F1.1070705@bwijnen.net> <4E97E362.4070102@bwijnen.net> <20111021092552.GB6530@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:00:35 -0000 On Fri, Oct 21, 2011 at 08:01:05AM -0700, Andy Bierman wrote: > You responded to the wrong draft thread. We will try to add text to > the security considerations that emphasizes what most operators > already know -- the order of access control rules matters. Oops. I guess for rules this might be more or less obvious. It may be more subtle that swapping rule lists can change acm behaviour as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From biermana@Brocade.com Fri Oct 21 10:14:35 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687E91F0C9A for ; Fri, 21 Oct 2011 10:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 zZPufahfvdCb for ; Fri, 21 Oct 2011 10:14:34 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEC11F0C95 for ; Fri, 21 Oct 2011 10:14:34 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p9LHCUgs015196; Fri, 21 Oct 2011 10:14:31 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id 10kcbw00rm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Oct 2011 10:14:31 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 21 Oct 2011 10:28:22 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 21 Oct 2011 10:14:30 -0700 From: Andy Bierman To: Juergen Schoenwaelder Date: Fri, 21 Oct 2011 10:14:27 -0700 Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st Thread-Index: AcyQEvtVwae1ln1DSQOyGkOBHjdcfgAATTVw Message-ID: References: <4E8D94F1.1070705@bwijnen.net> <4E97E362.4070102@bwijnen.net> <20111021092552.GB6530@elstar.local> <20111021170007.GA8139@elstar.local> In-Reply-To: <20111021170007.GA8139@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-21_06:2011-10-21, 2011-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110210177 Cc: netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-05.txt - runs till oct 21st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:14:35 -0000 We are hoping that vendors include pre-populated roles and operators just need to add users into the proper role-based groups. IMO, proper use of 'security tagging' in the data model (nacm:default-deny-write and nacm:default-deny-all) should reduce the need for detailed data access control rules. Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 21, 2011 10:00 AM To: Andy Bierman Cc: Bert Wijnen (IETF); netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notificat= ions-05.txt - runs till oct 21st On Fri, Oct 21, 2011 at 08:01:05AM -0700, Andy Bierman wrote: > You responded to the wrong draft thread. We will try to add text to > the security considerations that emphasizes what most operators > already know -- the order of access control rules matters. Oops. I guess for rules this might be more or less obvious. It may be more subtle that swapping rule lists can change acm behaviour as well. /js =20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Oct 23 12:53:29 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9B21F8A55 for ; Sun, 23 Oct 2011 12:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.072 X-Spam-Level: X-Spam-Status: No, score=-103.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 F+X7n6Jz47-H for ; Sun, 23 Oct 2011 12:53:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AD21F8A35 for ; Sun, 23 Oct 2011 12:53:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92A1220733 for ; Sun, 23 Oct 2011 21:53:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zFde7zbTIwJy; Sun, 23 Oct 2011 21:53:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2562020553; Sun, 23 Oct 2011 21:53:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7CFAE1B35838; Sun, 23 Oct 2011 21:53:00 +0200 (CEST) Date: Sun, 23 Oct 2011 21:53:00 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20111023195300.GA26734@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:53:29 -0000 Hi, it is very good to see YANG data models to configure / monitor various aspects of NETCONF. That said, I am concerned about the usage of namespaces (and even at the risk that people say "go away with your academic nit picking since we focus one thing at a time"), I felt that I at least raise my concern. Right now, we have the following namespaces urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring RFC 6022 urn:ietf:params:xml:ns:netconf:base:1.0 RFC 6241 urn:ietf:params:xml:ns:netconf:notification:1.0 RFC 5277 (no YANG) urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults RFC 6243 urn:ietf:params:xml:ns:yang:ietf-netconf-acm I-D.NACM urn:ietf:params:xml:ns:yang:ietf-netconf-notifications I-D.NSN and there might be additional modules for say the TLS transport and other NETCONF extensions coming to us soon. Technically, having all these relatively small and modular data models live in their own namespace is just fine for programs but for human readers of configurations, the many namespace prefixes make reading and editing configurations more complicated than it needs to be I think. So the question is whether we should seriously consider using submodules instead. This would allow us to have a single namespace and things like the acm configuration model or the TLS certificate mapping configuration model just become submodules and part of this common namespace. In a nutshell, we would have this little parent module module ietf-netconf-parent { namespace urn:ietf:params:xml:ns:yang:ietf-netconf-parent; prefix ncp; include ietf-netconf-acm { revision-date 2011-xx-xx; } include ietf-netconf-notifications { revision-date 2011-xx-yy; } // ... } and we would include an updated version of it (with additional includes) whenever a new NETCONF data model gets published as RFC. I think we need to answer this question now; RFC 6022 and RFC 6243 would then be "early accidents" and RFC 6241 is special anyway since the namespace had been fixed by the design of RFC 4741, which clearly predates YANG (and the same would be true in case RFC 5277 ever gets rewritten in YANG). /js PS: This idea apparently is not new, Martin kind of pointed to it already back on Tue, 11 Aug 2009 21:36:10 +0200. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Sun Oct 23 13:28:12 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1AB21F8B2B for ; Sun, 23 Oct 2011 13:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tI1X+S98t7Yy for ; Sun, 23 Oct 2011 13:28:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0919D21F8B26 for ; Sun, 23 Oct 2011 13:28:11 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so5290826vcb.31 for ; Sun, 23 Oct 2011 13:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Qnv2BfpAHScUc5hh6cXBWTpiIuGQFxiEsAwrnBNZ6as=; b=YoUm5749YcDxtyNepVxW5ivBIu23nG+wxBxAQIEuO7R3onb085TB0cKurKx8yB1WSi 35bErCJZGu5nN0Wv6BfkzuWSQc/jFBn8Ei+IzEs+7g1r20WfOtSoEFHEQtTnRp3O4uYa 8RlgsWDS8h70U0wlhr0tDtzDSe+KsV+ab/prk= MIME-Version: 1.0 Received: by 10.52.175.165 with SMTP id cb5mr20357328vdc.47.1319401690236; Sun, 23 Oct 2011 13:28:10 -0700 (PDT) Received: by 10.220.201.8 with HTTP; Sun, 23 Oct 2011 13:28:10 -0700 (PDT) Date: Sun, 23 Oct 2011 22:28:10 +0200 Message-ID: From: Badra To: netconf@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a8ec61005a704affd2598 Subject: [Netconf] New version of NETCONF over TLS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 20:28:12 -0000 --bcaec51a8ec61005a704affd2598 Content-Type: text/plain; charset=ISO-8859-1 Dear all, A new version of "NETCONF over TLS" document is available at http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt Comments are welcome. Best regards, Badra --bcaec51a8ec61005a704affd2598 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

A new version of "NETCONF over TLS&q= uot; document is available at http://www.ietf.org/id/draft-= badra-netconf-rfc5539bis-00.txt

Comments are welcome.
Best regards,
Badra
--bcaec51a8ec61005a704affd2598-- From ietf@andybierman.com Sun Oct 23 13:46:18 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A3321F8ACC for ; Sun, 23 Oct 2011 13:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599] 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 FMUx2uXylYMp for ; Sun, 23 Oct 2011 13:46:17 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4321F8AAA for ; Sun, 23 Oct 2011 13:46:17 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p9NKkDxY007291 for ; Sun, 23 Oct 2011 16:46:15 -0400 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:57730] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id EB/8B-04516-51D74AE4; Sun, 23 Oct 2011 16:46:13 -0400 Message-ID: <4EA47D35.4000209@andybierman.com> Date: Sun, 23 Oct 2011 13:46:45 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: netconf@ietf.org References: <20111023195300.GA26734@elstar.local> In-Reply-To: <20111023195300.GA26734@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 20:46:18 -0000 On 10/23/2011 12:53 PM, Juergen Schoenwaelder wrote: > Hi, > > it is very good to see YANG data models to configure / monitor various > aspects of NETCONF. That said, I am concerned about the usage of > namespaces (and even at the risk that people say "go away with your > academic nit picking since we focus one thing at a time"), I felt that > I at least raise my concern. Right now, we have the following > namespaces > > urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring RFC 6022 > urn:ietf:params:xml:ns:netconf:base:1.0 RFC 6241 > urn:ietf:params:xml:ns:netconf:notification:1.0 RFC 5277 (no YANG) > urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults RFC 6243 > urn:ietf:params:xml:ns:yang:ietf-netconf-acm I-D.NACM > urn:ietf:params:xml:ns:yang:ietf-netconf-notifications I-D.NSN > > and there might be additional modules for say the TLS transport and > other NETCONF extensions coming to us soon. Technically, having all > these relatively small and modular data models live in their own > namespace is just fine for programs but for human readers of > configurations, the many namespace prefixes make reading and editing > configurations more complicated than it needs to be I think. > > So the question is whether we should seriously consider using > submodules instead. This would allow us to have a single namespace > and things like the acm configuration model or the TLS certificate > mapping configuration model just become submodules and part of this > common namespace. In a nutshell, we would have this little parent > module > I proposed a YANG module for a registry in draft-bierman-netmod-yang-usage-00.txt in January, 2009. It got taken out way before RFC 6087 was published. I now realize our standards process is more robust when there are specific RFCs to point at, so a registry would not really work for standard modules. A 'main module' RFC that keeps changing all the time doesn't seem so good either. Every RFC published would have a normative reference to this main module RFC, except the sub-modules will reference an assortment of main module RFC numbers. The RFC publishing process gets slowed down enough already due to normative references. Waiting in line to get the main module updated doesn't work. Separate namespaces are going to happen for augment-stmts anyway, so applications and servers will not be able to ignore namespaces. I think we could invent some YANG/NETCONF shorthand for the 'std' namespace, like in C++. It may be too late now, but something that avoids a main module with include-stmts that change constantly would work. Andy > module ietf-netconf-parent { > > namespace urn:ietf:params:xml:ns:yang:ietf-netconf-parent; > prefix ncp; > > include ietf-netconf-acm { > revision-date 2011-xx-xx; > } > > include ietf-netconf-notifications { > revision-date 2011-xx-yy; > } > > // ... > } > > and we would include an updated version of it (with additional > includes) whenever a new NETCONF data model gets published as RFC. I > think we need to answer this question now; RFC 6022 and RFC 6243 would > then be "early accidents" and RFC 6241 is special anyway since the > namespace had been fixed by the design of RFC 4741, which clearly > predates YANG (and the same would be true in case RFC 5277 ever gets > rewritten in YANG). > > /js > > PS: This idea apparently is not new, Martin kind of pointed to it > already back on Tue, 11 Aug 2009 21:36:10 +0200. > From mbj@tail-f.com Sun Oct 23 13:59:42 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A733621F8AE9 for ; Sun, 23 Oct 2011 13:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 W1OaLR85QfmR for ; Sun, 23 Oct 2011 13:59:42 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0D15221F8A80 for ; Sun, 23 Oct 2011 13:59:42 -0700 (PDT) Received: from localhost (unknown [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 5BCE112008D2; Sun, 23 Oct 2011 22:59:39 +0200 (CEST) Date: Sun, 23 Oct 2011 22:59:37 +0200 (CEST) Message-Id: <20111023.225937.384150692.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4EA47D35.4000209@andybierman.com> References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 20:59:42 -0000 Andy Bierman wrote: > > So the question is whether we should seriously consider using > > submodules instead. I think we should (at least seriously consider it - now). > > This would allow us to have a single namespace > > and things like the acm configuration model or the TLS certificate > > mapping configuration model just become submodules and part of this > > common namespace. In a nutshell, we would have this little parent > > module > > > > I proposed a YANG module for a registry in > draft-bierman-netmod-yang-usage-00.txt > in January, 2009. It got taken out way before RFC 6087 was published. > I now realize our standards process is more robust when there are specific RFCs > to point at, so a registry would not really work for standard modules. > > A 'main module' RFC that keeps changing all the time doesn't seem so good > either. > Every RFC published would have a normative reference to this main module RFC, > except the sub-modules will reference an assortment of main module RFC numbers. > The RFC publishing process gets slowed down enough already due to normative > references. > Waiting in line to get the main module updated doesn't work. One approach is to update the main module in the same document that publishes the new submodule. It's not like we publish new data models so fast that we can't handle this. One issue is how two handle if two or more submodules gets published at the same time. I guess one of the new documents (or another new document) contains the module. Another approach is to let IANA handle the main module. It would then be a normal IANA registry, but in YANG format. > Separate namespaces are going to happen for augment-stmts anyway, so > applications > and servers will not be able to ignore namespaces. That is not the goal here. The goal is to reduce the number of namespaces. > > module ietf-netconf-parent { We should have called the module in 6241 "ietf-netconf-protocol"... "parent" is not very descriptive... need to think about a good name. > > and we would include an updated version of it (with additional > > includes) whenever a new NETCONF data model gets published as RFC. I > > think we need to answer this question now; RFC 6022 and RFC 6243 would > > then be "early accidents" and RFC 6241 is special anyway since the > > namespace had been fixed by the design of RFC 4741, which clearly > > predates YANG (and the same would be true in case RFC 5277 ever gets > > rewritten in YANG). Our current charter allows an update to 6022, so maybe that one can be fixed. 6243 only defines additional parameters to the operations defined in 6241, but I guess they could have been done in the "protocol" namespace if it was done as a submodule. /martin From ietf@andybierman.com Sun Oct 23 14:08:47 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD0021F8507 for ; Sun, 23 Oct 2011 14:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599] 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 AT9cvbizskGo for ; Sun, 23 Oct 2011 14:08:46 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8416821F84FA for ; Sun, 23 Oct 2011 14:08:40 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p9NL8daY017359 for ; Sun, 23 Oct 2011 17:08:39 -0400 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:52501] helo=[192.168.0.9]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 09/0A-05308-75284AE4; Sun, 23 Oct 2011 17:08:39 -0400 Message-ID: <4EA48278.30001@andybierman.com> Date: Sun, 23 Oct 2011 14:09:12 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Martin Bjorklund References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> <20111023.225937.384150692.mbj@tail-f.com> In-Reply-To: <20111023.225937.384150692.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 21:08:47 -0000 On 10/23/2011 01:59 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >>> So the question is whether we should seriously consider using >>> submodules instead. > > I think we should (at least seriously consider it - now). > I do not think there are too many namespaces. I do not agree there is a problem with each YANG module having its own namespace, especially since the standard URI does not support sub-modules. I think it's OK if a WG want s to structure a new module so that it uses sub-modules. The modules that are already published are done and should not be touched. Andy >>> This would allow us to have a single namespace >>> and things like the acm configuration model or the TLS certificate >>> mapping configuration model just become submodules and part of this >>> common namespace. In a nutshell, we would have this little parent >>> module >>> >> >> I proposed a YANG module for a registry in >> draft-bierman-netmod-yang-usage-00.txt >> in January, 2009. It got taken out way before RFC 6087 was published. >> I now realize our standards process is more robust when there are specific RFCs >> to point at, so a registry would not really work for standard modules. >> >> A 'main module' RFC that keeps changing all the time doesn't seem so good >> either. >> Every RFC published would have a normative reference to this main module RFC, >> except the sub-modules will reference an assortment of main module RFC numbers. >> The RFC publishing process gets slowed down enough already due to normative >> references. >> Waiting in line to get the main module updated doesn't work. > > One approach is to update the main module in the same document that > publishes the new submodule. It's not like we publish new data models > so fast that we can't handle this. One issue is how two handle if two > or more submodules gets published at the same time. I guess one of > the new documents (or another new document) contains the module. > > Another approach is to let IANA handle the main module. It would then > be a normal IANA registry, but in YANG format. > >> Separate namespaces are going to happen for augment-stmts anyway, so >> applications >> and servers will not be able to ignore namespaces. > > That is not the goal here. The goal is to reduce the number of > namespaces. > >>> module ietf-netconf-parent { > > We should have called the module in 6241 > "ietf-netconf-protocol"... "parent" is not very descriptive... need to > think about a good name. > >>> and we would include an updated version of it (with additional >>> includes) whenever a new NETCONF data model gets published as RFC. I >>> think we need to answer this question now; RFC 6022 and RFC 6243 would >>> then be "early accidents" and RFC 6241 is special anyway since the >>> namespace had been fixed by the design of RFC 4741, which clearly >>> predates YANG (and the same would be true in case RFC 5277 ever gets >>> rewritten in YANG). > > Our current charter allows an update to 6022, so maybe that one can be > fixed. 6243 only defines additional parameters to the operations > defined in 6241, but I guess they could have been done in the > "protocol" namespace if it was done as a submodule. > > > /martin > > From ietf@andybierman.com Sun Oct 23 14:42:20 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD2A21F8AFB for ; Sun, 23 Oct 2011 14:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599] 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 J3oC9EdCuoON for ; Sun, 23 Oct 2011 14:42:20 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id DBF5F21F888A for ; Sun, 23 Oct 2011 14:42:19 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id p9NLgGsg003745 for ; Sun, 23 Oct 2011 17:42:16 -0400 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:53919] helo=[192.168.0.9]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 76/0A-03699-83A84AE4; Sun, 23 Oct 2011 17:42:16 -0400 Message-ID: <4EA48A59.20205@andybierman.com> Date: Sun, 23 Oct 2011 14:42:49 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Martin Bjorklund References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> <20111023.225937.384150692.mbj@tail-f.com> In-Reply-To: <20111023.225937.384150692.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 21:42:20 -0000 On 10/23/2011 01:59 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >>> So the question is whether we should seriously consider using >>> submodules instead. > > I think we should (at least seriously consider it - now). Since you brought it up, you should define the problem in detail, so we can tell evaluate solution proposals. A giant kitchen sink module seems worse than a URI for every little module. The app probably needs to align with a specific version of each managed object, so a list of submodule name/submodule revision dates would be needed if this was removed from the the . If there is some usable functional modularity, i.e., some module cohesion, then sub-modules are appropriate. I think the latest NETMOD work can be consolidated because there are too many modules. In hindsight, one ietf-netconf.yang for all the NETCONF protocol sub-modules might be a little better than what we have (all modules), but it's not worth redoing it now. > ... > /martin > > Andy From lhotka@cesnet.cz Mon Oct 24 01:33:22 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A921A21F8BA6 for ; Mon, 24 Oct 2011 01:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 XyQuXH4XtoQd for ; Mon, 24 Oct 2011 01:33:22 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 177CA21F8B1E for ; Mon, 24 Oct 2011 01:33:18 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2F6D12CDE058 for ; Mon, 24 Oct 2011 10:33:17 +0200 (CEST) Message-ID: <4EA522CC.8080202@cesnet.cz> Date: Mon, 24 Oct 2011 10:33:16 +0200 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netconf@ietf.org References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> <20111023.225937.384150692.mbj@tail-f.com> <4EA48278.30001@andybierman.com> In-Reply-To: <4EA48278.30001@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 08:33:22 -0000 Dne 23.10.2011 23:09, Andy Bierman napsal(a): > I do not think there are too many namespaces. > I do not agree there is a problem with each YANG module having > its own namespace, especially since the standard URI > does not support sub-modules. > > I think it's OK if a WG want s to structure a new module so that > it uses sub-modules. The modules that are already published are > done and should not be touched. I agree with Andy. Moreover, I don't think NETCONF instance XML documents are intended to be read by humans, except for debugging. Also, if prefixes really were an issue, it is possible to use namespace declarations in a way that considerably reduces the use of prefixes. Lada > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Mon Oct 24 09:26:13 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B1D21F8AD6 for ; Mon, 24 Oct 2011 09:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.277 X-Spam-Level: X-Spam-Status: No, score=-106.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 s21hB-CwQD4q for ; Mon, 24 Oct 2011 09:26:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7CE21F848E for ; Mon, 24 Oct 2011 09:25:53 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9OGPq6K007345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 Oct 2011 18:25:52 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9OGPpfC020370 for ; Mon, 24 Oct 2011 18:25:51 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 18:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 24 Oct 2011 18:25:51 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402DA0568@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netconf - Requested session has been scheduled for IETF 82 Thread-Index: AcySaGi5hiWy8avjSDOMMD+v8//eRwAAMDNw From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 24 Oct 2011 16:25:51.0737 (UTC) FILETIME=[98A98690:01CC9269] Subject: [Netconf] FW: netconf - Requested session has been scheduled for IETF 82 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:26:13 -0000 SGkgQWxsLA0KDQp0aGVyZSBpcyBhbiBhZ2VuZGEgY2hhbmdlIGNvbmNlcm5pbmcgdGhlIE5FVENP TkYgc2Vzc2lvbi4gDQoNClRoZSBORVRDT05GIHNlc3Npb24gaW4gSUVURiA4MiB3aWxsIGJlIG9u ICJUdWVzZGF5IGF0IDE3MTAiDQpmb3Igb25lIGhvdXIuDQoNCk1laG1ldCANCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIklFVEYgU2VjcmV0YXJpYXQiIFttYWlsdG86YWdl bmRhQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNCwgMjAxMSA2OjE3IFBNDQpU bzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KQ2M6IG5ldGNvbmYtYWRzQHRvb2xz LmlldGYub3JnOyBuZXRjb25mLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgd2xvQGFtc2wuY29tDQpT dWJqZWN0OiBuZXRjb25mIC0gUmVxdWVzdGVkIHNlc3Npb24gaGFzIGJlZW4gc2NoZWR1bGVkIGZv ciBJRVRGIDgyDQoNCkRlYXIgTWVobWV0IEVyc3VlLA0KDQpUaGUgc2Vzc2lvbnMgdGhhdCB5b3Ug aGF2ZSByZXF1ZXN0ZWQgaGF2ZSBiZWVuIHNjaGVkdWxlZC4NCkJlbG93IGlzIHRoZSBzY2hlZHVs ZWQgc2Vzc2lvbiBpbmZvcm1hdGlvbiBmb2xsb3dlZCBieQ0KdGhlIG9yaWdpbmFsIHJlcXVlc3Qu IA0KDQpuZXRjb25mIFNlc3Npb24gMSAoMiBob3VycykNCiAgICBUdWVzZGF5LCBBZnRlcm5vb24g U2Vzc2lvbiBJSUkgMTcxMC0xODEwDQogICAgUm9vbSBOYW1lOiAxMDFBDQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQoNCg0KUmVxdWVzdCBJ bmZvcm1hdGlvbjoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpXb3JraW5nIEdyb3VwIE5hbWU6IE5ldHdvcmsgQ29uZmlndXJhdGlv bg0KQXJlYSBOYW1lOiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWENClNlc3Npb24gUmVx dWVzdGVyOiBXYW5kYSBMbw0KDQpOdW1iZXIgb2YgU2Vzc2lvbnM6IDENCkxlbmd0aCBvZiBTZXNz aW9uKHMpOiAgMiBob3Vycw0KTnVtYmVyIG9mIEF0dGVuZGVlczogNDANCkNvbmZsaWN0cyB0byBB dm9pZDogDQogRmlyc3QgUHJpb3JpdHk6IG9wc2FyZWEgb3BzYXdnIG5ldG1vZCBpcGZpeCByYWRl eHQgZGltZSBlbWFuIHNpZHINCiBTZWNvbmQgUHJpb3JpdHk6IHRzdmFyZWEgYXBwYXJlYSB2Nm9w cyB0c3Z3ZyBpcHBtIGJtd2cgZ3JvdyBtYm9uZWQgb3BzZWMgYXJtZCA2cmVudW0NCiBUaGlyZCBQ cmlvcml0eTogZG5zb3AgYWRzbG1pYiBkaGMgYW5jcCBjb3JlIDZsb3dwYW4NCiBCT0Ygb3IgSVJU RiBTZXNzaW9uOiBubXJnIGNsb3VkIElvVA0KDQoNClNwZWNpYWwgUmVxdWVzdHM6DQogIE5FVENP TkYgaXMgdmVyeSBtdWNoIHJlbGF0ZWQgdG8gTkVUTU9ELiBJZiBwb3NzaWJsZSBwbGVhc2Ugc2No ZWR1bGUgTkVUQ09ORiBhbmQgTkVUTU9EIHNlc3Npb25zIG9uIHN1YnNlcXVlbnQgZGF5cyBhdCB0 aGUgYmVnaW5uaW5nIG9mIHRoZSB3ZWVrLCBlLmcuIE5FVENPTkYgKE1vbmRheSkgYW5kIE5FVE1P RCAoVHVlc2RheSkuDQpUaGFuayB5b3UuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From kwatsen@juniper.net Mon Oct 24 14:02:31 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135E821F8AD8 for ; Mon, 24 Oct 2011 14:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 USmzm2eo-nTz for ; Mon, 24 Oct 2011 14:02:30 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0621F8AC3 for ; Mon, 24 Oct 2011 14:02:29 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 24 Oct 2011 14:02:29 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 24 Oct 2011 14:01:55 -0700 From: Kent Watsen To: "netconf@ietf.org" Date: Mon, 24 Oct 2011 14:01:52 -0700 Thread-Topic: [Netconf] netconf yang module namespaces Thread-Index: AcySKHszw73MLqXYTi+12LkJkqP56wAZLujA Message-ID: <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> <20111023.225937.384150692.mbj@tail-f.com> <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> In-Reply-To: <4EA522CC.8080202@cesnet.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:02:31 -0000 This thread appears the same as the one started a few months ago on the net= mod list: http://www.ietf.org/mail-archive/web/netmod/current/msg05931.htm= l. =20 That thread peters out, but I maintain that YANG unnecessarily imposes a te= chnical constraint that could've been handled by a maintainer of multiple Y= ANG modules (such as this group). All we'd need to do is change section 5.3 from: All YANG definitions are specified within a module that is bound to a particular XML namespace [XML-NAMES], which is a globally unique URI [RFC3986]. To: All YANG definitions are specified within a module that is bound to a particular XML namespace [XML-NAMES]. Multiple YANG modules MAY share a namespace but, to guarantee no namespace collisions, each YANG module SHOULD have a unique XML namespace. This would be a backwards-compatible change to the spec. Thanks, Kent From j.schoenwaelder@jacobs-university.de Mon Oct 24 14:24:41 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E8811E8124 for ; Mon, 24 Oct 2011 14:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.079 X-Spam-Level: X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 6Ojozi8M4qnw for ; Mon, 24 Oct 2011 14:24:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 88EF511E8123 for ; Mon, 24 Oct 2011 14:24:40 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8084420CC6; Mon, 24 Oct 2011 23:24:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HqzmLBCjW7bJ; Mon, 24 Oct 2011 23:24:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 020AE20CC1; Mon, 24 Oct 2011 23:24:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0F75F1B37F08; Mon, 24 Oct 2011 23:24:21 +0200 (CEST) Date: Mon, 24 Oct 2011 23:24:21 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20111024212421.GA29367@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> <20111023.225937.384150692.mbj@tail-f.com> <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:24:41 -0000 On Mon, Oct 24, 2011 at 02:01:52PM -0700, Kent Watsen wrote: > This thread appears the same as the one started a few months ago on the netmod list: http://www.ietf.org/mail-archive/web/netmod/current/msg05931.html. > > That thread peters out, but I maintain that YANG unnecessarily imposes a technical constraint that could've been handled by a maintainer of multiple YANG modules (such as this group). > > All we'd need to do is change section 5.3 from: > > All YANG definitions are specified within a module that is bound to a > particular XML namespace [XML-NAMES], which is a globally unique URI > [RFC3986]. > > To: > > All YANG definitions are specified within a module that is bound to > a particular XML namespace [XML-NAMES]. Multiple YANG modules MAY > share a namespace but, to guarantee no namespace collisions, each > YANG module SHOULD have a unique XML namespace. > > This would be a backwards-compatible change to the spec. Submodules were designed into YANG to do this, allowing tools to check that namespace collisions do not occur etc. What do we gain by not using them? Andy's argument that the namespaces matter in the exchange assumes that namespaces are useful units to check for in server capabilities. Given the way work is organized in bodies like the IETF, this may or may not be true. I would rather go with less granualar namespaces and encourage the definition of features. AFAIK, this allows a client still to discover data model features supported by a server without polluting the config itself with too many different namespaces. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Oct 24 14:28:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDF411E8160 for ; Mon, 24 Oct 2011 14:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Bgy30UJmp-W7 for ; Mon, 24 Oct 2011 14:28:14 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDC811E815C for ; Mon, 24 Oct 2011 14:28:14 -0700 (PDT) Received: from localhost (unknown [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BDC5012008BF; Mon, 24 Oct 2011 23:28:12 +0200 (CEST) Date: Mon, 24 Oct 2011 23:28:11 +0200 (CEST) Message-Id: <20111024.232811.169019089.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:28:15 -0000 Hi, Kent Watsen wrote: > This thread appears the same as the one started a few months ago on the netmod > list: http://www.ietf.org/mail-archive/web/netmod/current/msg05931.html. It is related, but not the issue here. Even with your proposed change to YANG, the question would be if this new feature should be used in this particular case. And for IETF-based modules, your proposed solution would probably require new IANA registries to keep track of the namespaces so no collisions occur. If we agree that we want to minimize the number of namespaces, I think we could still use submodules as they are defined today. The drawback (compared with your proposal) is that each submodule's revision is not directly advertised in the hello, but it is not clear to me that this is a problem, and if it is a problem worth solving, we could design a way to advertise submodules w/o changing 6020. /martin From ietf@andybierman.com Mon Oct 24 14:29:37 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E9C11E8160 for ; Mon, 24 Oct 2011 14:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599] 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 HTW7-OTy2iJv for ; Mon, 24 Oct 2011 14:29:37 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4AD11E815C for ; Mon, 24 Oct 2011 14:29:37 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id p9OLTYMS009109 for ; Mon, 24 Oct 2011 17:29:34 -0400 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:44433] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3E/1A-04516-DB8D5AE4; Mon, 24 Oct 2011 17:29:34 -0400 Message-ID: <4EA5D8E9.5080009@andybierman.com> Date: Mon, 24 Oct 2011 14:30:17 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kent Watsen References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> <20111023.225937.384150692.mbj@tail-f.com> <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:29:38 -0000 On 10/24/2011 02:01 PM, Kent Watsen wrote: > This thread appears the same as the one started a few months ago on the netmod list: http://www.ietf.org/mail-archive/web/netmod/current/msg05931.html. > > That thread peters out, but I maintain that YANG unnecessarily imposes a technical constraint that could've been handled by a maintainer of multiple YANG modules (such as this group). > > All we'd need to do is change section 5.3 from: > > All YANG definitions are specified within a module that is bound to a > particular XML namespace [XML-NAMES], which is a globally unique URI > [RFC3986]. > > To: > > All YANG definitions are specified within a module that is bound to > a particular XML namespace [XML-NAMES]. Multiple YANG modules MAY > share a namespace but, to guarantee no namespace collisions, each > YANG module SHOULD have a unique XML namespace. > > This would be a backwards-compatible change to the spec. > I do not agree. An application that expects a 1:1 mapping between YANG module and XML namespace will not accept multiple YANG modules with different names but the same namespace URI. IMO, this protocol is for applications, and it is not that difficult for applications to deal with XML namespaces. The YANG module reader doesn't really care what is in the namespace-stmt string, so it does not hurt readability. > Thanks, > Kent > Andy From ietf@andybierman.com Mon Oct 24 15:02:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823411E8121 for ; Mon, 24 Oct 2011 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] 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 xFtNql8Efn8G for ; Mon, 24 Oct 2011 15:02:00 -0700 (PDT) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by ietfa.amsl.com (Postfix) with ESMTP id 23FEB11E80B1 for ; Mon, 24 Oct 2011 15:01:59 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p9OM1vK2014065 for ; Mon, 24 Oct 2011 18:01:59 -0400 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:56110] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 53/9D-04749-550E5AE4; Mon, 24 Oct 2011 18:01:57 -0400 Message-ID: <4EA5E080.4010703@andybierman.com> Date: Mon, 24 Oct 2011 15:02:40 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Martin Bjorklund References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> In-Reply-To: <20111024.232811.169019089.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:02:00 -0000 On 10/24/2011 02:28 PM, Martin Bjorklund wrote: > Hi, > > Kent Watsen wrote: >> This thread appears the same as the one started a few months ago on the netmod >> list: http://www.ietf.org/mail-archive/web/netmod/current/msg05931.html. > > It is related, but not the issue here. > > Even with your proposed change to YANG, the question would be if this > new feature should be used in this particular case. And for > IETF-based modules, your proposed solution would probably require new > IANA registries to keep track of the namespaces so no collisions > occur. > > If we agree that we want to minimize the number of namespaces, I think > we could still use submodules as they are defined today. The drawback > (compared with your proposal) is that each submodule's revision is not > directly advertised in the hello, but it is not clear to me that this > is a problem, and if it is a problem worth solving, we could design a > way to advertise submodules w/o changing 6020. > > I think RFC 6020 is fine the way it is wrt XML namespaces. I do not agree a giant kitchen-sink YANG module and/or XML namespace is a good idea. I agree that on a case-by-case basis, YANG designers may choose to divide a single module into a main module plus some submodules. I don't really understand the problem. Why is it a burden to encode NETCONF content with the XML namespace URI specified in the YANG module namespace-stmt for that content? The current protocol and YANG spec work fine for 1 module per XML namespace. Augment depends on it. > > /martin Andy From kwatsen@juniper.net Mon Oct 24 16:43:10 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63511E80A4 for ; Mon, 24 Oct 2011 16:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SAxz417n9kGx for ; Mon, 24 Oct 2011 16:43:09 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6055411E81DC for ; Mon, 24 Oct 2011 16:43:09 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP; Mon, 24 Oct 2011 16:43:09 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 24 Oct 2011 16:39:08 -0700 From: Kent Watsen To: Andy Bierman , Martin Bjorklund Date: Mon, 24 Oct 2011 16:39:04 -0700 Thread-Topic: [Netconf] netconf yang module namespaces Thread-Index: AcySmI2L518Oig0ET/KlOwTb8ESV8QACC9Fg Message-ID: <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> In-Reply-To: <4EA5E080.4010703@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:43:10 -0000 Every time this issue comes up, the first comment seems to be that this is = what submodules can solve. But this is simply not true, since in my case, = each device chooses which revision of which "submodules" (if they were) the= y advertize I cannot write a parent module that restricts the submodule re= visions to a specific subset, at least not without writing a parent module = for every possible combination of submodule revisions, which obviously woul= d be wrong. Submodules were designed primarily to support the notion of an operating sy= stem (Junos, IOS, etc.) being composed of set of components (routing, polic= y, auth, system, etc.), such that each release of the operating system (Jun= os 11.3R1) could have a single top-level module that includes the submodule= from each of its components. Submodules are perfect for this scenario. But submodules don't work so well when the YANG modules are defined by a 3r= d-party (IETF or, in my case, the vendor's in-house NMS group) where the de= vices have discretion as to which version of which modules they want to sup= port - they want to cherry-pick what they support and incrementally support= a newer version of a module without suddenly having to support a newer of = all the modules. Hence, we use top-level modules (not sub-modules), so tha= t each device can granularly advertize what's supported. Concrete example, we originally defined modules like this: module hardware { namespace "http://xml.juniper.net/dmi"; <--- same namespace prefix "dmi"; revision "2008-11-05" { ... } ... } module software { namespace "http://xml.juniper.net/dmi"; <--- same namespace prefix "dmi"; revision "2008-11-05" { ... } ... } module license { namespace "http://xml.juniper.net/dmi"; <--- same namespace prefix "dmi"; revision "2008-11-05" { ... } ... } But after the last thread not resolving the issue, we changed them to: module hardware { namespace "http://xml.juniper.net/dmi/hardware"; <--- different n= amespace prefix "dmi"; revision "2008-11-05" { ... } ... } module software { namespace "http://xml.juniper.net/dmi/software"; <--- different n= amespace prefix "dmi"; revision "2008-11-05" { ... } ... } module license { namespace "http://xml.juniper.net/dmi/license"; <--- different na= mespace prefix "dmi"; revision "2008-11-05" { ... } ... } The impact to the message is that it (unnecessarily) went from: http://xml.juniper.net/dmi?module=3Dhardware&revision=3D2008-11-05 http://xml.juniper.net/dmi?module=3Dsoftware&revision=3D2008-11-05 http://xml.juniper.net/dmi?module=3Dlicense&revision=3D2008-11-05 To: http://xml.juniper.net/dmi/hardware?module=3Dhardware&revision=3D2008-1= 1-05 http://xml.juniper.net/dmi/software?module=3Dsoftware&revision=3D2008-1= 1-05 http://xml.juniper.net/dmi/license?module=3Dlicense&revision=3D2008-11-= 05 [Of course, there's a similar impact to the "xmlns" attribute in the XML as= well] My biggest concern (reported last time) was/is that 6020 is a bit ambiguous= . At least my reading and those of a few others led us to believe what we = had done originally was correct. We felt justified in this conclusion in t= hat YANG-forced solution seems to adds little value, since my group (or IET= F, to this thread's OP's point) is the sole maintainer of our namespace(s) = and hence can ourselves guarantee that no collision will ever occur. Thanks, Kent From j.schoenwaelder@jacobs-university.de Tue Oct 25 02:36:08 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAC921F8A80 for ; Tue, 25 Oct 2011 02:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.086 X-Spam-Level: X-Spam-Status: No, score=-103.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 0LG75iIjcdt4 for ; Tue, 25 Oct 2011 02:36:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 078DA21F8A7D for ; Tue, 25 Oct 2011 02:36:08 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6C8520C2E; Tue, 25 Oct 2011 11:36:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7Uz7lgdcO_ZR; Tue, 25 Oct 2011 11:36:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55A9920C22; Tue, 25 Oct 2011 11:36:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 941161B386BC; Tue, 25 Oct 2011 11:35:48 +0200 (CEST) Date: Tue, 25 Oct 2011 11:35:48 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20111025093547.GB30291@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 09:36:08 -0000 On Mon, Oct 24, 2011 at 04:39:04PM -0700, Kent Watsen wrote: > > Every time this issue comes up, the first comment seems to be that > this is what submodules can solve. But this is simply not true, > since in my case, each device chooses which revision of which > "submodules" (if they were) they advertize I cannot write a parent > module that restricts the submodule revisions to a specific subset, > at least not without writing a parent module for every possible > combination of submodule revisions, which obviously would be wrong. [...] So the issue seems to be that the revisions of submodules are not announced in the hello exchange. Do we all agree with that? And reading /netconf-state/schemas is also not an option to obtain that information since people really like to have the details in the exchange. Do we agree with that as well? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Tue Oct 25 03:38:19 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1783621F8B64 for ; Tue, 25 Oct 2011 03:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] 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 elsrvA8fRHf4 for ; Tue, 25 Oct 2011 03:38:18 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE6621F85F7 for ; Tue, 25 Oct 2011 03:38:18 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id p9PAcD8K021283 for ; Tue, 25 Oct 2011 06:38:15 -0400 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:38618] helo=[192.168.0.9]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E8/A8-05348-59196AE4; Tue, 25 Oct 2011 06:38:13 -0400 Message-ID: <4EA691C6.5070903@andybierman.com> Date: Tue, 25 Oct 2011 03:39:02 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <20111025093547.GB30291@elstar.local> In-Reply-To: <20111025093547.GB30291@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:38:19 -0000 On 10/25/2011 02:35 AM, Juergen Schoenwaelder wrote: > On Mon, Oct 24, 2011 at 04:39:04PM -0700, Kent Watsen wrote: >> >> Every time this issue comes up, the first comment seems to be that >> this is what submodules can solve. But this is simply not true, >> since in my case, each device chooses which revision of which >> "submodules" (if they were) they advertize I cannot write a parent >> module that restricts the submodule revisions to a specific subset, >> at least not without writing a parent module for every possible >> combination of submodule revisions, which obviously would be wrong. > > [...] > > So the issue seems to be that the revisions of submodules are not > announced in the hello exchange. Do we all agree with that? yes -- I think I brought up this issue awhile back. A new 'submodule' capability is needed that is simpler than the module capability. ?submodule=foo&module=parent-of-foo&revision=2011-10-29 revision == submodule-revision-date (no submodule features or deviations allowed!) (may want parent-revision in the URL as well) > > And reading /netconf-state/schemas is also not an option to obtain > that information since people really like to have the details in the > exchange. Do we agree with that as well? > yes -- implementing the data structure is optional and cannot be counted on to be present, so is the only reliable option. > /js > Andy From lhotka@cesnet.cz Tue Oct 25 04:34:32 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1521F8B2B for ; Tue, 25 Oct 2011 04:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 8X0Fi3-b-xvB for ; Tue, 25 Oct 2011 04:34:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 93BE221F8B09 for ; Tue, 25 Oct 2011 04:34:31 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id A9F202CDE05C for ; Tue, 25 Oct 2011 13:34:29 +0200 (CEST) Message-ID: <4EA69EC5.2080001@cesnet.cz> Date: Tue, 25 Oct 2011 13:34:29 +0200 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: NETCONF WG References: <20111023195300.GA26734@elstar.local> <4EA47D35.4000209@andybierman.com> <20111023.225937.384150692.mbj@tail-f.com> <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] netconf yang module namespaces X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 11:34:32 -0000 Dne 24.10.2011 23:01, Kent Watsen napsal(a): > This thread appears the same as the one started a few months ago on the netmod list: http://www.ietf.org/mail-archive/web/netmod/current/msg05931.html. > > That thread peters out, but I maintain that YANG unnecessarily imposes a technical constraint that could've been handled by a maintainer of multiple YANG modules (such as this group). > > All we'd need to do is change section 5.3 from: > > All YANG definitions are specified within a module that is bound to a > particular XML namespace [XML-NAMES], which is a globally unique URI > [RFC3986]. > > To: > > All YANG definitions are specified within a module that is bound to > a particular XML namespace [XML-NAMES]. Multiple YANG modules MAY > share a namespace but, to guarantee no namespace collisions, each > YANG module SHOULD have a unique XML namespace. > > This would be a backwards-compatible change to the spec. So what would you do with prefixes? Do you want to allow each of the namespace-sharing modules to define a different prefix? I don't want to open this can of worms. Why is it a problem to choose a separate URI for each module if the module names are already different? Lada > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Oct 25 12:31:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B3221F891D for ; Tue, 25 Oct 2011 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 1yjqhzqHzywR for ; Tue, 25 Oct 2011 12:30:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF221F88A0 for ; Tue, 25 Oct 2011 12:30:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02DD320C7D for ; Tue, 25 Oct 2011 21:30:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x3Ya_b2xsUFw; Tue, 25 Oct 2011 21:30:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AFA8320C04; Tue, 25 Oct 2011 21:30:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 368841B3A186; Tue, 25 Oct 2011 21:30:39 +0200 (CEST) Date: Tue, 25 Oct 2011 21:30:39 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20111025193039.GA33471@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] sdn bof in taipei X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:31:00 -0000 Hi, there is a BoF on Software Driven Networks (sdn) in Taipei (Thursday 17:40-19:40) which seems to be related to what has been discussed under the phrase "network-wide configuration" a while ago on this list and in the hallways. I am sending this simply to make everyone aware of this BoF happening at Taipei. For additional information, see . /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Tue Oct 25 12:34:03 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9B221F8AAA for ; Tue, 25 Oct 2011 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 v4pin+dJlW8O for ; Tue, 25 Oct 2011 12:34:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A7B5F21F8A80 for ; Tue, 25 Oct 2011 12:33:55 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9PJXsQ8013730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Oct 2011 21:33:54 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9PJXrYZ005892 for ; Tue, 25 Oct 2011 21:33:53 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.17]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 21:33:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC934D.07807C50" Date: Tue, 25 Oct 2011 21:33:52 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402DED148@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder: Security Advisor review PLEASE for draft-ietf-netconf-access-control-05.txt Thread-Index: AcyTG8o683fzcu+3TRq6lDQrXGX/zwAMDmTg From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 25 Oct 2011 19:33:53.0584 (UTC) FILETIME=[07948300:01CC934D] Subject: [Netconf] FW: Reminder: Security Advisor review PLEASE for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:34:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC934D.07807C50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, attached are the comments of the Security ADs acting as security advisors.=20 Mehmet=20 -----Original Message----- From: ext Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Tuesday, October 25, 2011 3:41 PM To: Bert Wijnen (IETF) Cc: Sean Turner; Romascanu, Dan (Dan); Ersue, Mehmet (NSN - DE/Munich); Andy Bierman; Martin Bjorklund Subject: Re: Reminder: Security Advisor review PLEASE for draft-ietf-netconf-access-control-05.txt Hi Bert, So Sean and I looked at this and we both think its on the right track so there's certainly no major huge problem looming. Being a bit more anal about things in general, I wrote some notes (attached) that might be useful. We can chat about those if you like. Note: I'm not saying that any or all of those would or would not turn into discusses so treating 'em as early last-call feedback is probably about right. Cheers, S. On 10/20/2011 01:45 PM, Bert Wijnen (IETF) wrote: > OK, great. > WG last call ends this weekdn. > > I herewith ask the authors/editors to wait for your > comments as well. I trust that we will see them by Tuesday > then. > > Thanks, > Bert > document shepherd > > On 10/20/11 2:38 PM, Stephen Farrell wrote: >> >> Hi Bert, >> >> Sean's done. I'm not. We're gonna talk about it Tuesday >> (after I've had a read) and get back to you then. >> >> Sorry for being the slow coach here;-) >> >> S. >> >> On 10/20/2011 01:33 PM, Bert Wijnen (IETF) wrote: >>> Hi Sean and Stephen, >>> >>> how are you doing on your review? >>> >>> >>> Thanks, >>> Bert >>> document shepherd >>> >>> On 10/5/11 5:12 PM, Bert Wijnen (IETF) wrote: >>>> Great (well the fact that you and Stephen will take a >>>> look next week, not that fact that you could not find >>>> any takers). Looking forward to any comments you may have. >>>> >>>> Bert >>>> >>>> On 10/5/11 4:50 PM, Sean Turner wrote: >>>>> We tried to rope in an additional reviewer. We got no takers. Stephen >>>>> and I will have a look next week. >>>>> >>>>> spt >>>>> >>>>> On 10/5/11 7:55 AM, Bert Wijnen (IETF) wrote: >>>>>> On 9/21/11 4:57 PM, Sean Turner wrote: >>>>>>> We're going to search for a new advisor. >>>>>> >>>>>>> If we can't find one, we'll get the SECDIR secretary to assign an >>>>>>> early reviewer. >>>>>>> >>>>>>> spt >>>>>>> >>>>>> >>>>>> So, a revised version of the document is out (trying to address >>>>>> all previous WGLC comments). We as WG chairs have put out a new >>>>>> WG Last Call for draft-ietf-netconf-access-control-05.txt >>>>>> which runs till Okt 21st 2011. >>>>>> >>>>>> After that finishes we expect to soon request our AD for >>>>>> an IETF Last Call to consider this document for PS. >>>>>> >>>>>> So review by a SEC advisor or early review by a SEC Area >>>>>> reviewer would be very much appreciated. The whole document >>>>>> is about security for Access Control to NetConf operations and data. >>>>>> >>>>>> Bert and Mehmet >>>>>> Netconf WG chairs. >>>>>> >>>>>> >>>>> >>>> >> ------_=_NextPart_001_01CC934D.07807C50 Content-Type: text/plain; name="netconf-access-05.cmt" Content-Transfer-Encoding: base64 Content-Description: netconf-access-05.cmt Content-Disposition: attachment; filename="netconf-access-05.cmt" DQpkcmFmdC1pZXRmLW5ldGNvbmYtYWNjZXNzLWNvbnRyb2wtMDUgY29tbWVudHMNClNGLCAyMDEx LTEwLTI0DQoNCkdlbmVyYWwgcXVlc3Rpb25zOg0KDQoxKSBIb3cgZG8geW91IGNvbnRvbCBhY2Nl c3Mgd2hlbiBhIHJ1bGUtc2V0IGlzIG1hbmFnZWQgYnkgQWxpY2UgYnV0DQpCb2IgdXBkYXRlcyB0 aGUgc2VydmVyIGNvZGUgdG8gZGVwbG95IG5ldyBwcm90b2NvbCBvcGVyYXRpb25zPyBEb2VzDQpp dCBzYXkgc29tZXdoZXJlIHRoYXQgQWxpY2UgYW5kIEJvYiBuZWVkIHRvIHRhbGs/IE9yIG1heWJl IHRoYXQNCkJvYidzIG5ldyBjb2RlIHNob3VsZCBmaWd1cmUgaXRzIHJ1bm5pbmcgZm9yIHRoZSAx c3QgdGltZSB3aXRoIGFuDQpleGlzdGluZyBjb25maWcgYW5kIHNlbmQgc29tZSBraW5kIG9mIG5v dGlmaWNhdGlvbiwgYW5kIHNob3VsZA0KQWxpY2UncyBjb25maWcgaW5jbHVkZSBzb21ldGhpbmcg dG8gc2F5IHdoZXJlPyANCg0KMikgRG8geW91IG5lZWQgdG8gaGF2ZSBhbnkgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgYWJvdXQgb2RkDQp1c2VybmFtZSBzdHJpbmdzLCBlLmcuIHdvdWxkIGl0IGJl IHBvc3NpYmxlIHRvIGF1dGhlbnRpY2F0ZSBhcw0KInN0ZXBoZW5cMGZhcnJlbGxAdGNkLmllIiBh bmQgZm9yIGFuIGFjY2VzcyBjb250cm9sIGltcGxlbWVudGF0aW9uDQp0byB0cmVhdCBtZSBhcyAi c3RlcGhlbiI/DQoNCm90aGVyIGNvbW1lbnRzDQoNCi0gYmUgZ29vZCBpZiAxc3Qgc2VudGVuY2Ug b2YgMi4yIGhhZCBhIHJlZmVyZW5jZSBidXQgSSB1bmRlcnN0YW5kDQp3aHkgeW91IG1pZ2h0IGJl IHNoeSAtIHRoZSBYLjUwMCBhY2Nlc3MgY29udHJvbCBzY2hlbWUgaG93ZXZlciBtYXkNCmJlIGZh aXIgZ2FtZTotKQ0KDQotICh0b3RhbCBuaXQpICJNVVNUIGJlIGF1dGhvcml6ZWQiIG5lYXIgdG9w IG9mIHAxMyBpcyBhbWJpZ3VvdXMuICBJdA0KY291bGQgbWVhbiB5b3UgIk1VU1QgbGV0IGl0IGhh cHBlbiIgb3IgKHRoZSBhY3R1YWwgaW50ZW50IEkgYXNzdW1lKQ0KIk1VU1QgYmUgY2hlY2tlZCIN Cg0KLSAzLjIgc2F5cyB0aGF0IGxvY2FsL3JlbW90ZSBmaWxlIGFjY2VzcyB2aWEgVVJMcyBpcyAi b3B0aW9uYWwgdG8NCnN1cHBvcnQuIiBhKSB3aGF0IGRvZXMgdGhhdCBtZWFuPyB0aGF0IGJlaW5n IGFibGUgdG8gcXVlcnkvcmV0dXJuIGENCmZpbGUgaXMgT1BUSU9OQUwgb3IgdGhhdCBhcHBseWlu ZyB0aGUgYWNjZXNzIGNvbnRyb2wgbW9kZWwgaXMNCk9QVElPTkFMPyAgYikgc2hvdWxkbid0IHRo ZXJlIGJlIHNvbWUgMjExOSBsYW5ndWFnZSB0aGVyZT8NCg0KLSBJIGRpZG4ndCBnZXQgdGhlIDJu ZCBwYXJhIG9mIDMuMi4zIGJ1dCBJIGV4cGVjdCB0aGF0J3MganVzdCBhIGxhY2sNCm9mIGJhY2tn cm91bmQuIEkgZ3Vlc3MgaW4gbXkgaWdub3JhbmNlIEknZCB3b25kZXIgaWYgdGhlcmUgYXJlIGFu eQ0Kb3BlcmF0aW9ucyB3aXRoIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUgdGhhdCBhcmUgYWN0dWFs bHkgc2Vuc2l0aXZlIC0NCmlmIHNvLCB0aGVuIG5vdCBkb2luZyBhY2Nlc3MgY29udHJvbCBtaWdo dCBiZSBiYWQuIENhbiB5b3UgY29uZmlybQ0KdGhhdCB0aGVyZSBhcmUgbm8gc3VjaCBvcGVyYXRp b25zPw0KDQotIDMuMi4zIDNyZCBsYXN0IHBhcmE6IElmIEkgaGFkIGEgY29udGFpbmVyIGNhbGxl ZCAiYmFnT2ZTdHVmZiIgdGhhdA0KaGFzIHdpdGhpbiBpdCAid2hvQ2FyZXMiIChub3Qgc2Vuc2l0 aXZlKSBhbmQgInZlcnlJbXBvcnRhbnQiDQooc2Vuc2l0aXZlKSBhbmQgdGhlcmUncyBhbiBBQ0wg dGhhdCBhbGxvd3MgbWUgZnVsbCBhY2Nlc3MgdG8NCmV2ZXJ5aGluZyBpbiBiYWdPZlN0dWZmIGV4 Y2VwdCB2ZXJ5SW1wb3J0YW50IGJ1dCB0aGVyZSdzIGFub3RoZXIgQUNMDQp0aGF0IGdpdmVzIG1l IGZ1bGwgYWNjZXNzIHRvICJub0JvZHlDYXJlcy8qIiB0aGVuIGNvdWxkIEkgcmVuYW1lDQpiYWdP ZlN0dWZmIHRvIG5vQm9keUNhcmVzL2JhZ09mU3R1ZmYgYW5kIHRoZW5jZSBnZXQgYWNjZXNzIHRv DQp2ZXJ5SW1wb3J0YW50PyAgDQoNCi0gMy4zLjIgLSBhcmUgR3JvdXAgbmFtZXMgZXZlciBzZW50 IG92ZXIgdGhlIHdpcmU/IElmIHNvLCBob3cncmUNCnRoZXkgaGFuZGxlZC9lbmNvZGVkPyAoIkFk bWluaXN0ZXJ1bmciIHZzLiAiQWRtaW5pc3RyYXRvcnMiIHdhcyBhbg0Kb2xkIG1zZnQgZ2xpdGNo Oy0pIElmIHRoZXkncmUgbm90IHNlbnQgb3ZlciB0aGUgd2lyZSwgdGhlbiBtYXliZQ0Kc2F5aW5n IHRoYXQgd2lsbCBmZW5kIG9mZiBzb21lIEkxOE4gZGlzY3Vzc2VzIHNvIG1pZ2h0IGJlIHdvcnRo IGl0Lg0KDQotIDMuMy4zLjEgLSBJIGFzc3VtZSBzZXR0aW5nIGVuYWJsZS1uYWNtPWZhbHNlIGlz IHByb3RlY3RlZCwgcmlnaHQ/DQoNCi0gV2hhdCBpcyB0aGUgImFjbWUgTlMiIGluIEZpZ3VyZSAz Pw0KDQotIEluIDMuNC40IGRvIHlvdSBuZWVkIHRvIHNheSB0aGF0IHRoaXMgYWxnb3JpdGhtIE1V U1QgYmUgc2VwYXJhdGVseQ0KcnVuIGZvciBlYWNoIDxycGM+IGVsZW1lbnQgaW4gYSByZWNlaXZl ZCByZXF1ZXN0PyAgVGhlIGNvbmNlcm4gd291bGQNCmJlIHNvbWVvbmUgc2VuZGluZyBhIHNpbmds ZSBwYWNrZXQgbWVhbmluZyAiY2xvc2Utc2Vzc2lvbiB0aGVuDQpvcGVuLXNlc3Npb24mZG8tYmFk LXRoaW5nIiAtIGlmIHRoZSBtZXNzYWdlIGhhbmRsZXIgb25seSBsb29rZWQgYXQNCnRoZSBzdGFy dCBvZiB0aGUgbWVzc2FnZSB0aGVuIGl0J2QgZG8gdGhlIHdyb25nIHRoaW5nLiBUaGF0IG1pZ2h0 IGJlDQpoYW5kbGVkIGVsc2V3aGVyZSBidXQgbWlnaHQgc3RpbGwgYmUgd29ydGggc3RhdGluZyB0 byBoZWxwIGNvZGVycy4NCihBbmQgInZhbGlkYXRlcyB0aGUgPHJwYz4gZWxlbWVudCIgbWlnaHQg bm90IGJlIHF1aXRlIHNwZWNpZmljDQplbm91Z2ggcGVyaGFwcy4pDQoNCi0gSW4gMy40LjQgaXRz IG5vdCBjbGVhciB0byBtZSBob3cgdGhlICJ0cmFuc3BvcnQgbGF5ZXIiIGNhbiBwcm92aWRlDQpn cm91cCBtZW1iZXJzaGlwcyAtIGRpZCBJIG1pc3MgdGhhdD8NCg0KLSBJbiAzLjQuNCwgbWF5YmUg SSdtIGNvbmZ1c2VkIGJ1dCBza2lwcGluZyBmcm9tIHN0ZXAgNSB0byAxMCBmb3IgYQ0KdXNlciB3 aG8ncyBhIG1lbWJlciBvZiBubyBncm91cHMgc2VlbXMgdG8gbWVhbiB0aGF0IHJ1bGVzIGNhbiBv bmx5DQpiZSBkZWZpbmVkIGZvciBnb3VwcyAtIGlzIHRoYXQgcmlnaHQ/IChTYW1lIHF1ZXN0aW9u IGxhdGVyIGFzIHdlbGwNCmluIDMuNC41KQ0KDQotIEkgZG9uJ3QgZ2V0IHdoYXQgc2Vzc2lvbiBp cyB1c2VkIGluIDMuNC42PyAoQ29uZnVzZWQgYWdhaW46LSkNCg0KLSBJIGp1c3QgZmxpY2tlZCBx dWlja2x5IHRocm91Z2ggMy41LjIgc2luY2UgSSdtIG5vIFlBTkcgZXhwZXJ0Oy0pDQoNCi0gMy43 LjEgLSBzL290IGl0L29yIGl0Lz8NCg0KLSBJIGRpZG4ndCBnbyB0aHJvdWdoIGFwcGVuZGl4IEEg cmVhbGx5Lg0K ------_=_NextPart_001_01CC934D.07807C50-- From bertietf@bwijnen.net Tue Oct 25 14:24:01 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A77821F8610 for ; Tue, 25 Oct 2011 14:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] 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 5NiaFx8aSKRD for ; Tue, 25 Oct 2011 14:24:00 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 75E1F21F85AE for ; Tue, 25 Oct 2011 14:23:58 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1RIoTO-00054c-R2; Tue, 25 Oct 2011 23:23:51 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Tue, 25 Oct 2011 23:15:04 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: Sean Turner , Stephen Farrell Subject: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 21:24:01 -0000 Editors/authors, pls take a look at these and make changes as you see fit. If there is anything that you think we need to get WG concensus on, pls let me know. I still have to read/check the details myself, wanted to send this to WG list asap. Bert ---------------------------- draft-ietf-netconf-access-control-05 comments SF, 2011-10-24 General questions: 1) How do you contol access when a rule-set is managed by Alice but Bob updates the server code to deploy new protocol operations? Does it say somewhere that Alice and Bob need to talk? Or maybe that Bob's new code should figure its running for the 1st time with an existing config and send some kind of notification, and should Alice's config include something to say where? 2) Do you need to have any security considerations about odd username strings, e.g. would it be possible to authenticate as "stephen\0farrell@tcd.ie" and for an access control implementation to treat me as "stephen"? other comments - be good if 1st sentence of 2.2 had a reference but I understand why you might be shy - the X.500 access control scheme however may be fair game:-) - (total nit) "MUST be authorized" near top of p13 is ambiguous. It could mean you "MUST let it happen" or (the actual intent I assume) "MUST be checked" - 3.2 says that local/remote file access via URLs is "optional to support." a) what does that mean? that being able to query/return a file is OPTIONAL or that applying the access control model is OPTIONAL? b) shouldn't there be some 2119 language there? - I didn't get the 2nd para of 3.2.3 but I expect that's just a lack of background. I guess in my ignorance I'd wonder if there are any operations with default-operation=none that are actually sensitive - if so, then not doing access control might be bad. Can you confirm that there are no such operations? - 3.2.3 3rd last para: If I had a container called "bagOfStuff" that has within it "whoCares" (not sensitive) and "veryImportant" (sensitive) and there's an ACL that allows me full access to everyhing in bagOfStuff except veryImportant but there's another ACL that gives me full access to "noBodyCares/*" then could I rename bagOfStuff to noBodyCares/bagOfStuff and thence get access to veryImportant? - 3.3.2 - are Group names ever sent over the wire? If so, how're they handled/encoded? ("Administerung" vs. "Administrators" was an old msft glitch;-) If they're not sent over the wire, then maybe saying that will fend off some I18N discusses so might be worth it. - 3.3.3.1 - I assume setting enable-nacm=false is protected, right? - What is the "acme NS" in Figure 3? - In 3.4.4 do you need to say that this algorithm MUST be separately run for each element in a received request? The concern would be someone sending a single packet meaning "close-session then open-session&do-bad-thing" - if the message handler only looked at the start of the message then it'd do the wrong thing. That might be handled elsewhere but might still be worth stating to help coders. (And "validates the element" might not be quite specific enough perhaps.) - In 3.4.4 its not clear to me how the "transport layer" can provide group memberships - did I miss that? - In 3.4.4, maybe I'm confused but skipping from step 5 to 10 for a user who's a member of no groups seems to mean that rules can only be defined for goups - is that right? (Same question later as well in 3.4.5) - I don't get what session is used in 3.4.6? (Confused again:-) - I just flicked quickly through 3.5.2 since I'm no YANG expert;-) - 3.7.1 - s/ot it/or it/? - I didn't go through appendix A really. ----- Original Message ----- From: "Stephen Farrell" To: "Bert Wijnen (IETF)" Cc: "Sean Turner" ; "Romascanu, Dan (Dan)" ; "Ersue, Mehmet (NSN - DE/Munich)" ; "Andy Bierman" ; "Martin Bjorklund" Sent: Tuesday, October 25, 2011 3:41 PM Subject: Re: Reminder: Security Advisor review PLEASE for draft-ietf-netconf-access-control-05.txt > > Hi Bert, > > So Sean and I looked at this and we both think its > on the right track so there's certainly no major huge > problem looming. > > Being a bit more anal about things in general, I wrote > some notes (attached) that might be useful. We can chat > about those if you like. Note: I'm not saying that any > or all of those would or would not turn into discusses > so treating 'em as early last-call feedback is probably > about right. > > Cheers, > S. > > On 10/20/2011 01:45 PM, Bert Wijnen (IETF) wrote: >> OK, great. >> WG last call ends this weekdn. >> >> I herewith ask the authors/editors to wait for your >> comments as well. I trust that we will see them by Tuesday >> then. >> >> Thanks, >> Bert >> document shepherd >> >> On 10/20/11 2:38 PM, Stephen Farrell wrote: >>> >>> Hi Bert, >>> >>> Sean's done. I'm not. We're gonna talk about it Tuesday >>> (after I've had a read) and get back to you then. >>> >>> Sorry for being the slow coach here;-) >>> >>> S. >>> >>> On 10/20/2011 01:33 PM, Bert Wijnen (IETF) wrote: >>>> Hi Sean and Stephen, >>>> >>>> how are you doing on your review? >>>> >>>> >>>> Thanks, >>>> Bert >>>> document shepherd >>>> >>>> On 10/5/11 5:12 PM, Bert Wijnen (IETF) wrote: >>>>> Great (well the fact that you and Stephen will take a >>>>> look next week, not that fact that you could not find >>>>> any takers). Looking forward to any comments you may have. >>>>> >>>>> Bert >>>>> >>>>> On 10/5/11 4:50 PM, Sean Turner wrote: >>>>>> We tried to rope in an additional reviewer. We got no takers. Stephen >>>>>> and I will have a look next week. >>>>>> >>>>>> spt >>>>>> >>>>>> On 10/5/11 7:55 AM, Bert Wijnen (IETF) wrote: >>>>>>> On 9/21/11 4:57 PM, Sean Turner wrote: >>>>>>>> We're going to search for a new advisor. >>>>>>> >>>>>>>> If we can't find one, we'll get the SECDIR secretary to assign an >>>>>>>> early reviewer. >>>>>>>> >>>>>>>> spt >>>>>>>> >>>>>>> >>>>>>> So, a revised version of the document is out (trying to address >>>>>>> all previous WGLC comments). We as WG chairs have put out a new >>>>>>> WG Last Call for draft-ietf-netconf-access-control-05.txt >>>>>>> which runs till Okt 21st 2011. >>>>>>> >>>>>>> After that finishes we expect to soon request our AD for >>>>>>> an IETF Last Call to consider this document for PS. >>>>>>> >>>>>>> So review by a SEC advisor or early review by a SEC Area >>>>>>> reviewer would be very much appreciated. The whole document >>>>>>> is about security for Access Control to NetConf operations and data. >>>>>>> >>>>>>> Bert and Mehmet >>>>>>> Netconf WG chairs. >>>>>>> >>>>>>> >>>>>> >>>>> >>> > From ietf@andybierman.com Wed Oct 26 10:05:16 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D11B21F8AFB for ; Wed, 26 Oct 2011 10:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] 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 pIxX0k8nJe30 for ; Wed, 26 Oct 2011 10:05:15 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6D15F21F8783 for ; Wed, 26 Oct 2011 10:05:15 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id p9QH5BcC032418 for ; Wed, 26 Oct 2011 13:05:14 -0400 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:39352] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0C/D1-04874-6CD38AE4; Wed, 26 Oct 2011 13:05:11 -0400 Message-ID: <4EA83E05.6040000@andybierman.com> Date: Wed, 26 Oct 2011 10:06:13 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sean Turner , Netconf , Stephen Farrell Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:05:16 -0000 On 10/25/2011 02:15 PM, Bert Wijnen (IETF) wrote: > Editors/authors, pls take a look at these and make changes as > you see fit. If there is anything that you think we need > to get WG concensus on, pls let me know. I still have to read/check > the details myself, wanted to send this to WG list asap. > We will discuss it and have a NACM update done soon. See inline for some more comments. > Bert > ---------------------------- > draft-ietf-netconf-access-control-05 comments > SF, 2011-10-24 > > General questions: > > 1) How do you contol access when a rule-set is managed by Alice but > Bob updates the server code to deploy new protocol operations? Does > it say somewhere that Alice and Bob need to talk? Or maybe that > Bob's new code should figure its running for the 1st time with an > existing config and send some kind of notification, and should > Alice's config include something to say where? > A different NETCONF draft specifies the notifications to send when a config datastore is changed. Bob and Alice have to coordinate off-line wrt/ specific device configuration changes, and their impact on access control config. (This is no different than when I have to go through Engineering Lab Services at work to get a new server setup in the lab net -- you have some off-line mechanism to request that an authorized user make the config changes.) > 2) Do you need to have any security considerations about odd > username strings, e.g. would it be possible to authenticate as > "stephen\0farrell@tcd.ie" and for an access control implementation > to treat me as "stephen"? NACM sort of punts the username management corner-cases to the administrator. They have to make sure all user names resolve to unique and correct NETCONF user names. > > other comments > We will go through these and fix the draft as needed. > - be good if 1st sentence of 2.2 had a reference but I understand > why you might be shy - the X.500 access control scheme however may > be fair game:-) > > - (total nit) "MUST be authorized" near top of p13 is ambiguous. It > could mean you "MUST let it happen" or (the actual intent I assume) > "MUST be checked" > > - 3.2 says that local/remote file access via URLs is "optional to > support." a) what does that mean? that being able to query/return a > file is OPTIONAL or that applying the access control model is > OPTIONAL? b) shouldn't there be some 2119 language there? > > - I didn't get the 2nd para of 3.2.3 but I expect that's just a lack > of background. I guess in my ignorance I'd wonder if there are any > operations with default-operation=none that are actually sensitive - > if so, then not doing access control might be bad. Can you confirm > that there are no such operations? > > - 3.2.3 3rd last para: If I had a container called "bagOfStuff" that > has within it "whoCares" (not sensitive) and "veryImportant" > (sensitive) and there's an ACL that allows me full access to > everyhing in bagOfStuff except veryImportant but there's another ACL > that gives me full access to "noBodyCares/*" then could I rename > bagOfStuff to noBodyCares/bagOfStuff and thence get access to > veryImportant? > > - 3.3.2 - are Group names ever sent over the wire? If so, how're > they handled/encoded? ("Administerung" vs. "Administrators" was an > old msft glitch;-) If they're not sent over the wire, then maybe > saying that will fend off some I18N discusses so might be worth it. > > - 3.3.3.1 - I assume setting enable-nacm=false is protected, right? > > - What is the "acme NS" in Figure 3? > > - In 3.4.4 do you need to say that this algorithm MUST be separately > run for each element in a received request? The concern would > be someone sending a single packet meaning "close-session then > open-session&do-bad-thing" - if the message handler only looked at > the start of the message then it'd do the wrong thing. That might be > handled elsewhere but might still be worth stating to help coders. > (And "validates the element" might not be quite specific > enough perhaps.) > > - In 3.4.4 its not clear to me how the "transport layer" can provide > group memberships - did I miss that? > > - In 3.4.4, maybe I'm confused but skipping from step 5 to 10 for a > user who's a member of no groups seems to mean that rules can only > be defined for goups - is that right? (Same question later as well > in 3.4.5) > > - I don't get what session is used in 3.4.6? (Confused again:-) > > - I just flicked quickly through 3.5.2 since I'm no YANG expert;-) > > - 3.7.1 - s/ot it/or it/? > > - I didn't go through appendix A really. > > ----- Original Message ----- From: "Stephen Farrell" > To: "Bert Wijnen (IETF)" > Cc: "Sean Turner" ; "Romascanu, Dan (Dan)" ; "Ersue, Mehmet (NSN - DE/Munich)" ; "Andy Bierman" ; "Martin Bjorklund" > > Sent: Tuesday, October 25, 2011 3:41 PM > Subject: Re: Reminder: Security Advisor review PLEASE for draft-ietf-netconf-access-control-05.txt > > >> >> Hi Bert, >> >> So Sean and I looked at this and we both think its >> on the right track so there's certainly no major huge >> problem looming. >> >> Being a bit more anal about things in general, I wrote >> some notes (attached) that might be useful. We can chat >> about those if you like. Note: I'm not saying that any >> or all of those would or would not turn into discusses >> so treating 'em as early last-call feedback is probably >> about right. >> >> Cheers, >> S. >> >> On 10/20/2011 01:45 PM, Bert Wijnen (IETF) wrote: >>> OK, great. >>> WG last call ends this weekdn. >>> >>> I herewith ask the authors/editors to wait for your >>> comments as well. I trust that we will see them by Tuesday >>> then. >>> >>> Thanks, >>> Bert >>> document shepherd >>> >>> On 10/20/11 2:38 PM, Stephen Farrell wrote: >>>> >>>> Hi Bert, >>>> >>>> Sean's done. I'm not. We're gonna talk about it Tuesday >>>> (after I've had a read) and get back to you then. >>>> >>>> Sorry for being the slow coach here;-) >>>> >>>> S. >>>> >>>> On 10/20/2011 01:33 PM, Bert Wijnen (IETF) wrote: >>>>> Hi Sean and Stephen, >>>>> >>>>> how are you doing on your review? >>>>> >>>>> >>>>> Thanks, >>>>> Bert >>>>> document shepherd >>>>> >>>>> On 10/5/11 5:12 PM, Bert Wijnen (IETF) wrote: >>>>>> Great (well the fact that you and Stephen will take a >>>>>> look next week, not that fact that you could not find >>>>>> any takers). Looking forward to any comments you may have. >>>>>> >>>>>> Bert >>>>>> >>>>>> On 10/5/11 4:50 PM, Sean Turner wrote: >>>>>>> We tried to rope in an additional reviewer. We got no takers. Stephen >>>>>>> and I will have a look next week. >>>>>>> >>>>>>> spt >>>>>>> >>>>>>> On 10/5/11 7:55 AM, Bert Wijnen (IETF) wrote: >>>>>>>> On 9/21/11 4:57 PM, Sean Turner wrote: >>>>>>>>> We're going to search for a new advisor. >>>>>>>> >>>>>>>>> If we can't find one, we'll get the SECDIR secretary to assign an >>>>>>>>> early reviewer. >>>>>>>>> >>>>>>>>> spt >>>>>>>>> >>>>>>>> >>>>>>>> So, a revised version of the document is out (trying to address >>>>>>>> all previous WGLC comments). We as WG chairs have put out a new >>>>>>>> WG Last Call for draft-ietf-netconf-access-control-05.txt >>>>>>>> which runs till Okt 21st 2011. >>>>>>>> >>>>>>>> After that finishes we expect to soon request our AD for >>>>>>>> an IETF Last Call to consider this document for PS. >>>>>>>> >>>>>>>> So review by a SEC advisor or early review by a SEC Area >>>>>>>> reviewer would be very much appreciated. The whole document >>>>>>>> is about security for Access Control to NetConf operations and data. >>>>>>>> >>>>>>>> Bert and Mehmet >>>>>>>> Netconf WG chairs. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bertietf@bwijnen.net Wed Oct 26 10:16:18 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39FE21F85C7 for ; Wed, 26 Oct 2011 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 coEfMw6u5NjR for ; Wed, 26 Oct 2011 10:16:17 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 08FA621F8797 for ; Wed, 26 Oct 2011 10:16:16 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJ75I-0004Dw-05; Wed, 26 Oct 2011 19:16:13 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJ75H-0003fw-SX; Wed, 26 Oct 2011 19:16:11 +0200 Message-ID: <4EA8405B.5010508@bwijnen.net> Date: Wed, 26 Oct 2011 19:16:11 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4EA83E05.6040000@andybierman.com> In-Reply-To: <4EA83E05.6040000@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a894c8f7cae35f6354b144e885731312 Cc: Sean Turner , Netconf , Stephen Farrell Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:16:18 -0000 On 10/26/11 7:06 PM, Andy Bierman wrote: > > We will discuss it and have a NACM update done soon. > See inline for some more comments. I believe the deadline for revisions of I-Ds is this coming Monday So if you can do it before that time, that would be great. 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. Bert From ietf@andybierman.com Wed Oct 26 10:22:05 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3321F8A58 for ; Wed, 26 Oct 2011 10:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] 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 5SsjfyHyYgQB for ; Wed, 26 Oct 2011 10:22:03 -0700 (PDT) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by ietfa.amsl.com (Postfix) with ESMTP id 50F6821F858D for ; Wed, 26 Oct 2011 10:21:42 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p9QHLd28017578 for ; Wed, 26 Oct 2011 13:21:39 -0400 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43657] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3A/2B-19789-2A148AE4; Wed, 26 Oct 2011 13:21:39 -0400 Message-ID: <4EA841E1.20202@andybierman.com> Date: Wed, 26 Oct 2011 10:22:41 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4EA83E05.6040000@andybierman.com> <4EA8405B.5010508@bwijnen.net> In-Reply-To: <4EA8405B.5010508@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sean Turner , Netconf , Stephen Farrell Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:22:05 -0000 On 10/26/2011 10:16 AM, Bert Wijnen (IETF) wrote: > > > On 10/26/11 7:06 PM, Andy Bierman wrote: >> >> We will discuss it and have a NACM update done soon. >> See inline for some more comments. > > I believe the deadline for revisions of I-Ds is this coming Monday > So if you can do it before that time, that would be great. > of course! May just make the deadline by minutes, though... > 2011-10-31 (Monday): Internet Draft final submission cut-off > by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. > > Bert > > Andy From ietf@andybierman.com Wed Oct 26 11:43:48 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97E321F8562 for ; Wed, 26 Oct 2011 11:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] 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 ZiE38EBllEsz for ; Wed, 26 Oct 2011 11:43:47 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 361AF21F8558 for ; Wed, 26 Oct 2011 11:43:40 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id p9QIhabH015367 for ; Wed, 26 Oct 2011 14:43:39 -0400 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48787] helo=[192.168.0.9]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 15/90-05308-8D458AE4; Wed, 26 Oct 2011 14:43:36 -0400 Message-ID: <4EA85517.3030104@andybierman.com> Date: Wed, 26 Oct 2011 11:44:39 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Stephen Farrell References: <4EA83E05.6040000@andybierman.com> <4EA8509D.2060209@cs.tcd.ie> In-Reply-To: <4EA8509D.2060209@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sean Turner , Netconf Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:43:48 -0000 On 10/26/2011 11:25 AM, Stephen Farrell wrote: > > Hi Andy, > > A few follow-ups below. I don't mind if we try bottom out > on these now or you leave 'em for later - whichever's better > for you/the WG is fine. > > On 10/26/2011 06:06 PM, Andy Bierman wrote: >> On 10/25/2011 02:15 PM, Bert Wijnen (IETF) wrote: >>> Editors/authors, pls take a look at these and make changes as >>> you see fit. If there is anything that you think we need >>> to get WG concensus on, pls let me know. I still have to read/check >>> the details myself, wanted to send this to WG list asap. >>> >> >> We will discuss it and have a NACM update done soon. >> See inline for some more comments. >> >> >>> Bert >>> ---------------------------- >>> draft-ietf-netconf-access-control-05 comments >>> SF, 2011-10-24 >>> >>> General questions: >>> >>> 1) How do you contol access when a rule-set is managed by Alice but >>> Bob updates the server code to deploy new protocol operations? Does >>> it say somewhere that Alice and Bob need to talk? Or maybe that >>> Bob's new code should figure its running for the 1st time with an >>> existing config and send some kind of notification, and should >>> Alice's config include something to say where? >> >> A different NETCONF draft specifies the notifications to send when >> a config datastore is changed. Bob and Alice have to coordinate off-line >> wrt/ specific device configuration changes, and their impact on access >> control config. >> (This is no different than when I have to go through Engineering Lab >> Services at work >> to get a new server setup in the lab net -- you have some off-line >> mechanism >> to request that an authorized user make the config changes.) > > Not sure if I was clear enough in the question but that maybe > (partly) answers a slightly different question. > > My question related to when the server code changes, not > when the config datastore changes. I.e. Alice does the datastore > admin but Bob installs new server code. > > The danger there is that the new server code has some new > feature that's accessible according to the existing config > (due to some wildcard or whatever) but that ought not be. Say > that the current config says that "foo/*" is accessible > to the world, because that's ok with the current s/w, but the > s/w update creates a new "foo/explode" knob that kills > something. With the new s/w and the current config, "foo/explode" > would, I think, also be world accessible, which could be bad, > depending what explode means. > > Since its (I think) impossible to automatically handle that > in general, the question is whether you might recommend that > the new code notify Alice when first run. > > That notification I've in mind might say something like "Hi > Alice, Version 2.10 of has just started running on > node for the first time, (previously version 2.8). You may > need to update your config, see ." > > I'm not asking that you definitely do that, but really whether > you've thought about that, because that wasn't clear to me > reading the draft. > I will add something to the SC section that warns administrators that changing software images, and perhaps other mechanisms, can alter the NETCONF content available to a given user, and care must be taken to insure no unintended access is allowed. NETCONF messages contain a URI summary of all the content supported by the server, called the server capabilities. The system notifications also has capability change events. If a new image or current image has any different data models or capabilities than it did before, the client can know about it via NETCONF netconf-capability-changed notifications. Implementation of the system notifications draft is not coupled to NACM in any way. I can add text that suggests this draft is implemented to warn administrators of security threats due to changing capabilities. >>> 2) Do you need to have any security considerations about odd >>> username strings, e.g. would it be possible to authenticate as >>> "stephen\0farrell@tcd.ie" and for an access control implementation >>> to treat me as "stephen"? >> >> NACM sort of punts the username management corner-cases to the >> administrator. >> They have to make sure all user names resolve to uique and correct NETCONF >> user names. > > I'd like to more-than-sort-of understand if the above corner-case > is likely to be a gotcha or not;-) That basic trick was used in X.509 > certs for web sites in the wild and worked in some places for some > time. It might well be that any change needed isn't for this spec > but the problem might hit when you do access control so it may well > be worth a reference to the relevant part of some other netconf > spec from this one, or to just warn about the need to ensure that > the identifiers use in access control are the right ones as a > security consideration, with an example like the above (if it is > a real potential vulnerability). We will try to add some security consideration text emphasizing this sort of user identity management issue. > > Cheer, > S. > >> Andy >>> >>> other comments >>> >> >> We will go through these and fix the draft as needed. >> >> >>> - be good if 1st sentence of 2.2 had a reference but I understand >>> why you might be shy - the X.500 access control scheme however may >>> be fair game:-) >>> >>> - (total nit) "MUST be authorized" near top of p13 is ambiguous. It >>> could mean you "MUST let it happen" or (the actual intent I assume) >>> "MUST be checked" >>> >>> - 3.2 says that local/remote file access via URLs is "optional to >>> support." a) what does that mean? that being able to query/return a >>> file is OPTIONAL or that applying the access control model is >>> OPTIONAL? b) shouldn't there be some 2119 language there? >>> >>> - I didn't get the 2nd para of 3.2.3 but I expect that's just a lack >>> of background. I guess in my ignorance I'd wonder if there are any >>> operations with default-operation=none that are actually sensitive - >>> if so, then not doing access control might be bad. Can you confirm >>> that there are no such operations? >>> >>> - 3.2.3 3rd last para: If I had a container called "bagOfStuff" that >>> has within it "whoCares" (not sensitive) and "veryImportant" >>> (sensitive) and there's an ACL that allows me full access to >>> everyhing in bagOfStuff except veryImportant but there's another ACL >>> that gives me full access to "noBodyCares/*" then could I rename >>> bagOfStuff to noBodyCares/bagOfStuff and thence get access to >>> veryImportant? >>> >>> - 3.3.2 - are Group names ever sent over the wire? If so, how're >>> they handled/encoded? ("Administerung" vs. "Administrators" was an >>> old msft glitch;-) If they're not sent over the wire, then maybe >>> saying that will fend off some I18N discusses so might be worth it. >>> >>> - 3.3.3.1 - I assume setting enable-nacm=false is protected, right? >>> >>> - What is the "acme NS" in Figure 3? >>> >>> - In 3.4.4 do you need to say that this algorithm MUST be separately >>> run for each element in a received request? The concern would >>> be someone sending a single packet meaning "close-session then >>> open-session&do-bad-thing" - if the message handler only looked at >>> the start of the message then it'd do the wrong thing. That might be >>> handled elsewhere but might still be worth stating to help coders. >>> (And "validates the element" might not be quite specific >>> enough perhaps.) >>> >>> - In 3.4.4 its not clear to me how the "transport layer" can provide >>> group memberships - did I miss that? >>> >>> - In 3.4.4, maybe I'm confused but skipping from step 5 to 10 for a >>> user who's a member of no groups seems to mean that rules can only >>> be defined for goups - is that right? (Same question later as well >>> in 3.4.5) >>> >>> - I don't get what session is used in 3.4.6? (Confused again:-) >>> >>> - I just flicked quickly through 3.5.2 since I'm no YANG expert;-) >>> >>> - 3.7.1 - s/ot it/or it/? >>> >>> - I didn't go through appendix A really. >>> >>> ----- Original Message ----- From: "Stephen Farrell" >>> >>> To: "Bert Wijnen (IETF)" >>> Cc: "Sean Turner" ; "Romascanu, Dan (Dan)" >>> ; "Ersue, Mehmet (NSN - DE/Munich)" >>> ; "Andy Bierman" ; "Martin >>> Bjorklund" >>> >>> Sent: Tuesday, October 25, 2011 3:41 PM >>> Subject: Re: Reminder: Security Advisor review PLEASE for >>> draft-ietf-netconf-access-control-05.txt >>> >>> >>>> >>>> Hi Bert, >>>> >>>> So Sean and I looked at this and we both think its >>>> on the right track so there's certainly no major huge >>>> problem looming. >>>> >>>> Being a bit more anal about things in general, I wrote >>>> some notes (attached) that might be useful. We can chat >>>> about those if you like. Note: I'm not saying that any >>>> or all of those would or would not turn into discusses >>>> so treating 'em as early last-call feedback is probably >>>> about right. >>>> >>>> Cheers, >>>> S. >>>> >>>> On 10/20/2011 01:45 PM, Bert Wijnen (IETF) wrote: >>>>> OK, great. >>>>> WG last call ends this weekdn. >>>>> >>>>> I herewith ask the authors/editors to wait for your >>>>> comments as well. I trust that we will see them by Tuesday >>>>> then. >>>>> >>>>> Thanks, >>>>> Bert >>>>> document shepherd >>>>> >>>>> On 10/20/11 2:38 PM, Stephen Farrell wrote: >>>>>> >>>>>> Hi Bert, >>>>>> >>>>>> Sean's done. I'm not. We're gonna talk about it Tuesday >>>>>> (after I've had a read) and get back to you then. >>>>>> >>>>>> Sorry for being the slow coach here;-) >>>>>> >>>>>> S. >>>>>> >>>>>> On 10/20/2011 01:33 PM, Bert Wijnen (IETF) wrote: >>>>>>> Hi Sean and Stephen, >>>>>>> >>>>>>> how are you doing on your review? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Bert >>>>>>> document shepherd >>>>>>> >>>>>>> On 10/5/11 5:12 PM, Bert Wijnen (IETF) wrote: >>>>>>>> Great (well the fact that you and Stephen will take a >>>>>>>> look next week, not that fact that you could not find >>>>>>>> any takers). Looking forward to any comments you may have. >>>>>>>> >>>>>>>> Bert >>>>>>>> >>>>>>>> On 10/5/11 4:50 PM, Sean Turner wrote: >>>>>>>>> We tried to rope in an additional reviewer. We got no takers. >>>>>>>>> Stephen >>>>>>>>> and I will have a look next week. >>>>>>>>> >>>>>>>>> spt >>>>>>>>> >>>>>>>>> On 10/5/11 7:55 AM, Bert Wijnen (IETF) wrote: >>>>>>>>>> On 9/21/11 4:57 PM, Sean Turner wrote: >>>>>>>>>>> We're going to search for a new advisor. >>>>>>>>>> >>>>>>>>>>> If we can't find one, we'll get the SECDIR secretary to assign an >>>>>>>>>>> early reviewer. >>>>>>>>>>> >>>>>>>>>>> spt >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So, a revised version of the document is out (trying to address >>>>>>>>>> all previous WGLC comments). We as WG chairs have put out a new >>>>>>>>>> WG Last Call for draft-ietf-netconf-access-control-05.txt >>>>>>>>>> which runs till Okt 21st 2011. >>>>>>>>>> >>>>>>>>>> After that finishes we expect to soon request our AD for >>>>>>>>>> an IETF Last Call to consider this document for PS. >>>>>>>>>> >>>>>>>>>> So review by a SEC advisor or early review by a SEC Area >>>>>>>>>> reviewer would be very much appreciated. The whole document >>>>>>>>>> is about security for Access Control to NetConf operations and >>>>>>>>>> data. >>>>>>>>>> >>>>>>>>>> Bert and Mehmet >>>>>>>>>> Netconf WG chairs. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> > > From stephen.farrell@cs.tcd.ie Wed Oct 26 11:25:40 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6F21F8B51 for ; Wed, 26 Oct 2011 11:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 MxjU-JHT+Jj2 for ; Wed, 26 Oct 2011 11:25:39 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28121F8B4E for ; Wed, 26 Oct 2011 11:25:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9D54D153C74; Wed, 26 Oct 2011 19:25:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319653535; bh=1wn7QeQWbG5AWA QyU5JwjAbU5UN6GshBkR3BPN9+7F4=; b=tSiDqLGM1MkyMvs6RhkDkrcKC0czKH Lhy1MvjQFFmFzrhPPupGKtISbb5LaijlGu+xnk0s7ppMlq9IoAz8pBKCDw5GeYd9 zElfCNtfklY90uWfnnkScVcWz2rcgXmc2wLZJTNZXSRFen4vgbfzScT8T0fg/psm BLpT8q4pFDP/8NKRLBW3PPI3786Q2K2CcK3Yi46ABRsEku5qGGB8O5kOA+zu/CCR xRqKKnavhmkIJTgmWRD/nmlNorDNz2lRN2ETU0aMwfAZV4tqrnwcVpcwNZVA4d6i Q/SiHSYZrLBJ2VqT2+8wF/x448aNHj4EPUOl9HNOzWmiprTfGstCyxHw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ldA2UjoINCW1; Wed, 26 Oct 2011 19:25:35 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.22.54]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 01DE3153C73; Wed, 26 Oct 2011 19:25:33 +0100 (IST) Message-ID: <4EA8509D.2060209@cs.tcd.ie> Date: Wed, 26 Oct 2011 19:25:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4EA83E05.6040000@andybierman.com> In-Reply-To: <4EA83E05.6040000@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 Oct 2011 15:14:01 -0700 Cc: Sean Turner , Netconf Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:25:40 -0000 Hi Andy, A few follow-ups below. I don't mind if we try bottom out on these now or you leave 'em for later - whichever's better for you/the WG is fine. On 10/26/2011 06:06 PM, Andy Bierman wrote: > On 10/25/2011 02:15 PM, Bert Wijnen (IETF) wrote: >> Editors/authors, pls take a look at these and make changes as >> you see fit. If there is anything that you think we need >> to get WG concensus on, pls let me know. I still have to read/check >> the details myself, wanted to send this to WG list asap. >> > > We will discuss it and have a NACM update done soon. > See inline for some more comments. > > >> Bert >> ---------------------------- >> draft-ietf-netconf-access-control-05 comments >> SF, 2011-10-24 >> >> General questions: >> >> 1) How do you contol access when a rule-set is managed by Alice but >> Bob updates the server code to deploy new protocol operations? Does >> it say somewhere that Alice and Bob need to talk? Or maybe that >> Bob's new code should figure its running for the 1st time with an >> existing config and send some kind of notification, and should >> Alice's config include something to say where? > > A different NETCONF draft specifies the notifications to send when > a config datastore is changed. Bob and Alice have to coordinate off-line > wrt/ specific device configuration changes, and their impact on access > control config. > (This is no different than when I have to go through Engineering Lab > Services at work > to get a new server setup in the lab net -- you have some off-line > mechanism > to request that an authorized user make the config changes.) Not sure if I was clear enough in the question but that maybe (partly) answers a slightly different question. My question related to when the server code changes, not when the config datastore changes. I.e. Alice does the datastore admin but Bob installs new server code. The danger there is that the new server code has some new feature that's accessible according to the existing config (due to some wildcard or whatever) but that ought not be. Say that the current config says that "foo/*" is accessible to the world, because that's ok with the current s/w, but the s/w update creates a new "foo/explode" knob that kills something. With the new s/w and the current config, "foo/explode" would, I think, also be world accessible, which could be bad, depending what explode means. Since its (I think) impossible to automatically handle that in general, the question is whether you might recommend that the new code notify Alice when first run. That notification I've in mind might say something like "Hi Alice, Version 2.10 of has just started running on node for the first time, (previously version 2.8). You may need to update your config, see ." I'm not asking that you definitely do that, but really whether you've thought about that, because that wasn't clear to me reading the draft. >> 2) Do you need to have any security considerations about odd >> username strings, e.g. would it be possible to authenticate as >> "stephen\0farrell@tcd.ie" and for an access control implementation >> to treat me as "stephen"? > > NACM sort of punts the username management corner-cases to the > administrator. > They have to make sure all user names resolve to uique and correct NETCONF > user names. I'd like to more-than-sort-of understand if the above corner-case is likely to be a gotcha or not;-) That basic trick was used in X.509 certs for web sites in the wild and worked in some places for some time. It might well be that any change needed isn't for this spec but the problem might hit when you do access control so it may well be worth a reference to the relevant part of some other netconf spec from this one, or to just warn about the need to ensure that the identifiers use in access control are the right ones as a security consideration, with an example like the above (if it is a real potential vulnerability). Cheer, S. > >> >> other comments >> > > We will go through these and fix the draft as needed. > > >> - be good if 1st sentence of 2.2 had a reference but I understand >> why you might be shy - the X.500 access control scheme however may >> be fair game:-) >> >> - (total nit) "MUST be authorized" near top of p13 is ambiguous. It >> could mean you "MUST let it happen" or (the actual intent I assume) >> "MUST be checked" >> >> - 3.2 says that local/remote file access via URLs is "optional to >> support." a) what does that mean? that being able to query/return a >> file is OPTIONAL or that applying the access control model is >> OPTIONAL? b) shouldn't there be some 2119 language there? >> >> - I didn't get the 2nd para of 3.2.3 but I expect that's just a lack >> of background. I guess in my ignorance I'd wonder if there are any >> operations with default-operation=none that are actually sensitive - >> if so, then not doing access control might be bad. Can you confirm >> that there are no such operations? >> >> - 3.2.3 3rd last para: If I had a container called "bagOfStuff" that >> has within it "whoCares" (not sensitive) and "veryImportant" >> (sensitive) and there's an ACL that allows me full access to >> everyhing in bagOfStuff except veryImportant but there's another ACL >> that gives me full access to "noBodyCares/*" then could I rename >> bagOfStuff to noBodyCares/bagOfStuff and thence get access to >> veryImportant? >> >> - 3.3.2 - are Group names ever sent over the wire? If so, how're >> they handled/encoded? ("Administerung" vs. "Administrators" was an >> old msft glitch;-) If they're not sent over the wire, then maybe >> saying that will fend off some I18N discusses so might be worth it. >> >> - 3.3.3.1 - I assume setting enable-nacm=false is protected, right? >> >> - What is the "acme NS" in Figure 3? >> >> - In 3.4.4 do you need to say that this algorithm MUST be separately >> run for each element in a received request? The concern would >> be someone sending a single packet meaning "close-session then >> open-session&do-bad-thing" - if the message handler only looked at >> the start of the message then it'd do the wrong thing. That might be >> handled elsewhere but might still be worth stating to help coders. >> (And "validates the element" might not be quite specific >> enough perhaps.) >> >> - In 3.4.4 its not clear to me how the "transport layer" can provide >> group memberships - did I miss that? >> >> - In 3.4.4, maybe I'm confused but skipping from step 5 to 10 for a >> user who's a member of no groups seems to mean that rules can only >> be defined for goups - is that right? (Same question later as well >> in 3.4.5) >> >> - I don't get what session is used in 3.4.6? (Confused again:-) >> >> - I just flicked quickly through 3.5.2 since I'm no YANG expert;-) >> >> - 3.7.1 - s/ot it/or it/? >> >> - I didn't go through appendix A really. >> >> ----- Original Message ----- From: "Stephen Farrell" >> >> To: "Bert Wijnen (IETF)" >> Cc: "Sean Turner" ; "Romascanu, Dan (Dan)" >> ; "Ersue, Mehmet (NSN - DE/Munich)" >> ; "Andy Bierman" ; "Martin >> Bjorklund" >> >> Sent: Tuesday, October 25, 2011 3:41 PM >> Subject: Re: Reminder: Security Advisor review PLEASE for >> draft-ietf-netconf-access-control-05.txt >> >> >>> >>> Hi Bert, >>> >>> So Sean and I looked at this and we both think its >>> on the right track so there's certainly no major huge >>> problem looming. >>> >>> Being a bit more anal about things in general, I wrote >>> some notes (attached) that might be useful. We can chat >>> about those if you like. Note: I'm not saying that any >>> or all of those would or would not turn into discusses >>> so treating 'em as early last-call feedback is probably >>> about right. >>> >>> Cheers, >>> S. >>> >>> On 10/20/2011 01:45 PM, Bert Wijnen (IETF) wrote: >>>> OK, great. >>>> WG last call ends this weekdn. >>>> >>>> I herewith ask the authors/editors to wait for your >>>> comments as well. I trust that we will see them by Tuesday >>>> then. >>>> >>>> Thanks, >>>> Bert >>>> document shepherd >>>> >>>> On 10/20/11 2:38 PM, Stephen Farrell wrote: >>>>> >>>>> Hi Bert, >>>>> >>>>> Sean's done. I'm not. We're gonna talk about it Tuesday >>>>> (after I've had a read) and get back to you then. >>>>> >>>>> Sorry for being the slow coach here;-) >>>>> >>>>> S. >>>>> >>>>> On 10/20/2011 01:33 PM, Bert Wijnen (IETF) wrote: >>>>>> Hi Sean and Stephen, >>>>>> >>>>>> how are you doing on your review? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bert >>>>>> document shepherd >>>>>> >>>>>> On 10/5/11 5:12 PM, Bert Wijnen (IETF) wrote: >>>>>>> Great (well the fact that you and Stephen will take a >>>>>>> look next week, not that fact that you could not find >>>>>>> any takers). Looking forward to any comments you may have. >>>>>>> >>>>>>> Bert >>>>>>> >>>>>>> On 10/5/11 4:50 PM, Sean Turner wrote: >>>>>>>> We tried to rope in an additional reviewer. We got no takers. >>>>>>>> Stephen >>>>>>>> and I will have a look next week. >>>>>>>> >>>>>>>> spt >>>>>>>> >>>>>>>> On 10/5/11 7:55 AM, Bert Wijnen (IETF) wrote: >>>>>>>>> On 9/21/11 4:57 PM, Sean Turner wrote: >>>>>>>>>> We're going to search for a new advisor. >>>>>>>>> >>>>>>>>>> If we can't find one, we'll get the SECDIR secretary to assign an >>>>>>>>>> early reviewer. >>>>>>>>>> >>>>>>>>>> spt >>>>>>>>>> >>>>>>>>> >>>>>>>>> So, a revised version of the document is out (trying to address >>>>>>>>> all previous WGLC comments). We as WG chairs have put out a new >>>>>>>>> WG Last Call for draft-ietf-netconf-access-control-05.txt >>>>>>>>> which runs till Okt 21st 2011. >>>>>>>>> >>>>>>>>> After that finishes we expect to soon request our AD for >>>>>>>>> an IETF Last Call to consider this document for PS. >>>>>>>>> >>>>>>>>> So review by a SEC advisor or early review by a SEC Area >>>>>>>>> reviewer would be very much appreciated. The whole document >>>>>>>>> is about security for Access Control to NetConf operations and >>>>>>>>> data. >>>>>>>>> >>>>>>>>> Bert and Mehmet >>>>>>>>> Netconf WG chairs. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > From stephen.farrell@cs.tcd.ie Wed Oct 26 12:27:53 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84F921F888A for ; Wed, 26 Oct 2011 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1hvY5QNJlr8E for ; Wed, 26 Oct 2011 12:27:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A4D8321F8770 for ; Wed, 26 Oct 2011 12:27:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A0872153C74; Wed, 26 Oct 2011 20:27:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319657269; bh=fydyv5X+obiwll nX3FIJsES0ahpMcIJXORY/+dFus6s=; b=Xu5N5pXj2zve1KuawPElQqPOB66D3S 7zxkIWnZcpTejBqi/Ci4xpsXgDZhbiPsTTSXhp5D/cIpqZGhIzZFIq9FCfktuOkJ kn0TDjA9vcjqXUfdplufnzl7kdh1GoBd5RjAgmdDdiV1ufS7R6Y0EDhwBFbtr8Yn vsmBO8tazYE9TUcEkQ3gJRD3B0Xn8sFr3WSWaKrHte+xEZ+uN/q4fPGGRErwOHQm 08kgaJOYEFfMcy+FYBdjDMCa42y10LrI9/rXEZEAe0G+f0zSAJ6eBL1P2YHQOt4a 55Ndwn+GnChvly1yz6As6t72ZA8Akga4F/WFELN5ZQUF6++kPgsHC+vw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id LelntF5CQS7L; Wed, 26 Oct 2011 20:27:49 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.22.54]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DFA9B153C73; Wed, 26 Oct 2011 20:27:48 +0100 (IST) Message-ID: <4EA85F34.2080500@cs.tcd.ie> Date: Wed, 26 Oct 2011 20:27:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4EA83E05.6040000@andybierman.com> <4EA8509D.2060209@cs.tcd.ie> <4EA85517.3030104@andybierman.com> In-Reply-To: <4EA85517.3030104@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 Oct 2011 15:14:02 -0700 Cc: Sean Turner , Netconf Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:27:54 -0000 Hi Andy, I think those would be fine additions. Thanks for considering them, Cheers, S. On 10/26/2011 07:44 PM, Andy Bierman wrote: > On 10/26/2011 11:25 AM, Stephen Farrell wrote: >> >> Hi Andy, >> >> A few follow-ups below. I don't mind if we try bottom out >> on these now or you leave 'em for later - whichever's better >> for you/the WG is fine. >> >> On 10/26/2011 06:06 PM, Andy Bierman wrote: >>> On 10/25/2011 02:15 PM, Bert Wijnen (IETF) wrote: >>>> Editors/authors, pls take a look at these and make changes as >>>> you see fit. If there is anything that you think we need >>>> to get WG concensus on, pls let me know. I still have to read/check >>>> the details myself, wanted to send this to WG list asap. >>>> >>> >>> We will discuss it and have a NACM update done soon. >>> See inline for some more comments. >>> >>> >>>> Bert >>>> ---------------------------- >>>> draft-ietf-netconf-access-control-05 comments >>>> SF, 2011-10-24 >>>> >>>> General questions: >>>> >>>> 1) How do you contol access when a rule-set is managed by Alice but >>>> Bob updates the server code to deploy new protocol operations? Does >>>> it say somewhere that Alice and Bob need to talk? Or maybe that >>>> Bob's new code should figure its running for the 1st time with an >>>> existing config and send some kind of notification, and should >>>> Alice's config include something to say where? >>> >>> A different NETCONF draft specifies the notifications to send when >>> a config datastore is changed. Bob and Alice have to coordinate off-line >>> wrt/ specific device configuration changes, and their impact on access >>> control config. >>> (This is no different than when I have to go through Engineering Lab >>> Services at work >>> to get a new server setup in the lab net -- you have some off-line >>> mechanism >>> to request that an authorized user make the config changes.) >> >> Not sure if I was clear enough in the question but that maybe >> (partly) answers a slightly different question. >> >> My question related to when the server code changes, not >> when the config datastore changes. I.e. Alice does the datastore >> admin but Bob installs new server code. >> >> The danger there is that the new server code has some new >> feature that's accessible according to the existing config >> (due to some wildcard or whatever) but that ought not be. Say >> that the current config says that "foo/*" is accessible >> to the world, because that's ok with the current s/w, but the >> s/w update creates a new "foo/explode" knob that kills >> something. With the new s/w and the current config, "foo/explode" >> would, I think, also be world accessible, which could be bad, >> depending what explode means. >> >> Since its (I think) impossible to automatically handle that >> in general, the question is whether you might recommend that >> the new code notify Alice when first run. >> >> That notification I've in mind might say something like "Hi >> Alice, Version 2.10 of has just started running on >> node for the first time, (previously version 2.8). You may >> need to update your config, see ." >> >> I'm not asking that you definitely do that, but really whether >> you've thought about that, because that wasn't clear to me >> reading the draft. >> > > > I will add something to the SC section that warns administrators > that changing software images, and perhaps other mechanisms, can alter > the NETCONF content available to a given user, and care must > be taken to insure no unintended access is allowed. NETCONF > messages contain a URI summary of all the content supported by the server, > called the server capabilities. > > The system notifications also has capability change events. > If a new image or current image has any different data models or > capabilities than > it did before, the client can know about it via NETCONF > netconf-capability-changed > notifications. Implementation of the system notifications draft is not > coupled to NACM > in any way. I can add text that suggests this draft is implemented > to warn administrators of security threats due to changing capabilities. > > > >>>> 2) Do you need to have any security considerations about odd >>>> username strings, e.g. would it be possible to authenticate as >>>> "stephen\0farrell@tcd.ie" and for an access control implementation >>>> to treat me as "stephen"? >>> >>> NACM sort of punts the username management corner-cases to the >>> administrator. >>> They have to make sure all user names resolve to uique and correct >>> NETCONF >>> user names. >> >> I'd like to more-than-sort-of understand if the above corner-case >> is likely to be a gotcha or not;-) That basic trick was used in X.509 >> certs for web sites in the wild and worked in some places for some >> time. It might well be that any change needed isn't for this spec >> but the problem might hit when you do access control so it may well >> be worth a reference to the relevant part of some other netconf >> spec from this one, or to just warn about the need to ensure that >> the identifiers use in access control are the right ones as a >> security consideration, with an example like the above (if it is >> a real potential vulnerability). > > > We will try to add some security consideration text emphasizing this > sort of user identity management issue. > > >> >> Cheer, >> S. >> >>> > > > Andy > > >>>> >>>> other comments >>>> >>> >>> We will go through these and fix the draft as needed. >>> >>> >>>> - be good if 1st sentence of 2.2 had a reference but I understand >>>> why you might be shy - the X.500 access control scheme however may >>>> be fair game:-) >>>> >>>> - (total nit) "MUST be authorized" near top of p13 is ambiguous. It >>>> could mean you "MUST let it happen" or (the actual intent I assume) >>>> "MUST be checked" >>>> >>>> - 3.2 says that local/remote file access via URLs is "optional to >>>> support." a) what does that mean? that being able to query/return a >>>> file is OPTIONAL or that applying the access control model is >>>> OPTIONAL? b) shouldn't there be some 2119 language there? >>>> >>>> - I didn't get the 2nd para of 3.2.3 but I expect that's just a lack >>>> of background. I guess in my ignorance I'd wonder if there are any >>>> operations with default-operation=none that are actually sensitive - >>>> if so, then not doing access control might be bad. Can you confirm >>>> that there are no such operations? >>>> >>>> - 3.2.3 3rd last para: If I had a container called "bagOfStuff" that >>>> has within it "whoCares" (not sensitive) and "veryImportant" >>>> (sensitive) and there's an ACL that allows me full access to >>>> everyhing in bagOfStuff except veryImportant but there's another ACL >>>> that gives me full access to "noBodyCares/*" then could I rename >>>> bagOfStuff to noBodyCares/bagOfStuff and thence get access to >>>> veryImportant? >>>> >>>> - 3.3.2 - are Group names ever sent over the wire? If so, how're >>>> they handled/encoded? ("Administerung" vs. "Administrators" was an >>>> old msft glitch;-) If they're not sent over the wire, then maybe >>>> saying that will fend off some I18N discusses so might be worth it. >>>> >>>> - 3.3.3.1 - I assume setting enable-nacm=false is protected, right? >>>> >>>> - What is the "acme NS" in Figure 3? >>>> >>>> - In 3.4.4 do you need to say that this algorithm MUST be separately >>>> run for each element in a received request? The concern would >>>> be someone sending a single packet meaning "close-session then >>>> open-session&do-bad-thing" - if the message handler only looked at >>>> the start of the message then it'd do the wrong thing. That might be >>>> handled elsewhere but might still be worth stating to help coders. >>>> (And "validates the element" might not be quite specific >>>> enough perhaps.) >>>> >>>> - In 3.4.4 its not clear to me how the "transport layer" can provide >>>> group memberships - did I miss that? >>>> >>>> - In 3.4.4, maybe I'm confused but skipping from step 5 to 10 for a >>>> user who's a member of no groups seems to mean that rules can only >>>> be defined for goups - is that right? (Same question later as well >>>> in 3.4.5) >>>> >>>> - I don't get what session is used in 3.4.6? (Confused again:-) >>>> >>>> - I just flicked quickly through 3.5.2 since I'm no YANG expert;-) >>>> >>>> - 3.7.1 - s/ot it/or it/? >>>> >>>> - I didn't go through appendix A really. >>>> >>>> ----- Original Message ----- From: "Stephen Farrell" >>>> >>>> To: "Bert Wijnen (IETF)" >>>> Cc: "Sean Turner" ; "Romascanu, Dan (Dan)" >>>> ; "Ersue, Mehmet (NSN - DE/Munich)" >>>> ; "Andy Bierman" ; "Martin >>>> Bjorklund" >>>> >>>> Sent: Tuesday, October 25, 2011 3:41 PM >>>> Subject: Re: Reminder: Security Advisor review PLEASE for >>>> draft-ietf-netconf-access-control-05.txt >>>> >>>> >>>>> >>>>> Hi Bert, >>>>> >>>>> So Sean and I looked at this and we both think its >>>>> on the right track so there's certainly no major huge >>>>> problem looming. >>>>> >>>>> Being a bit more anal about things in general, I wrote >>>>> some notes (attached) that might be useful. We can chat >>>>> about those if you like. Note: I'm not saying that any >>>>> or all of those would or would not turn into discusses >>>>> so treating 'em as early last-call feedback is probably >>>>> about right. >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> On 10/20/2011 01:45 PM, Bert Wijnen (IETF) wrote: >>>>>> OK, great. >>>>>> WG last call ends this weekdn. >>>>>> >>>>>> I herewith ask the authors/editors to wait for your >>>>>> comments as well. I trust that we will see them by Tuesday >>>>>> then. >>>>>> >>>>>> Thanks, >>>>>> Bert >>>>>> document shepherd >>>>>> >>>>>> On 10/20/11 2:38 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> Hi Bert, >>>>>>> >>>>>>> Sean's done. I'm not. We're gonna talk about it Tuesday >>>>>>> (after I've had a read) and get back to you then. >>>>>>> >>>>>>> Sorry for being the slow coach here;-) >>>>>>> >>>>>>> S. >>>>>>> >>>>>>> On 10/20/2011 01:33 PM, Bert Wijnen (IETF) wrote: >>>>>>>> Hi Sean and Stephen, >>>>>>>> >>>>>>>> how are you doing on your review? >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bert >>>>>>>> document shepherd >>>>>>>> >>>>>>>> On 10/5/11 5:12 PM, Bert Wijnen (IETF) wrote: >>>>>>>>> Great (well the fact that you and Stephen will take a >>>>>>>>> look next week, not that fact that you could not find >>>>>>>>> any takers). Looking forward to any comments you may have. >>>>>>>>> >>>>>>>>> Bert >>>>>>>>> >>>>>>>>> On 10/5/11 4:50 PM, Sean Turner wrote: >>>>>>>>>> We tried to rope in an additional reviewer. We got no takers. >>>>>>>>>> Stephen >>>>>>>>>> and I will have a look next week. >>>>>>>>>> >>>>>>>>>> spt >>>>>>>>>> >>>>>>>>>> On 10/5/11 7:55 AM, Bert Wijnen (IETF) wrote: >>>>>>>>>>> On 9/21/11 4:57 PM, Sean Turner wrote: >>>>>>>>>>>> We're going to search for a new advisor. >>>>>>>>>>> >>>>>>>>>>>> If we can't find one, we'll get the SECDIR secretary to >>>>>>>>>>>> assign an >>>>>>>>>>>> early reviewer. >>>>>>>>>>>> >>>>>>>>>>>> spt >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, a revised version of the document is out (trying to address >>>>>>>>>>> all previous WGLC comments). We as WG chairs have put out a new >>>>>>>>>>> WG Last Call for draft-ietf-netconf-access-control-05.txt >>>>>>>>>>> which runs till Okt 21st 2011. >>>>>>>>>>> >>>>>>>>>>> After that finishes we expect to soon request our AD for >>>>>>>>>>> an IETF Last Call to consider this document for PS. >>>>>>>>>>> >>>>>>>>>>> So review by a SEC advisor or early review by a SEC Area >>>>>>>>>>> reviewer would be very much appreciated. The whole document >>>>>>>>>>> is about security for Access Control to NetConf operations and >>>>>>>>>>> data. >>>>>>>>>>> >>>>>>>>>>> Bert and Mehmet >>>>>>>>>>> Netconf WG chairs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>>> >>> >> >> > From phil@juniper.net Wed Oct 26 15:52:43 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F5711E808A for ; Wed, 26 Oct 2011 15:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5n87TcD-B0PP for ; Wed, 26 Oct 2011 15:52:39 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7CB11E80A6 for ; Wed, 26 Oct 2011 15:52:36 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP; Wed, 26 Oct 2011 15:52:39 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Oct 2011 15:49:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p9QMnqh09531; Wed, 26 Oct 2011 15:49:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p9QMLa5H011346; Wed, 26 Oct 2011 22:21:36 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201110262221.p9QMLa5H011346@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20111025193039.GA33471@elstar.local> Date: Wed, 26 Oct 2011 18:21:36 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] sdn bof in taipei X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 22:52:43 -0000 Juergen Schoenwaelder writes: >there is a BoF on Software Driven Networks (sdn) in Taipei (Thursday >17:40-19:40) which seems to be related to what has been discussed >under the phrase "network-wide configuration" a while ago on this list >and in the hallways. I am sending this simply to make everyone aware >of this BoF happening at Taipei. For additional information, see >. SDN ("Software Defined Networking") is a buzz word from openflow. http://www.openflow.org/wp/2011/03/open-networking-foundation-formed-to-speed-network-innovation/ There's a little content on http://www.openflow.org/wp/documents/, but it's pretty thin. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Oct 26 23:26:21 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A588021F8498 for ; Wed, 26 Oct 2011 23:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.098 X-Spam-Level: X-Spam-Status: No, score=-103.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 r1QmkTcidO9n for ; Wed, 26 Oct 2011 23:26:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CD3DC21F8497 for ; Wed, 26 Oct 2011 23:26:20 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5A2620DFD; Thu, 27 Oct 2011 08:26:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MbDmmmOrV2FH; Thu, 27 Oct 2011 08:26:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F11020DB4; Thu, 27 Oct 2011 08:26:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C43011B3C4CF; Thu, 27 Oct 2011 08:26:01 +0200 (CEST) Date: Thu, 27 Oct 2011 08:26:01 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20111027062601.GA38012@elstar.local> Mail-Followup-To: Phil Shafer , netconf@ietf.org References: <20111025193039.GA33471@elstar.local> <201110262221.p9QMLa5H011346@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110262221.p9QMLa5H011346@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] sdn bof in taipei X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 06:26:21 -0000 On Wed, Oct 26, 2011 at 06:21:36PM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >there is a BoF on Software Driven Networks (sdn) in Taipei (Thursday > >17:40-19:40) which seems to be related to what has been discussed > >under the phrase "network-wide configuration" a while ago on this list > >and in the hallways. I am sending this simply to make everyone aware > >of this BoF happening at Taipei. For additional information, see > >. > > SDN ("Software Defined Networking") is a buzz word from openflow. > > http://www.openflow.org/wp/2011/03/open-networking-foundation-formed-to-speed-network-innovation/ > > There's a little content on http://www.openflow.org/wp/documents/, but > it's pretty thin. Please check the sdnp mailing list - there is discussion of what the BOF's goals are and NETCONF is popping up once in a while and it seems at least some sdnp people do not think sdnp is openflow. I think it is not helpful to repeat the discussion here, so please join the sdnp mailing list and/or read through the archives. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Oct 26 23:37:55 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4221F84CD for ; Wed, 26 Oct 2011 23:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.104 X-Spam-Level: X-Spam-Status: No, score=-103.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 6g4Zg9W+CtGe for ; Wed, 26 Oct 2011 23:37:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAE021F84CB for ; Wed, 26 Oct 2011 23:37:54 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87ED620E23; Thu, 27 Oct 2011 08:37:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2FzF2AyKch3A; Thu, 27 Oct 2011 08:37:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B035520E22; Thu, 27 Oct 2011 08:37:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A476C1B3C671; Thu, 27 Oct 2011 08:37:35 +0200 (CEST) Date: Thu, 27 Oct 2011 08:37:35 +0200 From: Juergen Schoenwaelder To: Stephen Farrell Message-ID: <20111027063735.GC38012@elstar.local> Mail-Followup-To: Stephen Farrell , Andy Bierman , Sean Turner , Netconf References: <4EA83E05.6040000@andybierman.com> <4EA8509D.2060209@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA8509D.2060209@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Sean Turner , Netconf Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 06:37:55 -0000 On Wed, Oct 26, 2011 at 07:25:33PM +0100, Stephen Farrell wrote: > >>2) Do you need to have any security considerations about odd > >>username strings, e.g. would it be possible to authenticate as > >>"stephen\0farrell@tcd.ie" and for an access control implementation > >>to treat me as "stephen"? > > > >NACM sort of punts the username management corner-cases to the > >administrator. > >They have to make sure all user names resolve to uique and correct NETCONF > >user names. > > I'd like to more-than-sort-of understand if the above corner-case > is likely to be a gotcha or not;-) That basic trick was used in X.509 > certs for web sites in the wild and worked in some places for some > time. It might well be that any change needed isn't for this spec > but the problem might hit when you do access control so it may well > be worth a reference to the relevant part of some other netconf > spec from this one, or to just warn about the need to ensure that > the identifiers use in access control are the right ones as a > security consideration, with an example like the above (if it is > a real potential vulnerability). RFC6241 says: The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The username is a string of characters that match the "Char" production from Section 2.2 of [W3C.REC-xml-20001006]. Would it make you happy to point to this with some explicit text that implementations have to make sure they handle any legal username as a name and nothing else? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Thu Oct 27 00:30:09 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A0221F85F7 for ; Thu, 27 Oct 2011 00:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 n4o97bOOAXeo for ; Thu, 27 Oct 2011 00:30:08 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id AC4C021F85DB for ; Thu, 27 Oct 2011 00:30:06 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJKPb-0005Qs-1Y for netconf@ietf.org; Thu, 27 Oct 2011 09:30:05 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJKPa-0002D1-Rd for netconf@ietf.org; Thu, 27 Oct 2011 09:30:02 +0200 Message-ID: <4EA9087A.9040900@bwijnen.net> Date: Thu, 27 Oct 2011 09:30:02 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Netconf References: <4EA017F6.5000606@bwijnen.net> In-Reply-To: <4EA017F6.5000606@bwijnen.net> X-Forwarded-Message-Id: <4EA017F6.5000606@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ad1de2b3fbb73e0b1e3a43cfdfa67b8e Subject: [Netconf] WG Last Call ended for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 07:30:09 -0000 WG participants and editors/authors. Now that we also have received the review comments from the Security ADs, we declare the WG Last Call for this document completed. We have already seen a number of email exchanges and hope to see a new revision by the I-D deadline this coming Monday. Bert and Mehmet -------- Original Message -------- Subject: Re: Reminder: Security Advisor review PLEASE for draft-ietf-netconf-access-control-05.txt Date: Thu, 20 Oct 2011 14:45:42 +0200 From: Bert Wijnen (IETF) To: Stephen Farrell CC: Sean Turner , "Romascanu, Dan \(Dan\)" , "Ersue, Mehmet (NSN - DE/Munich)" , Andy Bierman , Martin Bjorklund OK, great. WG last call ends this weekdn. I herewith ask the authors/editors to wait for your comments as well. I trust that we will see them by Tuesday then. Thanks, Bert document shepherd On 10/20/11 2:38 PM, Stephen Farrell wrote: From bertietf@bwijnen.net Thu Oct 27 00:31:45 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D3D21F84D5 for ; Thu, 27 Oct 2011 00:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DaCch2owKNWD for ; Thu, 27 Oct 2011 00:31:45 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 4255621F84CE for ; Thu, 27 Oct 2011 00:31:45 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJKR9-0005Jg-QZ for netconf@ietf.org; Thu, 27 Oct 2011 09:31:42 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJKR9-0002UU-Mm for netconf@ietf.org; Thu, 27 Oct 2011 09:31:39 +0200 Message-ID: <4EA908DB.6080604@bwijnen.net> Date: Thu, 27 Oct 2011 09:31:39 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Netconf References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41b45fc13229c1e485ae15d6543cec4b4 Subject: [Netconf] WG Last Call ended for draft-ietf-netconf-system-notifications-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 07:31:45 -0000 The WG Last Call for this draft has now formally ended. Editors/authors, pls submit a new revision if needed. Pls do so before the I-D deadline this coming Monday. Bert From bertietf@bwijnen.net Thu Oct 27 02:26:20 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E55921F84C1 for ; Thu, 27 Oct 2011 02:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 O+oDUac0N-RK for ; Thu, 27 Oct 2011 02:26:19 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 59B9A21F84B8 for ; Thu, 27 Oct 2011 02:26:19 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJME4-0002Y1-LR; Thu, 27 Oct 2011 11:26:18 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJME4-0006SY-HE; Thu, 27 Oct 2011 11:26:16 +0200 Message-ID: <4EA923B8.6070308@bwijnen.net> Date: Thu, 27 Oct 2011 11:26:16 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Phil Shafer , netconf@ietf.org References: <20111025193039.GA33471@elstar.local> <201110262221.p9QMLa5H011346@idle.juniper.net> <20111027062601.GA38012@elstar.local> In-Reply-To: <20111027062601.GA38012@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45b852aa58888b78d6de2d7b66452796e Subject: Re: [Netconf] sdn bof in taipei X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 09:26:20 -0000 In document: http://tools.ietf.org/html/draft-pan-sdn-dc-problem-statement-and-use-cases-00 I see: NETCONF/YANG provides a XML-based solution for network device configuration. It has been in wide-deployment. By definition, it supports server-to-client configuration, but not client-to-server alarms or feedback. That is not correct, is it? I think I would rather see: NETCONF/YANG provides a XML-based solution for network device configuration. It has been in wide-deployment. By definition, it supports client-to-server configuration, and server-to-client alarms or feedback (The servers are the devices/systems to be configured, the clients are the network configuration/management systems). Or some such. Any disagreement with that? Or maybe even a better formulation? Bert On 10/27/11 8:26 AM, Juergen Schoenwaelder wrote: > On Wed, Oct 26, 2011 at 06:21:36PM -0400, Phil Shafer wrote: >> Juergen Schoenwaelder writes: >>> there is a BoF on Software Driven Networks (sdn) in Taipei (Thursday >>> 17:40-19:40) which seems to be related to what has been discussed >>> under the phrase "network-wide configuration" a while ago on this list >>> and in the hallways. I am sending this simply to make everyone aware >>> of this BoF happening at Taipei. For additional information, see >>> . >> >> SDN ("Software Defined Networking") is a buzz word from openflow. >> >> http://www.openflow.org/wp/2011/03/open-networking-foundation-formed-to-speed-network-innovation/ >> >> There's a little content on http://www.openflow.org/wp/documents/, but >> it's pretty thin. > > Please check the sdnp mailing list - there is discussion of what the > BOF's goals are and NETCONF is popping up once in a while and it seems > at least some sdnp people do not think sdnp is openflow. I think it is > not helpful to repeat the discussion here, so please join the sdnp > mailing list and/or read through the archives. > > /js > From j.schoenwaelder@jacobs-university.de Thu Oct 27 02:48:20 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED36A21F8A35 for ; Thu, 27 Oct 2011 02:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.109 X-Spam-Level: X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 doSMZZ0Nja-p for ; Thu, 27 Oct 2011 02:48:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3531A21F8A64 for ; Thu, 27 Oct 2011 02:48:20 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D3BB20E16; Thu, 27 Oct 2011 11:48:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mzsy_IY9FoPK; Thu, 27 Oct 2011 11:48:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A66920D87; Thu, 27 Oct 2011 11:48:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 60A0C1B3D06D; Thu, 27 Oct 2011 11:48:02 +0200 (CEST) Date: Thu, 27 Oct 2011 11:48:02 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20111027094802.GA39503@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Phil Shafer , netconf@ietf.org References: <20111025193039.GA33471@elstar.local> <201110262221.p9QMLa5H011346@idle.juniper.net> <20111027062601.GA38012@elstar.local> <4EA923B8.6070308@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA923B8.6070308@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] sdn bof in taipei X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 09:48:21 -0000 On Thu, Oct 27, 2011 at 11:26:16AM +0200, Bert Wijnen (IETF) wrote: > In document: > > http://tools.ietf.org/html/draft-pan-sdn-dc-problem-statement-and-use-cases-00 > > I see: > > NETCONF/YANG provides a XML-based solution for network device > configuration. It has been in wide-deployment. By definition, it > supports server-to-client configuration, but not client-to-server > alarms or feedback. > > That is not correct, is it? > > I think I would rather see: > > NETCONF/YANG provides a XML-based solution for network device > configuration. It has been in wide-deployment. By definition, it > supports client-to-server configuration, and server-to-client > alarms or feedback (The servers are the devices/systems to be > configured, the clients are the network configuration/management > systems). > > Or some such. > Any disagreement with that? Or maybe even a better formulation? No disagreement. In the context of SDNP, it might be useful to add that NETCONF provides support for executing configuration change transactions over multiple devices. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 27 02:49:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939B121F86C1 for ; Thu, 27 Oct 2011 02:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.342 X-Spam-Level: X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 h6diYv2UuROC for ; Thu, 27 Oct 2011 02:49:23 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6721F85F1 for ; Thu, 27 Oct 2011 02:49:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAPsnqU7GmAcF/2dsb2JhbABCmgmNAIJIgQWBcgEBAQEDAQEBDx4KNBcEAgEIDQQEAQEBCgYMCwEGASYfCQgBAQQBEggBEgeHZpkQm3CICWEEmVaMFQ X-IronPort-AV: E=Sophos;i="4.69,412,1315195200"; d="scan'208";a="274676878" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Oct 2011 05:49:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Oct 2011 05:47:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2011 11:49:19 +0200 Message-ID: In-Reply-To: <4EA923B8.6070308@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Netconf] sdn bof in taipei thread-index: AcyUioAjmX6xVZM3R/eVtD0EeLCjyAAAxBVA References: <20111025193039.GA33471@elstar.local><201110262221.p9QMLa5H011346@idle.juniper.net><20111027062601.GA38012@elstar.local> <4EA923B8.6070308@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Phil Shafer" , Subject: Re: [Netconf] sdn bof in taipei X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 09:49:24 -0000 Looks right to me - including the addition from Juergen.=20 Dan > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Bert Wijnen (IETF) > Sent: Thursday, October 27, 2011 11:26 AM > To: Phil Shafer; netconf@ietf.org > Subject: Re: [Netconf] sdn bof in taipei >=20 > In document: >=20 > http://tools.ietf.org/html/draft-pan-sdn-dc-problem-statement-and- > use-cases-00 >=20 > I see: >=20 > NETCONF/YANG provides a XML-based solution for network device > configuration. It has been in wide-deployment. By definition, > it > supports server-to-client configuration, but not client-to- > server > alarms or feedback. >=20 > That is not correct, is it? >=20 > I think I would rather see: >=20 > NETCONF/YANG provides a XML-based solution for network device > configuration. It has been in wide-deployment. By definition, > it > supports client-to-server configuration, and server-to-client > alarms or feedback (The servers are the devices/systems to be > configured, the clients are the network > configuration/management > systems). >=20 > Or some such. > Any disagreement with that? Or maybe even a better formulation? >=20 > Bert >=20 >=20 > On 10/27/11 8:26 AM, Juergen Schoenwaelder wrote: > > On Wed, Oct 26, 2011 at 06:21:36PM -0400, Phil Shafer wrote: > >> Juergen Schoenwaelder writes: > >>> there is a BoF on Software Driven Networks (sdn) in Taipei > (Thursday > >>> 17:40-19:40) which seems to be related to what has been discussed > >>> under the phrase "network-wide configuration" a while ago on this > list > >>> and in the hallways. I am sending this simply to make everyone > aware > >>> of this BoF happening at Taipei. For additional information, see > >>> . > >> > >> SDN ("Software Defined Networking") is a buzz word from openflow. > >> > >> http://www.openflow.org/wp/2011/03/open-networking-foundation- > formed-to-speed-network-innovation/ > >> > >> There's a little content on http://www.openflow.org/wp/documents/, > but > >> it's pretty thin. > > > > Please check the sdnp mailing list - there is discussion of what the > > BOF's goals are and NETCONF is popping up once in a while and it > seems > > at least some sdnp people do not think sdnp is openflow. I think it > is > > not helpful to repeat the discussion here, so please join the sdnp > > mailing list and/or read through the archives. > > > > /js > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Thu Oct 27 02:54:22 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5511F21F86C1 for ; Thu, 27 Oct 2011 02:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 7Jsc2gBNqhIi for ; Thu, 27 Oct 2011 02:54:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8939221F85F1 for ; Thu, 27 Oct 2011 02:54:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9R9sKmO022791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Oct 2011 11:54:20 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9R9sHJX016057 for ; Thu, 27 Oct 2011 11:54:19 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 11:54:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC948E.63CCB3DE" Date: Thu, 27 Oct 2011 11:54:16 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402E2B513@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] New version of NETCONF over TLS Thread-Index: AcyRwkv97Letl2yORqWcMgWQhrVwGgCywkdw References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 27 Oct 2011 09:54:18.0470 (UTC) FILETIME=[64D2B860:01CC948E] Subject: Re: [Netconf] New version of NETCONF over TLS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 09:54:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC948E.63CCB3DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 please review and comment the 5539bis draft so that we can=20 decide on the next steps. =20 It includes the necessary chunked framing mechanism following=20 RFC6242 and the handling of TLS usernames. However there is a=20 discussion necessary to get the technical details solved/addressed. =20 Mehmet & Bert =20 =20 From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Badra Sent: Sunday, October 23, 2011 10:28 PM To: netconf@ietf.org Subject: [Netconf] New version of NETCONF over TLS =20 Dear all, A new version of "NETCONF over TLS" document is available at http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt Comments are welcome. Best regards, Badra ------_=_NextPart_001_01CC948E.63CCB3DE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi All,

=  

= please review and comment the 5539bis draft so that we can =

= decide on the next steps.

=  

= It includes the necessary chunked framing mechanism following =

= RFC6242 and the handling of TLS usernames. However there is a =

= discussion necessary to get the technical details = solved/addressed.

=  

= Mehmet= & Bert

=  

=  

From:= = netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of ext Badra
Sent: Sunday, October 23, 2011 10:28 = PM
To: netconf@ietf.org
Subject: [Netconf] New = version of NETCONF over TLS

 

Dear = all,

A new version of "NETCONF over TLS" document is = available at http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-0= 0.txt

Comments are welcome.
Best = regards,
Badra

------_=_NextPart_001_01CC948E.63CCB3DE-- From bertietf@bwijnen.net Thu Oct 27 03:07:43 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52E521F84CF for ; Thu, 27 Oct 2011 03:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Vza5J65bTU7y for ; Thu, 27 Oct 2011 03:07:43 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 2034421F84C5 for ; Thu, 27 Oct 2011 03:07:43 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJMs6-0002Qv-4S; Thu, 27 Oct 2011 12:07:40 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJMs6-0002Pt-0Z; Thu, 27 Oct 2011 12:07:38 +0200 Message-ID: <4EA92D69.20301@bwijnen.net> Date: Thu, 27 Oct 2011 12:07:37 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: ppan@infinera.com, thomas.nadeau@ca.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ec6f16dce21341dcd21203c0f92da556 X-Mailman-Approved-At: Thu, 27 Oct 2011 03:10:50 -0700 Subject: [Netconf] comment on http://tools.ietf.org/html/draft-pan-sdn-dc-problem-statement-and-use-cases-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 10:07:43 -0000 In document: http://tools.ietf.org/html/draft-pan-sdn-dc-problem-statement-and-use-cases-00 I see: NETCONF/YANG provides a XML-based solution for network device configuration. It has been in wide-deployment. By definition, it supports server-to-client configuration, but not client-to-server alarms or feedback. That is not correct. I think (after consultation with some other NetConf people) that the following would be a better description: NETCONF/YANG provides a XML-based solution for network device configuration. It has been in wide-deployment. By definition, it supports client-to-server configuration, and server-to-client alarms or feedback (The servers are the devices/systems to be configured, the clients are the network configuration/management systems). NETCONF provides support for executing configuration change transactions over multiple devices. Bert From stephen.farrell@cs.tcd.ie Thu Oct 27 04:28:25 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6709921F8538 for ; Thu, 27 Oct 2011 04:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Xbi14r4udRuG for ; Thu, 27 Oct 2011 04:28:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A046021F8507 for ; Thu, 27 Oct 2011 04:28:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4EAB9153634; Thu, 27 Oct 2011 12:28:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319714902; bh=qcdausd6sXW0z3 xOPXamIxBJW9EhRHuTkvdXs0ART4Q=; b=xgsSV4LdpLMuX+CnAwcS8nzx6Y91zd 7iAwTLKu1Kj8IIbn7fYIT08h4fS/5ie3+MjRm9Qk+vQBhnUGgRHBb8YaoiXU+/Gy vo+byODwVqRFSjegso2rJO59iWDSSBnMqdr0nnlr2EW70CyTUJbJRA9haIgLeUY0 55kNd2NMe7MFBRYmecmdEYzWmAUlgf0wsg8irxISRtvNoMapvO5rnmsMVif4Ctg0 W2od+7dasrhfXuD21uB1vnPSs3Bz7HFuMpuPp852SorZCf6G4cvLkSpgaN2/3U5I 1+57qFLRjADyjH+LYxhhB02e8BUS9STM1+F0u8PitrOnlzPtn99EUZ6A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id s-EcoTVE63ny; Thu, 27 Oct 2011 12:28:22 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 82637171C17; Thu, 27 Oct 2011 12:28:21 +0100 (IST) Message-ID: <4EA94056.6030408@cs.tcd.ie> Date: Thu, 27 Oct 2011 12:28:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman , Sean Turner , Netconf References: <4EA83E05.6040000@andybierman.com> <4EA8509D.2060209@cs.tcd.ie> <20111027063735.GC38012@elstar.local> In-Reply-To: <20111027063735.GC38012@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 11:28:25 -0000 Hi Juergen, On 10/27/2011 07:37 AM, Juergen Schoenwaelder wrote: > On Wed, Oct 26, 2011 at 07:25:33PM +0100, Stephen Farrell wrote: > >>>> 2) Do you need to have any security considerations about odd >>>> username strings, e.g. would it be possible to authenticate as >>>> "stephen\0farrell@tcd.ie" and for an access control implementation >>>> to treat me as "stephen"? >>> >>> NACM sort of punts the username management corner-cases to the >>> administrator. >>> They have to make sure all user names resolve to uique and correct NETCONF >>> user names. >> >> I'd like to more-than-sort-of understand if the above corner-case >> is likely to be a gotcha or not;-) That basic trick was used in X.509 >> certs for web sites in the wild and worked in some places for some >> time. It might well be that any change needed isn't for this spec >> but the problem might hit when you do access control so it may well >> be worth a reference to the relevant part of some other netconf >> spec from this one, or to just warn about the need to ensure that >> the identifiers use in access control are the right ones as a >> security consideration, with an example like the above (if it is >> a real potential vulnerability). > > RFC6241 says: > > The authentication process MUST result in an authenticated client > identity whose permissions are known to the server. The > authenticated identity of a client is commonly referred to as the > NETCONF username. The username is a string of characters that match > the "Char" production from Section 2.2 of [W3C.REC-xml-20001006]. > > Would it make you happy to point to this with some explicit text that > implementations have to make sure they handle any legal username as a > name and nothing else? Something like that would be good. I've seen slip-ups happen between authentication and authorization code a good few times so whatever helps avoid that is good. Ta, S. > > /js > From bertietf@bwijnen.net Thu Oct 27 05:36:44 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42FE21F8593 for ; Thu, 27 Oct 2011 05:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mezqy4k16Ktt for ; Thu, 27 Oct 2011 05:36:44 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 362DF21F8507 for ; Thu, 27 Oct 2011 05:36:43 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJPCJ-00051v-Ok; Thu, 27 Oct 2011 14:36:41 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJPCJ-00077N-GO; Thu, 27 Oct 2011 14:36:39 +0200 Message-ID: <4EA95057.7010308@bwijnen.net> Date: Thu, 27 Oct 2011 14:36:39 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A6402E2B513@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6402E2B513@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48c3ae6e007f7f4ead0d72ada97401cef Cc: netconf@ietf.org Subject: Re: [Netconf] New version of NETCONF over TLS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 12:36:45 -0000 After a very short peek, I think - references to rfc4741, 4742, 5539 should probably best move to the informative references section. - I see changes compared to the RFC that I am not sure are warranted without explanation and possibly WG agreement. To see a diff, you can go here: http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/rfc/rfc5539.txt&url2=http://tools.ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt Bert On 10/27/11 11:54 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > please review and comment the 5539bis draft so that we can > > decide on the next steps. > > It includes the necessary chunked framing mechanism following > > RFC6242 and the handling of TLS usernames. However there is a > > discussion necessary to get the technical details solved/addressed. > > Mehmet& Bert > > *From:*netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] *On Behalf Of *ext Badra > *Sent:* Sunday, October 23, 2011 10:28 PM > *To:* netconf@ietf.org > *Subject:* [Netconf] New version of NETCONF over TLS > > Dear all, > > A new version of "NETCONF over TLS" document is available at http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt > > Comments are welcome. > Best regards, > Badra > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Thu Oct 27 05:53:12 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064C021F8AF7 for ; Thu, 27 Oct 2011 05:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 uYTozMU8ZUNk for ; Thu, 27 Oct 2011 05:53:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3761A21F8B08 for ; Thu, 27 Oct 2011 05:53:11 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9RCr86R001445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Oct 2011 14:53:09 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9RCr8uL015641; Thu, 27 Oct 2011 14:53:08 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 14:52:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2011 14:52:58 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402E2B7CA@DEMUEXC006.nsn-intra.net> In-Reply-To: <4EA95057.7010308@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] New version of NETCONF over TLS Thread-Index: AcyUpRWQYPOZR9udQr24C+BFmB81mAAAfGhA References: <80A0822C5E9A4440A5117C2F4CD36A6402E2B513@DEMUEXC006.nsn-intra.net> <4EA95057.7010308@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , X-OriginalArrivalTime: 27 Oct 2011 12:52:59.0537 (UTC) FILETIME=[5B13B810:01CC94A7] Subject: Re: [Netconf] New version of NETCONF over TLS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 12:53:12 -0000 Exactly. There is also the YANG modul ietf-netconf-tls-username, which requires a thorough review. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: Thursday, October 27, 2011 2:37 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] New version of NETCONF over TLS >=20 > After a very short peek, I think > - references to rfc4741, 4742, 5539 should probably best > move to the informative references section. > - I see changes compared to the RFC that I am not sure are > warranted without explanation and possibly WG agreement. >=20 > To see a diff, you can go here: >=20 >=20 > http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/rfc/rfc5539.t= x t&url2=3Dhttp://tools > .ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt >=20 > Bert >=20 > On 10/27/11 11:54 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi All, > > > > please review and comment the 5539bis draft so that we can > > > > decide on the next steps. > > > > It includes the necessary chunked framing mechanism following > > > > RFC6242 and the handling of TLS usernames. However there is a > > > > discussion necessary to get the technical details solved/addressed. > > > > Mehmet& Bert > > > > *From:*netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] *On Behalf Of > *ext Badra > > *Sent:* Sunday, October 23, 2011 10:28 PM > > *To:* netconf@ietf.org > > *Subject:* [Netconf] New version of NETCONF over TLS > > > > Dear all, > > > > A new version of "NETCONF over TLS" document is available at > http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt > > > > Comments are welcome. > > Best regards, > > Badra > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From lhotka@cesnet.cz Thu Oct 27 07:08:53 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA87221F87D3 for ; Thu, 27 Oct 2011 07:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 xlJdLyLsCS1A for ; Thu, 27 Oct 2011 07:08:53 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE921F85A4 for ; Thu, 27 Oct 2011 07:08:52 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id E75C12CDE05C for ; Thu, 27 Oct 2011 16:08:46 +0200 (CEST) Message-ID: <4EA965EF.5010009@cesnet.cz> Date: Thu, 27 Oct 2011 16:08:47 +0200 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6402E2B513@DEMUEXC006.nsn-intra.net> <4EA95057.7010308@bwijnen.net> In-Reply-To: <4EA95057.7010308@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] New version of NETCONF over TLS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:08:53 -0000 Dne 27.10.2011 14:36, Bert Wijnen (IETF) napsal(a): > After a very short peek, I think > - references to rfc4741, 4742, 5539 should probably best > move to the informative references section. Shouldn't they be updated to 6241 etc.? Lada > - I see changes compared to the RFC that I am not sure are > warranted without explanation and possibly WG agreement. > > To see a diff, you can go here: > > > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/rfc/rfc5539.txt&url2=http://tools.ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt > > > Bert > > On 10/27/11 11:54 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Hi All, >> >> please review and comment the 5539bis draft so that we can >> >> decide on the next steps. >> >> It includes the necessary chunked framing mechanism following >> >> RFC6242 and the handling of TLS usernames. However there is a >> >> discussion necessary to get the technical details solved/addressed. >> >> Mehmet& Bert >> >> *From:*netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] *On >> Behalf Of *ext Badra >> *Sent:* Sunday, October 23, 2011 10:28 PM >> *To:* netconf@ietf.org >> *Subject:* [Netconf] New version of NETCONF over TLS >> >> Dear all, >> >> A new version of "NETCONF over TLS" document is available at >> http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-00.txt >> >> Comments are welcome. >> Best regards, >> Badra >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Thu Oct 27 07:10:59 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B514321F8B15 for ; Thu, 27 Oct 2011 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 B2YqmxyZ7Qi0 for ; Thu, 27 Oct 2011 07:10:59 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0021F8B1A for ; Thu, 27 Oct 2011 07:10:58 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJQfM-00078N-Am; Thu, 27 Oct 2011 16:10:47 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJQfM-0005DO-6w; Thu, 27 Oct 2011 16:10:44 +0200 Message-ID: <4EA96663.6020006@bwijnen.net> Date: Thu, 27 Oct 2011 16:10:43 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <80A0822C5E9A4440A5117C2F4CD36A6402E2B513@DEMUEXC006.nsn-intra.net> <4EA95057.7010308@bwijnen.net> <4EA965EF.5010009@cesnet.cz> In-Reply-To: <4EA965EF.5010009@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42af0a72ceefd1ebbe7a9e953992133fa Cc: netconf@ietf.org Subject: Re: [Netconf] New version of NETCONF over TLS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:10:59 -0000 Yes, and that has been done. But the old RFCs are also still listed and cited. As far as I can understand, that is just informational. The new numbers should give enough info from a normative point of view. Bert On 10/27/11 4:08 PM, Ladislav Lhotka wrote: > Dne 27.10.2011 14:36, Bert Wijnen (IETF) napsal(a): >> After a very short peek, I think >> - references to rfc4741, 4742, 5539 should probably best >> move to the informative references section. > > Shouldn't they be updated to 6241 etc.? > > Lada From j.schoenwaelder@jacobs-university.de Thu Oct 27 08:05:05 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFDD21F8B6E for ; Thu, 27 Oct 2011 08:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.113 X-Spam-Level: X-Spam-Status: No, score=-103.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 0ZwLFSWlplx8 for ; Thu, 27 Oct 2011 08:05:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB1521F8B6D for ; Thu, 27 Oct 2011 08:05:04 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FFA220E58; Thu, 27 Oct 2011 17:05:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XeuUzgaHnhxn; Thu, 27 Oct 2011 17:05:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BB1C20E60; Thu, 27 Oct 2011 17:05:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 23BF31B3D9EF; Thu, 27 Oct 2011 17:04:43 +0200 (CEST) Date: Thu, 27 Oct 2011 17:04:43 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20111027150443.GB40631@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6402E2B513@DEMUEXC006.nsn-intra.net> <4EA95057.7010308@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA95057.7010308@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] New version of NETCONF over TLS X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:05:05 -0000 On Thu, Oct 27, 2011 at 02:36:39PM +0200, Bert Wijnen (IETF) wrote: > After a very short peek, I think > - references to rfc4741, 4742, 5539 should probably best > move to the informative references section. This should not normatively depend on these: [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009. [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Thu Oct 27 10:48:12 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20421F8772 for ; Thu, 27 Oct 2011 10:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 K3lJeWdh3n8G for ; Thu, 27 Oct 2011 10:48:11 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4460721F8672 for ; Thu, 27 Oct 2011 10:48:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=REpBEFH+9KCg1S8p/FCO08AnefpRG58D19Rsy1rtEajV1zj/YjrQv0C3ZYXcJ5eK; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.78] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RJU3k-0000za-7z for netconf@ietf.org; Thu, 27 Oct 2011 13:48:08 -0400 Message-ID: <005a01cc94d0$e70b7d20$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201110211447.KAA23003@adminfs.snmp.com> Date: Thu, 27 Oct 2011 10:50:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee28814208c83d6ee5beecaa6d64bd805abb1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.78 Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:48:12 -0000 Hi - A few comments, in-line below. > From: "Alan Luchuk" > To: > Sent: Friday, October 21, 2011 7:47 AM > Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames ... > Here is the latest proposed text for an update to RFC 5539 for deriving > NETCONF usernames when using NETCONF over TLS. Thanks to all who > commented on earlier version(s) of this text. > > Much of the text in the earlier draft has been replaced by a YANG module > in this draft. This YANG module heavily borrows ideas and text from the > SNMP-TLS-TM-MIB from RFC 6353. The description text in the YANG module > should be more concise and clear than the deleted text. ... > Additionally, the NETCONF protocol [RFC6241] requires that the > transport protocol's authentication process MUST result in an > authenticated client identity whose permissions are known to the > server. The authenticated identity of a client is commonly > referred to as the NETCONF username. Thus, an algorithm for > transforming certificates to NETCONF usernames is needed. I think someone else has already commented on how the "MUST" here is a bit odd. Is it attempting to say that it is impossible for the permissions of an authenticated client identity to *not* be known to the server? > The algorithm for deriving NETCONF usernames from TLS certificates > is patterned after the algorithm for deriving tmSecurityNames from > TLS certificates specified in Transport Layer Security (TLS) > Transport Model for the Simple Network Management Protocol (SNMP) > [RFC6353]. RFC6353 specifies that an SNMP engine must implement > several algorithms for transforming a certificate to a tmSecurityName, > and lets the SNMP engine deployer choose and configure the algorithm > most suitable for the deployer's environment. Recapping RFC6353 does be helpful, but it's more important to answer the question of what *this* specification requires. All this paragraph says is "patterned after", which means "similar but likely different", and the paragraph does not spell out what the differences are. > When a NETCONF server accepts a TLS connection from a NETCONF client, > the NETCONF server must produce a NETCONF username from the certificate > presented by the NETCONF client. The NETCONF server may use any of > the following algorithms to produce the NETCONF username from the > certificate presented by the NETCONF client: Is the use of "must" and "may deliberate? I think what you mean is: When a NETCONF server accepts a TLS connection from a NETCONF client, the NETCONF server attempts to derive a NETCONF username from the certificate presented by the NETCONF client. The NETCONF server MAY use any of the following algorithms to produce the NETCONF username from the certificate presented by the NETCONF client: > - Map a certificate directly to a NETCONF username; What transforms are permitted in this mapping? > - Extract the subjectAltName's rfc822Name from the certificate, > then use the extracted rfc822Name as the NETCONF username; > > - Extract the subjectAltName's dnsName from the certificate, > then use the extracted dnsName as the NETCONF username; > > - Extract the subjectAltName's iPAddress from the certificate, > then use the extracted iPAddress as the NETCONF username; Does anything need to be said about the representaiton of the IPAddress? > - Examine the subjectAltName's rfc822Name, dnsName, and iPAddress > fields in a pre-defined order, then use the first matching > subjectAltName value. "matching" what? > The NETCONF server MUST implement all of these algorithms, and > allow the deployer to choose and configure the algorithm used. "and configure" - are there additional inputs to any of these algorithms? If so, they need to be spelled out. > The certificate-to-username-transforms container in the > ietf-netconf-tls-username YANG module specifies how a NETCONF > server transforms an certificate into a NETCONF username. If this paragraph applies to the first bullet above, I suggest turning it into a note and attaching it directly to the bullet. > Identifying a Certificate > ------------------------- > > A client certificate has an identity: the certificate. The TLS and > corresponding protocols provide an identity. The identity > shows that "this client certificate has shown that it, indeed, is on > the other side of the connection". With a complete certificate, > the certificate receiver can be certain that for someone or something > on the other side to use that certificate successfully, it has the > associated private key. Only the last sentence of this paragraph makes any sense to me. The first sentence (presumably the topic sentence of the paragraph) is tautological nonsense. > The problem with using the entire certificates as the identity is > that they are difficult for people to use. It is generally accepted > that a fingerprint of a certificate is not likely to come up with a > collision against a fingerprint of another (different) certificate. > Thus, assuming a good hash algorithm, using fingerprints is a safe > way to compare two certificates. "Compare" is the wrong word. I'd suggest replacing the last phrase with "a fingerprint can be a safe short-hand for identifying a certificate." I would recommend that someone actually do the math to figure out what a "safe" fingerprint size would be. Since this would be used for configuration, interoperability is a concern, so the fingerprint algorithm needs to be spelled out. > If if a locally held copy of a trusted CA certificate is configured > in the transformation container, and that CA certificate was used to > validate the path to the presented certificate, then the NETCONF > server should use that list entry in the transformation container. > All presented certificates validated by the configured CA certificate > will be transformed to NETCONF usernames using the same transformation > algorithm. This paragraph is just plain baffling in context. It sounds like it presumes a bunch of stuff spelled out in the Yang. ... > typedef tls-fingerprint-type { > type binary { > length "0..255"; > } ... > An tls-fingerprint-type value is composed of a 1-octet hashing > algorithm identifier followed by the fingerprint value. Wouldn't it make sense for this sub-structure to be explicit in the data type's syntax? > This typedef allows for a zero-length (blank) tls-fingerprint-type > value for use in containers where the fingerprint value may be > optional. YANG definitions or implementations may refuse to > accept a zero-length value as appropriate."; If the data element is itself optional in such cases, why is the sentinel value needed? ... > leaf certificate-to-username-transform-count { > type yang:gauge32; > description > "A count of the number of certificate-to-username-transforms."; > config false; > } Why is this needed? > leaf certificate-to-username-transform-last-changed { > type yang:date-and-time; > description > "The date and time when the certificate-to-username-transforms > was last modified through any means. The value 0 means the > certificate-to-username-transforms has not been modified since > the NETCONF server was started."; > config false; > } Why is this needed? If it's there for the reason I think it's there, limiting it to "since the NETCONF server was started" defeats the purpose. > container. This container does not provide any mechanisms for > configuring the trust anchors; the transfer of any needed > trusted certificates for path validation is expected to occur > through an out-of-band transfer. I can understand the bootstrap problem of getting an initial trust anchor. However, I think this (or the security considerations section) also needs to address why NETCONF can't be used to configure additional trust anchors or to modify/delete the initial trust anchor. ... > NETCONF username to identify with the remote connection. This perhaps s/identify/associate/ > is done by considering each active list entry from this container > in prioritized order according to its index value. > Each list entry's certificate-fingerprint value determines > whether the list entry is a match for the incoming connection: > > 1) If the list entry's certificate-fingerprint value > identifies the presented certificate, then consider the s/identifies/matches that of/ ... > 2) If the list entry's certificate-fingerprint value > identifies a locally held copy of a trusted CA s/identifies/matches that of/ > certificate and that CA certificate was used to > validate the path to the presented certificate, then > consider the list entry as a successful match. This seems just a bit odd. Why should CAs be treated as NETCONF users? > Once a matching list entry has been found, the NETCONF server uses > the map-type value to determine how the NETCONF username associated > with the session should be determined. See the map-type column's General note - is "column" the preferred terminology here and elsewhere? It sounds rather MIB-ish. ... > If no matching and valid list entry can be found, the connection MUST > be closed and NETCONF messages MUST NOT be accepted over it. This seems quite reasonable, but contradicts the statement from above "Additionally, the NETCONF protocol [RFC6241] requires that the transport protocol's authentication process MUST result in an authenticated client identity whose permissions are known to the server." > Missing values of index are acceptable and implementations How can the value of index be missing? It's a key, with a simple integer range. > should continue to the next highest numbered list entry. It is What is "next" after "missing"??? > recommended that administrators skip index values to leave room Do you mean "RECOMMENDED"? > for the insertion of future list entries (for example, use values > of 10 and 20 when creating initial list entries). If so, what is the motivation for this operational practice? > Users are encouraged to make use of certificates with By "users" do you mean "security administrators"? ... > rfc822Name > > Maps a subjectAltName's rfc822Name to a NETCONF username. > The local part of the rfc822Name is passed unaltered but > the host-part of the name must be passed in lowercase. Does anything need to be said about IDNs here and in the other "lowercase" conversion situations? > leaf data { > type string { > length "1..max"; > } > description > "Auxiliary data used as optional configuration information for > a given mapping specified by the map-type column. Only some > mapping systems will make use of this column. The value in this > column MUST be ignored for any mapping type that does not require > data present in this column."; What does "MUST be ignored" mean? During get-config? During edit-config? ... > Implementations may optionally support TLS Pre-Shared Key (PSK) > authentication. RFC 4279 describes pre-shared key ciphersuites for > TLS. During the TLS Handshake, the client indicates which key to use > by including a PSK identity in the TLS ClientKeyExchange message > [RFC4279]. On the server side, this PSK identity is used to lookup the s/lookup/look up/ Randy From randy_presuhn@mindspring.com Thu Oct 27 12:14:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E5621F8B6F for ; Thu, 27 Oct 2011 12:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.849 X-Spam-Level: X-Spam-Status: No, score=-100.849 tagged_above=-999 required=5 tests=[AWL=-1.751, BAYES_05=-1.11, FAKE_REPLY_C=2.012, USER_IN_WHITELIST=-100] 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 ornF+472bLUT for ; Thu, 27 Oct 2011 12:14:14 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0E21F85F2 for ; Thu, 27 Oct 2011 12:14:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=r9fM+oNhkOAWYWs8C8zQRxe8ZBM5alxIgEkC23jvj8bEJP5GX/Tv14D6F6Ldo3sk; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.78] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RJVP1-0002QG-3H for netconf@ietf.org; Thu, 27 Oct 2011 15:14:11 -0400 Message-ID: <001801cc94dc$ed7b52a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 27 Oct 2011 12:16:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288a122ad96482ce678737f785ebe4d208a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.78 Subject: Re: [Netconf] RFC 5539 update for NETCONF usernames X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 19:14:15 -0000 Hi - An additional concern regarding fingerprint algorithms... It sounds like the set of algorithms is intended to be extensible, thus the reference to the IANA registry. If that is the case, what happens when a configuration specifies the use of an algorithm not supported by a particular implementation? For interoperability purposes, is there a specific set of "must support" fingerprint algorithms? Randy From internet-drafts@ietf.org Fri Oct 28 06:06:48 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5C321F8BB0; Fri, 28 Oct 2011 06:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FkQbnXAQ03Km; Fri, 28 Oct 2011 06:06:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD43621F8B55; Fri, 28 Oct 2011 06:06:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111028130647.24207.57274.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 06:06:47 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-system-notifications-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 13:06:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group o= f the IETF. Title : Network Configuration Protocol (NETCONF) Base Notificati= ons Author(s) : Andy Bierman Filename : draft-ietf-netconf-system-notifications-06.txt Pages : 17 Date : 2011-10-28 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-= 06.txt From bertietf@bwijnen.net Fri Oct 28 06:54:58 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98CB21F86A1 for ; Fri, 28 Oct 2011 06:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] 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 2vrMiSawLJAA for ; Fri, 28 Oct 2011 06:54:58 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 30DB521F844A for ; Fri, 28 Oct 2011 06:54:58 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RJmtc-0003NO-91 for netconf@ietf.org; Fri, 28 Oct 2011 15:54:57 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RJmtb-0007Ka-TY for netconf@ietf.org; Fri, 28 Oct 2011 15:54:56 +0200 Message-ID: <4EAAB42F.6060102@bwijnen.net> Date: Fri, 28 Oct 2011 15:54:55 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 CC: netconf@ietf.org References: <20111028130647.24207.57274.idtracker@ietfa.amsl.com> In-Reply-To: <20111028130647.24207.57274.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.0 MISSING_HEADERS Missing To: header -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43ddc08f21b9896eb775458dbf21fb5ce Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-system-notifications-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 13:54:59 -0000 My comment was properly addressed, so I am happy if we go to the next step. Bert On 10/28/11 3:06 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. > > Title : Network Configuration Protocol (NETCONF) Base Notifications > Author(s) : Andy Bierman > Filename : draft-ietf-netconf-system-notifications-06.txt > Pages : 17 > Date : 2011-10-28 > > The NETCONF protocol provides mechanisms to manipulate configuration > datastores. However, client applications often need to be aware of > common events such as a change in NETCONF server capabilities, that > may impact management applications. Standard mechanisms are needed > to support the monitoring of the base system events within the > NETCONF server. This document defines a YANG module that allows a > NETCONF client to receive notifications for some common system > events. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-06.txt > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From internet-drafts@ietf.org Mon Oct 31 10:30:52 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910571F0C81; Mon, 31 Oct 2011 10:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4PTlkS7qUQE9; Mon, 31 Oct 2011 10:30:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3E21F0C6E; Mon, 31 Oct 2011 10:30:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031173052.29299.57849.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 10:30:52 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:30:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group o= f the IETF. Title : Network Configuration Protocol (NETCONF) Access Control = Model Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-access-control-06.txt Pages : 54 Date : 2011-10-31 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-06.txt From bertietf@bwijnen.net Mon Oct 31 13:58:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E6211E828D for ; Mon, 31 Oct 2011 13:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0HmEUTBVPmgu for ; Mon, 31 Oct 2011 13:58:22 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id BFABF11E8286 for ; Mon, 31 Oct 2011 13:58:19 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RKyvv-0003xj-Uo for netconf@ietf.org; Mon, 31 Oct 2011 21:58:17 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RKyvv-00049g-P7 for netconf@ietf.org; Mon, 31 Oct 2011 21:58:15 +0100 Message-ID: <4EAF0BE7.4080502@bwijnen.net> Date: Mon, 31 Oct 2011 21:58:15 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netconf References: <20111031173052.29299.57849.idtracker@ietfa.amsl.com> In-Reply-To: <20111031173052.29299.57849.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111031173052.29299.57849.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd441bd30284d4e709334201a1e2a35c7f6 Subject: [Netconf] Fwd: I-D Action: draft-ietf-netconf-access-control-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:58:25 -0000 I am happy with the changes in this new revision (as a result of comments during WG Last Call). I think the document is ready to hand over to our AD for IETF Last Call. Meamwhile, Pls do a quick check to see if your comments have been addressed properly. Bert Wijnen Document shepherd -------- Original Message -------- Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-06.txt Date: Mon, 31 Oct 2011 10:30:52 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: netconf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Access Control Model Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-access-control-06.txt Pages : 54 Date : 2011-10-31 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-06.txt _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Mon Oct 31 14:01:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10A221F8B9F for ; Mon, 31 Oct 2011 14:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bpGRTBF-SjRH for ; Mon, 31 Oct 2011 14:01:14 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 7922621F8B91 for ; Mon, 31 Oct 2011 14:01:14 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RKyyh-000435-SV; Mon, 31 Oct 2011 22:01:11 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RKyyh-0004LK-7n; Mon, 31 Oct 2011 22:01:07 +0100 Message-ID: <4EAF0C92.5000603@bwijnen.net> Date: Mon, 31 Oct 2011 22:01:06 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4EA83E05.6040000@andybierman.com> <4EA8509D.2060209@cs.tcd.ie> <20111027063735.GC38012@elstar.local> <4EA94056.6030408@cs.tcd.ie> In-Reply-To: <4EA94056.6030408@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41e6500cecd31206eb8502cb0cff582a2 Cc: Sean Turner , Netconf Subject: [Netconf] just posted: draft-ietf-netconf-access-control-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:01:15 -0000 This revision 06 has just been posted. If you wan to check if your comments have been properly addressed (or answerd), pls do so. The diff is here: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-access-control/draft-ietf-netconf-access-control-06-from-05.diff.html I think we're ready for the next step, namely hand it over to our AD for IETF Last Call. Bert Wijnen, Document shepherd.