Steve, I believe that the situation is #1 below. Dan > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Stephen Hanna > Sent: Thursday, August 13, 2009 1:53 PM > To: Tom.Petch; secdir@xxxxxxxx; ietf@xxxxxxxx; > draft-ietf-netconf-partial-lock@xxxxxxxxxxxxxx > Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt > > Tom, > > Thanks for responding to my comments. Allow me to respond. > > You wrote: > > As a participant in netconf, I see authorization as one of those > > topics which the Working Group sees as necessary but cannot > be tackled > > just yet. As RFC4741 says, " This document does not specify an > > authorization scheme, as such a > > scheme should be tied to a meta-data model or a data model." > > and as yet, there is no data model; hence, no > authorization, not yet, > > nor, IMHO, for some time to come. > > This is just the sort of background information that a WG > participant would know but that a secdir reviewer would not. > Please allow me to ask a clarifying question. You say that > there is no authorization yet. > I think that could mean several things: > > 1) Existing NETCONF implementations implement authorization, ensuring > that each user gets an appropriate and perhaps different level of > access to the database. However, there are no standards for the > manner in which authorization is performed or configured. > > 2) Existing NETCONF implementations require authentication > but generally > just give complete read-write access to the database to > all authenticated > users. > > 3) Existing NETCONF implementations do not require authentication. > Anyone with network access has complete, unfettered access to > the database and can modify it at will. > > Could you tell me which of these meanings is most accurate? > Of course, it could be a mix of these but I'd like to get > your real-world assessment of the state of the NETCONF world. > If the answer is 3), we have a serious problem! If the answer > is 1) or 2), that's acceptable in my view. > > Now on to the language in the draft. My comment was relating > to this quote from the Security Considerations: > > > "Only an authenticated and authorized user can request a partial > > lock." > > I'm afraid that this statement is not justified if there is > no normative text requiring implementations to comply. I > suggest that normative text be added to at least require > authentication. > With such text, the statement above could be justified. > Requiring that levels of authorization be implemented is less > important in this application. And standardizing the manner > in which authorization is performed or configured (which I > think is your concern with respect to the lack of a data > model) is really not important at all unless NETCONF > customers or vendors decide that it is. Standardizing an > authorization policy format is a tremendously challenging > task for any protocol and often not necessary. > > I hope that this helps you address my comments in a > reasonable and achievable manner. The intent of secdir > comments is not to impose unreasonable requirements. It is to > point out issues that might not be evident to someone who is > not a security expert. > > Thanks, > > Steve > > > -----Original Message----- > > From: Tom.Petch [mailto:sisyphus@xxxxxxxxxxxxxx] > > Sent: Thursday, August 13, 2009 4:00 AM > > To: Stephen Hanna; secdir@xxxxxxxx; ietf@xxxxxxxx; > > draft-ietf-netconf-partial-lock@xxxxxxxxxxxxxx > > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt > > > > ----- Original Message ----- > > From: "Stephen Hanna" <shanna@xxxxxxxxxxx> > > To: <iesg@xxxxxxxx>; <secdir@xxxxxxxx>; <ietf@xxxxxxxx>; > > <draft-ietf-netconf-partial-lock@xxxxxxxxxxxxxx> > > Sent: Monday, August 10, 2009 4:28 PM > > > > > I have reviewed this document as part of the security > directorate's > > > ongoing effort to review all IETF documents being > processed by the > > > IESG. These comments were written primarily for the > benefit of the > > > security area directors. Document editors and WG chairs > > should treat > > > these comments just like any other last call comments. > > > > > > This document defines optional partial-lock and partial-unlock > > > operations to be added to the NETCONF protocol. These > operations are > > > used to lock only part of a configuration datastore, allowing > > > multiple management sessions to modify the configuration > of a device > > > at a single time. > > > > > > The Security Considerations section of the document > highlights the > > > risk that a malicious party might employ partial locks to impede > > > access to a device's configuration. Therefore, it states "Only an > > > authenticated and authorized user can request a partial lock." > > > Unfortunately, I cannot find any normative text (MUST) > that supports > > > this statement. The NETCONF spec (RFC 4741) says "NETCONF > > > connections must be authenticated" but this is not clearly > > > normative. Perhaps a NETCONF expert can point to some > normative text > > > requiring authentication and authorization for any party > requesting > > > a partial lock. If not, I suggest that such normative > text be added > > > to the partial-lock specification. > > > > > As a participant in netconf, I see authorization as one of those > > topics which the Working Group sees as necessary but cannot > be tackled > > just yet. As RFC4741 says, " This document does not specify an > > authorization scheme, as such a > > scheme should be tied to a meta-data model or a data model." > > and as yet, there is no data model; hence, no > authorization, not yet, > > nor, IMHO, for some time to come. In the light of this, I > am not sure > > what adding a normative statement to this I-D would do; delay > > publication sine die? > > > > Tom Petch > > > > > > > > > > > Another security concern that I have related to the partial-lock > > > operation is that the configuration might become > inconsistent if one > > > manager changes one part of a datastore at the same time that > > > another manager changes another part. The resulting inconsistency > > > could have security implications. For example, an > organization might > > > have a rule that either the firewall or the intrusion detection > > > features must be enabled on a device. If one manager might lock > > > intrusion detection configuration, check that the firewall is > > > enabled, and then disable intrusion detection. Another > manager might > > > lock the firewall configuration, check that intrusion > > detection > > > is enabled, and then disable the firewall. If those > operations were > > > interleaved, they could result in a violation of policy. > > > To address this concern, I suggest that the draft contain > a warning > > > that parallel operations are tricky and should be carefully > > > considered. Sometimes, it may be necessary to lock a > portion of the > > > datastore that will not be modified, just to ensure the datastore > > > remains consistent and compliant with policy. > > > > > > Of course, a human administrator using a GUI could easily > run into > > > this same problem if the human does not have the ability > to control > > > configuration locks. The human might look at the firewall > > > configuration to make sure that it's enabled and then switch to > > > another section of the display to disable the intrusion detection > > > function. If the management console only locks the datastore to > > > execute the administrator's request to disable intrusion > detection, > > > overlapping operations from another administrator could > result in a > > > bad configuration. > > > This problem can arise even without the partial lock operation. > > > Probably the best that can be done here is to include language > > > warning of this sort of problem. Warning human > administrators that > > > someone else is also editing the device should help and > giving these > > > administrators the ability to easily communicate with > each other to > > > coordinate their work would also probably help. > > > > > > Here are a few minor issues: > > > > > > * At the end of section 2.1.1.2, the comma in the last > > > sentence is superfluous. > > > > > > * In section 2.1.1.3 in the sentence "Manager A terminates it's > > > session", the apostrophe should be removed. > > > > > > * In section 2.4.1, I think that the sentence that begins with > > > "If someone later creates a new interface" would be clearer > > > if the second comma was changed to "so". > > > > > > * Later in section 2.4.1, the sentence that begins with > > > "A NETCONF server MUST" should instead start with "A NETCONF > > > server that supports partial locks MUST". I think that > > > paragraph should end with "all of the overlapping locks are > > > released" not "all of the locks are released". > > > _______________________________________________ > > > Ietf mailing list > > > Ietf@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/ietf > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf