----- 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf