Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-yang-patch-12: (with DISCUSS and COMMENT)

[[e-mail]]

Please excuse typos, sent from handheld device 

> On Nov 13, 2016, at 3:10 PM, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
>> On Sat, Nov 12, 2016 at 4:45 PM, Kathleen Moriarty <[e-mail]> wrote:
>> Hello,
>> 
>> Thanks for your responses, inline.
>> 
>>> On Fri, Nov 11, 2016 at 12:08 PM, Andy Bierman <[e-mail]> wrote:
>>> 
>>> 
>>>> On Fri, Nov 11, 2016 at 6:04 AM, Mahesh Jethanandani <[e-mail]> wrote:
>>>> Andy,
>>>> 
>>>> I am looking at -13 version of the document and following up on all the DISCUSS on the document to make sure they have been addressed. In particular - 
>>>> 
>>>>> On Nov 3, 2016, at 9:35 PM, Kathleen Moriarty <[e-mail]> wrote:
>>>>> 
>>>>> Hi Andy,
>>>>> 
>>>>> Thanks for your response and sorry I didn't see it sooner.  Inline
>>>>> 
>>>>>> On Tue, Nov 1, 2016 at 5:21 PM, Andy Bierman <[e-mail]> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <[e-mail]> wrote:
>>>>>>> Authors,
>>>>>>> 
>>>>>>> Can we address Kathleen's comments?
>>>>>>> 
>>>>>>> Mahesh Jethanandani
>>>>>>> [e-mail]
>>>>>>> 
>>>>>>> > On Oct 31, 2016, at 8:28 AM, Kathleen Moriarty <[e-mail]> wrote:
>>>>>>> >
>>>>>>> > Kathleen Moriarty has entered the following ballot position for
>>>>>>> > draft-ietf-netconf-yang-patch-12: Discuss
>>>>>>> >
>>>>>>> > When responding, please keep the subject line intact and reply to all
>>>>>>> > email addresses included in the To and CC lines. (Feel free to cut this
>>>>>>> > introductory paragraph, however.)
>>>>>>> >
>>>>>>> >
>>>>>>> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>>> > for more information about IESG DISCUSS and COMMENT positions.
>>>>>>> >
>>>>>>> >
>>>>>>> > The document, along with other ballot positions, can be found here:
>>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > ----------------------------------------------------------------------
>>>>>>> > DISCUSS:
>>>>>>> > ----------------------------------------------------------------------
>>>>>>> >
>>>>>>> > This should be easy to resolve through discussion or some text tweaks.
>>>>>>> > In the security considerations section, I see some text that hints at my
>>>>>>> > questions below, but isn't clear enough, so I'd like to discuss it to see
>>>>>>> > if these things are covered, or why they are not, and to see if we can
>>>>>>> > tweak the text a bit.
>>>>>>> >
>>>>>>> > The following text is helpful, is PATCH described in
>>>>>>> > [I-D.ietf-netconf-restconf]?
>>>>>>> >   This document defines edit processing
>>>>>>> >   instructions for a variant of the PATCH method, as used within the
>>>>>>> >   RESTCONF protocol.
>>>>>>> >
>>>>>>> > I see section 2.7 discusses error handling and validating the YANG
>>>>>>> > module, but is there a way that the hash (or some other mechanism) of the
>>>>>>> > patch could be validated to ensure the patch was not altered.  Is that
>>>>>>> > already described for PATCH?
>>>>>> 
>>>>>> The YANG Patch requests are not signed.
>>>>>> These messages are sent within the RESTCONF protocol, which MUST use TLS.
>>>>>> 
>>>>>> Sec 1. says:
>>>>>> 
>>>>>>    It may be possible to use YANG Patch with other protocols besides
>>>>>>    RESTCONF.  This is outside the scope of this document.  It may be
>>>>>>    possible to use YANG Patch with datastore types other than a 
>>>>>>        configuration datastore. This is outside the scope of this document.
>>>>>> 
>>>>>> The security requirements for protocols other than RESTCONF are not discussed.
>>>>>> Should I add text somewhere to make it clear the document applies only
>>>>>> to RESTCONF use of YANG Patch?
>>>>> 
>>>>> Yes, that text would be good.  It might be good to mention that there is no capability to sign or validate patches with RESTCONF as well so this is clear in the considerations. 
>>>> 
>>>> Is this addressed somewhere? I looked at Section 1 and Security Considerations, but could not find any explicit mention.
>>> 
>>> sec. 1, para 2:
>>> 
>>> This document only specifies the use of 
>>>    the YANG Patch media type with the RESTCONF protocol.
>> 
>> OK, could you make the point clear that answers my question specific to RESTCONF usage?  This would mean a little text added to clarify that there is no capability to validate the patch had not been altered from my original question.
>> 
> 
> 
> sec 5, para 1
> 
> OLD:
> 
>    The YANG Patch media type does not introduce any significant new
>    security threats, beyond what is described in
>    [I-D.ietf-netconf-restconf].  This document defines edit processing
>    instructions for a variant of the PATCH method, as used within the
>    RESTCONF protocol.
> 
> NEW:
> 
>    The YANG Patch media type does not introduce any significant new
>    security threats, beyond what is described in
>    [I-D.ietf-netconf-restconf].  This document defines edit processing
>    instructions for a variant of the PATCH method, as used within the
>    RESTCONF protocol.  Message integrity is provided by the RESTCONF
>    protocol.  There is no additional capability to validate that a
>    patch has not been altered.
> 
> Is this OK?

Yes, thank you.  That will at least make some aware of this possibility.  Please let me know when you post the updated version.

Best regards,
Kathleen 
> 
> 
> Andy
> 
> 
>  
>> 
>>  
>>>  
>>>> 
>>>>>> 
>>>>>> 
>>>>>>> >
>>>>>>> > I also see this text in the security considerations section:
>>>>>>> >   It is important for RESTCONF server implementations to carefully
>>>>>>> >   validate all the edit request parameters in some manner.
>>>>>>> >
>>>>>>> > Is the source of the patch authenticated?  Can the client receiving the
>>>>>>> > patch be authenticated?  Is this handled through RESTCONF?  Since YANG
>>>>>>> > modules could add in write capabilities, unauthenticated patches could
>>>>>>> > result in opening backdoors or revealing information that was not
>>>>>>> > intended.  You are covering it with that statement, but it's not clear if
>>>>>>> > both ends can be authenticated and there are attacks if they are not
>>>>>>> > authenticated.
>>>>>>> >
>>>>>>> >
>>>>>> 
>>>>>> 
>>>>>> It is covered by RESTCONF. Both client and server are authenticated.
>>>>> 
>>>>> Great, can you re-word the sentence to make sure it is clear that this is done with RESTCONF, but maybe not other protocols?
>>>> 
>>>> And this.
>>> 
>>> 
>>> sec 5, para 3
>>> 
>>>  For RESTCONF, both the client and server MUST be authenticated, 
>>>    according to section 2 of [I-D.ietf-netconf-restconf]. 
>> 
>> OK, thank you.
>> 
>> Best regards,
>> Kathleen
>> 
>>> 
>>> 
>>> Andy
>>> 
>>>  
>>>> 
>>>>>   
>>>>>> 
>>>>>> However, security considerations sec. has this text
>>>>>> similar to sec. 1:
>>>>>> 
>>>>>>   It may be possible to use YANG Patch with other protocols besides 
>>>>>>     RESTCONF, which is outside the scope of this document.
>>>>>> 
>>>>>> Regarding this text:
>>>>>> 
>>>>>> > Since YANG
>>>>>> > modules could add in write capabilities, unauthenticated patches could
>>>>>> > result in opening backdoors or revealing information that was not
>>>>>> > intended.  
>>>>>> 
>>>>>> I am not aware how YANG allows this vulnerability.
>>>>>> The patch represents instance data which is supposed to conform to
>>>>>> the schema nodes in the YANG modules advertised by the server.
>>>>> 
>>>>> RESTCONF doing server and client auth covers this.  Thank you. 
>>>>>> 
>>>>>> 
>>>>>>  
>>>>>>> > ----------------------------------------------------------------------
>>>>>>> > COMMENT:
>>>>>>> > ----------------------------------------------------------------------
>>>>>>> >
>>>>>>> > Nit: In section 2.2
>>>>>>> >
>>>>>>> >   YANG Patch does not provide any access to specific datastores.  It is
>>>>>>> >   am implementation detail
>>>>>>> >
>>>>>>> > s/am/an/
>>>>>> 
>>>>>> fixed
>>>>>>  
>>>>>>> >
>>>>>>> >
>>>>>> 
>>>>>> 
>>>>>> Andy
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 
>>>>> Best regards,
>>>>> Kathleen
>>>> 
>>>> Mahesh Jethanandani
>>>> [e-mail]
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> 
>> Best regards,
>> Kathleen
>