RE: secdir review of draft-ietf-netconf-partial-lock-09.txt

Steve, I believe that the situation is #1 below. 

Dan
 

> -----Original Message-----
> From: ietf-bounces(_at_)ietf(_dot_)org 
> [mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
> Behalf Of Stephen Hanna
> Sent: Thursday, August 13, 2009 1:53 PM
> To: Tom.Petch; secdir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
> draft-ietf-netconf-partial-lock(_at_)tools(_dot_)ietf(_dot_)org
> 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(_at_)dial(_dot_)pipex(_dot_)com]
> > Sent: Thursday, August 13, 2009 4:00 AM
> > To: Stephen Hanna; secdir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
> > draft-ietf-netconf-partial-lock(_at_)tools(_dot_)ietf(_dot_)org
> > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> >
> > ----- Original Message -----
> > From: "Stephen Hanna" <shanna(_at_)juniper(_dot_)net>
> > To: <iesg(_at_)ietf(_dot_)org>; <secdir(_at_)ietf(_dot_)org>; 
> > <ietf(_at_)ietf(_dot_)org>; 
> > <draft-ietf-netconf-partial-lock(_at_)tools(_dot_)ietf(_dot_)org>
> > 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(_at_)ietf(_dot_)org
> > > https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf