Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt

["Tom.Petch" <[e-mail]>]

----- Original Message -----
From: "Stephen Hanna" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf