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

["Bert (IETF) Wijnen" <[e-mail]>]

Stephen,

I think it is your first bullet point. We have not standardize it yet.
And so it is implementation dependent as to what authorization is used.

Bert


Stephen Hanna wrote:
> 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:[e-mail]] 
>> Sent: Thursday, August 13, 2009 4:00 AM
>> To: Stephen Hanna; [e-mail]; [e-mail]; 
>> [e-mail]
>> Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
>>
>> ----- 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
>>>       
>>     
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
>