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

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 1 Nov 2016 07:15:33 -0700

Authors,

Can we address Kathleen's comments?

Mahesh Jethanandani
[email-masked]

> On Oct 31, 2016, at 8:28 AM, Kathleen Moriarty <[email-masked]> 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?
> 
> 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.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Nit: In section 2.2
> 
>   YANG Patch does not provide any access to specific datastores.  It is
>   am implementation detail
> 
> s/am/an/
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Nov 2016 14:21:57 -0700

On Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <[email-masked]
> wrote:

> > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-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?

> > both ends can be authenticated and there are attacks if they are not

It is covered by RESTCONF. Both client and server are authenticated.

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

fixed

Andy

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 3 Nov 2016 09:35:30 -0400

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 <[email-masked]> wrote:

>
>
> On Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <
> [email-masked]> wrote:
>
>> Authors,
>>

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.

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

> the schema nodes in the YANG modules advertised by the server.

RESTCONF doing server and client auth covers this.  Thank you.

>> >   YANG Patch does not provide any access to specific datastores.  It is

Thank you!

-- 

Best regards,
Kathleen

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 11 Nov 2016 22:04:29 +0800

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 <[email-masked]> wrote:
> 
> Hi Andy,
> 
> On Tue, Nov 1, 2016 at 5:21 PM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> Authors,
> 
> [email-masked] <mailto:[email-masked]>
> 
> > On Oct 31, 2016, at 8:28 AM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ <https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/>
> >
> >
> >
> The security requirements for protocols other than RESTCONF are not discussed.
> 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.

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

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Nov 2016 09:08:11 -0800

On Fri, Nov 11, 2016 at 6:04 AM, Mahesh Jethanandani <
[email-masked]> 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 Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <mjethanandani@
>> gmail.com> wrote:
>>
>>> Authors,
>>>
> 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
> 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.

> done with RESTCONF, but maybe not other protocols?

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 12 Nov 2016 19:45:44 -0500

Hello,

Thanks for your responses, inline.

On Fri, Nov 11, 2016 at 12:08 PM, Andy Bierman <[email-masked]> wrote:

>>> On Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <mjethanandani@gm
>>> ail.com> wrote:
>>>
>>>> Authors,
>>>>

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.

> <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-13#ref-I-D.ietf-netconf-restconf>

OK, thank you.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Andy Bierman <[email-masked]>
Date: Sat, 12 Nov 2016 22:10:40 -0800

> is no capability to validate the patch had not been altered from my

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

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

---

From: [email-masked]
Date: Sun, 13 Nov 2016 19:42:51 +0900

Please excuse typos, sent from handheld device 

> On Nov 13, 2016, at 3:10 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
>> On Sat, Nov 12, 2016 at 4:45 PM, Kathleen Moriarty <[email-masked]> wrote:
>> Hello,
>> 
>>>> On Fri, Nov 11, 2016 at 6:04 AM, Mahesh Jethanandani <[email-masked]> wrote:
>>>> Andy,
>>>> 
>>>>>>> On Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <[email-masked]> wrote:
>>>>>>> Authors,
>>>>>>> 
>> 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:
> 

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 
>>>    according to section 2 of [I-D.ietf-netconf-restconf]. 
>> 
>> OK, thank you.
>> 
>> Best regards,
>> Kathleen
>> 
>>> 
>>> 
>>> Andy
>>> 
>>>  
>>>> 
>>>>>   
>>>>>>