Subject: Re: [ippm] Adam Roach's Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Jul 2018 13:58:33 -0500

(Also not the Adam interpreter)

On Fri, Jun 29, 2018 at 12:19:53PM -0700, Mahesh Jethanandani wrote:
> Hi Spencer,
> 
> > On Jun 29, 2018, at 8:08 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> > 
> > Hi, Manesh, 
> > 
> > On Fri, Jun 22, 2018 at 2:14 PM Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> > Hi Adam,
> > 
> > > On Jun 20, 2018, at 9:41 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
> > > 
> > > Adam Roach has entered the following ballot position for
> > > draft-ietf-ippm-twamp-yang-11: 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 <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-ippm-twamp-yang/ <https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/>
> > > 
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > > 
> > > Thanks for the work and thought that everyone involved in this document spent. I
> > > find the model well described and easy to understand.
> > > 
> > > I agree with Ben's comments about including more information about the privacy
> > > and security properties of specific entities in the module. See
> > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> for specific
> > > guidance.
> > > 
> > > Since this conflicts with normative language in RFC 6087 §3.4 (and 6087bis
> > > §3.7), it is a blocking defect that needs to be remedied prior to publication.
> > 
> > I have added more nodes in the Security Considerations section.
> > 
> > I'm not the Adam Interpreter, but I'm seeing considerable new discussion about the MTI security for NETCONF and RESTCONF, and about what happens if writable nodes are modified by an attacker. Thank you for that. 
> > 
> > Adam said in his Discuss that he was agreeing with Ben's comments on this topic, and Ben's comments included this question: 
> > 
> >  Are there no nodes that are privacy (or otherwise) sensitive when just readable?
> > 
> > I didn't see any new text about this. Are there privacy-sensitive read-only nodes?
> 
> I took another look at nodes that are marked read-only in the YANG module. These nodes include session state, sent and receive packet count, last sequence number received or transmitted, start time, repeat count, tcp/ip address and port numbers etc. Nothing jumped out as particularly privacy sensitive.

In some scenarios knowing the current sequence number is useful to an
attacker, e.g., in TCP for sending off-path RST.  I don't remember enough
of how TWAMP works to say offhand whether an analogous disruption is
possible in some (unauthenticated?) cases.

> One field that did catch my attention was the ‘token’ field, which is defined as "This parameter holds the 64 octets containing the concatenation of a 16-octet Challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication; see also the last paragraph of Section 6 in RFC 4656.”
> 
> I am not a security expert, and do not know if being able to read this or other read-only information is sufficient in itself to launch an attack or disrupt an existing or new session. Maybe somebody from SEC-DIR can comment on it. If it is, I would be happy to add some text around it. 

I note that secdir is not on the recipients list, so if you want to get
specific feedback, someone will need to explicitly seek it out.

I also note that the cryptographic constructions used for TWAMP are quite
diverged from current best practices and appear to be fragile at best.  So
someone doing such an analysis might have to go through a fair amount of
effort to reach a conclusion (part of why I did not attempt such analysis
myself).  It might be safest to assume that being able to read the token
field gives an attacker the ability to disrupt a test session.

-Benjamin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 1 Jul 2018 13:55:21 -0700

Hi Ben,

Sent from my iPhone
> On Jul 1, 2018, at 11:58 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

That is correct. But we do not store the sequence number, so they would have to snoop the traffic to get the sequence number which they can, whether they have the IP address/port number from the twamp module or not. 

> field gives an attacker the ability to disrupt a test session.

Ok. I will write something up for the 'token' attribute.

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Jul 2018 13:32:08 -0500

Thanks for addressing the various comments I made -- your resolutions 
all seem good to me. One comment on the security section, below:

On 6/22/18 2:14 PM, Mahesh Jethanandani wrote:
>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines for specific
>> guidance.
>>

Thanks. This is an improvement, but I'm still a bit concerned about the 
fact that the section speaks only in examples ("examples include" and 
"nodes such as") rather than explicitly identifying sensitive nodes, 
which is what I believe RFC 6087 anticipates. I also don't think that 
simply stating that the attacks that result from changing certain 
parameters "are obvious" is enough to satisfy either the spirit or 
letter of what is intended by:

>     In particular, writable data nodes that could be especially
>     disruptive if abused MUST be explicitly listed by name and the
>     associated security risks MUST be spelled out.
>

/a

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 2 Jul 2018 12:47:14 -0700

Hi Adam,

> On Jul 2, 2018, at 11:32 AM, Adam Roach <[email-masked]> wrote:
> 
> Thanks for addressing the various comments I made -- your resolutions all seem good to me. One comment on the security section, below:
> 
> Thanks. This is an improvement, but I'm still a bit concerned about the fact that the section speaks only in examples ("examples include" and "nodes such as") rather than explicitly identifying sensitive nodes, which is what I believe RFC 6087 anticipates. I also don't think that simply stating that the attacks that result from changing certain parameters "are obvious" is enough to satisfy either the spirit or letter of what is intended by:
> 
>> In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out.
>> 
How about this?

OLD:

   Nodes such as 'admin-state' that cause test sessions to be created,
   or 'number-of-packets' that dictate how many packets are sent in any
   particular test session are obvious.  Examples of nodes that are
   particularly vulnerable include several timeout values put in the
   protocol to protect against sessions that are not active but are
   consuming resources.  Examples include the REFWAIT timeout parameter
   which determine whether to discontinue the session if no packets are
   received.  Nodes like 'count' and 'max-count-exponent' can cause a
   long time to be spent on PBKDF2 iterations.  In addition, nodes such
   as 'dscp' marked with different DSCP markings, can cause the test
   traffic on the network to be skewed, and the result manipulated.
   Finally, nodes within 'mode-preference-chain' which specify the
   'mode' and 'priority' values and indicate the preferred order of use
   by an operator, can for example, be manipulated to send
   unauthenticated or non-encrypted traffic, enabling a MITM attack.
   Limiting access to these nodes will limit the ability to launch an
   attack in network environments.

NEW:

   If written, the 'admin-state' node can cause unintended test sessions to be 
   created. If the node 'number-of-packets' that dictates how 
   many packets are sent in any particular test session is written 
   with a large value, it can cause a test session to run longer 
   than expected.  Nodes that are
   particularly vulnerable include several timeout values put in the
   protocol to protect against sessions that are not active but are
   consuming resources.  These are the REFWAIT timeout parameter
   which determine whether to discontinue the session if no packets are
   received, and nodes 'count' and 'max-count-exponent’ which can cause a
   long time to be spent on PBKDF2 iterations.  In addition,
   'dscp’ node marked with different DSCP markings, can cause the test
   traffic on the network to be skewed, and the result manipulated.
   Finally, nodes within 'mode-preference-chain' which specify the
   'mode' and 'priority' values and indicate the preferred order of use
   by an operator, can be manipulated to send
   unauthenticated or non-encrypted traffic, enabling a MITM attack.
   Limiting access to these nodes will limit the ability to launch an
   attack in network environments.

> /a

On the question of nodes that are privacy sensitive when they are readable, here is the text I was planning on adding.

"The ‘token’ node defined in the model, containing a concatenation of a Challenge, AES Session-key used for encryption, and HMAC-SHA1 Session-key used for authentication, is sensitive from a privacy perspective, and can be used to disrupt a test session. The ability to read the field should be limited to the administrator of the test network.”

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Jul 2018 15:03:33 -0500

Thanks for a quick response! These both look good to me. I'll clear my 
discuss when the next version of the document comes out.

/a

On 7/2/18 2:47 PM, Mahesh Jethanandani wrote:
> Hi Adam,
>
>> On Jul 2, 2018, at 11:32 AM, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Thanks. This is an improvement, but I'm still a bit concerned about 
>> the fact that the section speaks only in examples ("examples include" 
>> and "nodes such as") rather than explicitly identifying sensitive 
>> nodes, which is what I believe RFC 6087 anticipates. I also don't 
>> think that simply stating that the attacks that result from changing 
>> certain parameters "are obvious" is enough to satisfy either the 
>> spirit or letter of what is intended by:
>>
> On the question of nodes that are privacy sensitive when they are 
> readable, here is the text I was planning on adding.
>
> "The ‘token’ node defined in the model, containing a concatenation of 
> a Challenge, AES Session-key used for encryption, and HMAC-SHA1 
> Session-key used for authentication, is sensitive from a privacy 
> perspective, and can be used to disrupt a test session. The ability to 
> read the field should be limited to the administrator of the test 
> network.”
>
> Thanks.
>
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
>