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

[Andy Bierman <[e-mail]>]

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 <mjethanandani@gm
>>>> ail.com> 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/s
>>>>> tatement/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?



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
>> <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-13#ref-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
>