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

[Andy Bierman <[e-mail]>]

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@
>> gmail.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/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.


>
>
>>
>> >
>>> > 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>
].


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]
>
>
>
>