Subject: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 14:11:27 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-07: 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-i2rs-protocol-security-requirements/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In section 3.4, the text says that the requirements that the integrity
protection mechanisms can actually provide integrity protection are
SHOULD because some communication may occur over non-secure channels.
That does not follow, since the rationale is about use, while the actual
requirement is about capability.  As currently written, it leaves it
possible for people to select a protocol that cannot provide integrity
protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS.

In the third paragaph of 3.2, Isn't the point to say that ephemeral data
MUST be sent over a secure transport unless the data model explicitly
labels it as safe for insecure transports? As written, it seems to leave
room to send data that is not labeled as safe to also be sent over
insecure transports.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-2.1: I am on the fence about other's comments about copying definitions
here--but if you do copy them here, it seems strange to not mention
"client" or "agent".

I agree with Alissa about equating privacy and confidentiality.

-3.1,: 
I’m confused by the first paragraph. I don’t find strings of the form of
SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

It’s not clear to me how 5 and 6 differ. Is it just a matter of the
additional “before establishing a connection” part in 6?

-3.4: Isn't 15 simply a restatement of the third item under 14?

3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do
they simply recognize reality, or to they  grant permission?)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Aug 2016 18:04:56 -0400

Making sure I understand what is being asked in each of these items, 
hence in-line.
Yours,
Joel

> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/

I think what you are asking is that we rephrase these requirements to 
indicate that implementations must include integrity protection 
capability which meets these requirements.  And that the current text 
explaining the SHOULD becomes text about when these mechanisms SHOULD be 
used?

> room to send data that is not labeled as safe to also be sent over

I am having trouble seeing the problem.  The text, as far as I can tell, 
says "SHOULD be protect", and then goes on to say "except when the model 
says it is okay to send unprotected".  That seems to say the right thing.

I can live with just listing the terms and references, without the text. 
  It makes reading a little more complex for new readers, but avoids any 
risk of error in copying.

> I agree with Alissa about equating privacy and confidentiality.

I was going to simply say "sure", but REQ-20 sems to need to still say 
"privacy".  Not sure what you (individually or collectively) would like 
us to do.
I do note that if the terminology has shifted from that documented in 
4949, it would be helpful to those of us who do not live with it daily 
to have some way to know such.

> SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

Section 3.1 is trying to recapitulate for context requirements that are 
stated in textual form in RFC 7921.  No, they are not lsited as 
SEQ_REQ-XX or even REQ-XX in RFC 7921.  Thus, in addition to context, 
listing them here allows us to give them numbers for consistency of 
discussion.  (Thus, this is a case where repetition adds value.)

> additional “before establishing a connection” part in 6?

As far as I know, it is indeed just a matter of the timing being added 
in 6.  If this is a problem, we can collapse them.

> -3.4: Isn't 15 simply a restatement of the third item under 14?

that looks like an error on our part.  Maybe I missed something, but I 
think we can drop that when we rewrite to address your major comment.

> they simply recognize reality, or to they  grant permission?)

Re-reading these, the MAY in 19 is a description of allowed 
architecture, and seems to me to wall within the 2119 meaning.
The may in 20 is subtler.  I think it is recognizing reality, since that 
mechanism is not something we are going to be defining, as far as I 
know.  It can be argued that it is saying that these requirements allow 
such a range of mechanism.  But I agree that 2119 usage is a bit of a 
stretch there.

>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 17:53:01 -0500

> On 8/17/16 5:11 PM, Ben Campbell wrote:

[...]

> explaining the SHOULD becomes text about when these mechanisms SHOULD 
> be used?
>

Yes.

> I am having trouble seeing the problem.  The text, as far as I can 
> tell, says "SHOULD be protect", and then goes on to say "except when 
> the model says it is okay to send unprotected".  That seems to say the 
> right thing.

I take "SHOULD except..." to mean something fundamentally different than 
"MUST except..." SHOULD allows the implementers (or I guess protocol 
designers in this case) the additional flexibility of deciding they have 
some other good reason to deviate from the guidance, in addition to 
whatever might be list. Is that the intent here?

> I can live with just listing the terms and references, without the 
> text.  It makes reading a little more complex for new readers, but 
> avoids any risk of error in copying.

I think that's a good answer to other people's comments :-) My comment 
was, _if_ this draft continues to mention the defined terms, it would be 
good to also mention client and agent.

> "privacy".  Not sure what you (individually or collectively) would 
> like us to do.

It probably makes sense to keep this discussion in the thread from 
Alissa's comments.

> Section 3.1 is trying to recapitulate for context requirements that 
> are stated in textual form in RFC 7921.  No, they are not lsited as 

It think some clarification text would be in order. (I am agnostic about 
Mirja's and Alissa's comments about whether these should be replicated 
at all.)

> in 6.  If this is a problem, we can collapse them.

I'm okay either way on this one.

> think we can drop that when we rewrite to address your major comment.

Okay. The odd part is that 15 seems to recognize that it's just a 
restatement :-)

> architecture, and seems to me to wall within the 2119 meaning.

Is the MAY in 19 a materially new statement, or is that already covered 
in the architecture? If the latter, something to the effect of "The 
architecture allows..." might make more sense.

> The may in 20 is subtler.  I think it is recognizing reality, since 
> that mechanism is not something we are going to be defining, as far as 
> I know.  It can be argued that it is saying that these requirements 
> allow such a range of mechanism.  But I agree that 2119 usage is a bit 
> of a stretch there.
>
>>
>>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Aug 2016 20:51:41 -0400

Ben: 

Does the following text work for section 3.4 
==============================

SEC-REQ-14: An integrity protection mechanism for I2RS MUST be provided
that will be able to ensure the following: 

1) the data being protected is not modified without detection during 
its transportation,  

2) the data is actually from where it is expected to come from, and 

3) the data is not repeated from some earlier interaction of the protocol.
(That is, when both confidentiality and integrity of data is properly protected, it 
is possible to ensure that encrypted data is not modified
or replayed without detection.)

SEC-REQ-15: The I2RS protocol MUST provide a mechanism for data integrity 
that insure the message data is not repeated, and that the secure transport between  
I2RS client to I2RS agent MUST be able to protect against replay attack

Requirements SEC-REQ-14 and SEC-REQ-15 are requirements for the secure 
channel which must be supported as the default by every I2RS Agent, and 
by every I2RS client communicating over a secure transport.    
In order to provide some traceability or notification for the non-secure protocol,
SEC-REQ-16 suggests traceability and notification are important to include for
any non-secure protocol.

SEC-REQ-16: The I2RS protocol MUST provide a mechanism for 
message traceability and notification requirements 
requirements found in <xref target="RFC7922"></xref> and
<xref target="RFC7923"></xref> that can be supported 
in communication channel that is non-secure to trace or notify about potential
security issues.

--------------
If so, I will place this in version-08.txt. 

I've merged SEC-REQ-05 and SEC-REQ-06 in version -08.txt 

Sue 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, August 17, 2016 6:53 PM
To: Joel M. Halpern
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[...]

>> In section 3.4, the text says that the requirements that the 
>> integrity protection mechanisms can actually provide integrity 
>> protection are SHOULD because some communication may occur over 
>> non-secure channels.
>> That does not follow, since the rationale is about use, while the 
>> actual requirement is about capability.  As currently written, it 
>> leaves it possible for people to select a protocol that cannot 
>> provide integrity protection at all. I think the SHOULDs in 14 and 15 
>> need to be MUSTS.
>

Yes.

>>
>> In the third paragaph of 3.2, Isn't the point to say that ephemeral 
>> data MUST be sent over a secure transport unless the data model 
>> explicitly labels it as safe for insecure transports? As written, it 
>> seems to leave room to send data that is not labeled as safe to also 
>> be sent over insecure transports.
>

I take "SHOULD except..." to mean something fundamentally different than "MUST except..." SHOULD allows the implementers (or I guess protocol designers in this case) the additional flexibility of deciding they have some other good reason to deviate from the guidance, in addition to whatever might be list. Is that the intent here?

>>> -2.1: I am on the fence about other's comments about copying 
>>> definitions here--but if you do copy them here, it seems strange to 
>>> not mention "client" or "agent".
>>
>> [Joel] I can live with just listing the terms and references, without the 

>>I think that's a good answer to other people's comments :-) My comment was, _if_ this draft continues to mention the defined terms, it would be good to also mention client and >agent.

Sue: Clarifying question - are you suggestion this removal of the security definitions (section 2.1) or for section 2.2 as well?  

I am concern that it makes the reading of the requirements harder for the netconf/restconf people.  Since this is a re-use protocol, this requirements specification will go right into the validation of the NETCONF/RESTCONF as having the appropriate protocols.   There will be new readers in these WG that do not have the security background - so reducing complexity is useful here.  

> like us to do. I do note that if the terminology has shifted from that documented in 

REQ-20 states privacy that relates to pervasive privacy RFCs?  What do you want us to do here? 
A suggestion would be useful.  We will be utilizing this in the NETCONF/NETMOD/I2RS discussions - so helpful comments. 

>Mirja's and Alissa's comments about whether these should be replicated 

Sue: This is a practical matter. Without these explicit comments, the design discussion between I2RS/NETCONF/NETMOD were running into problems.  We are numbering these expansions and giving them specific requirements so that the protocol which fulfills these requirements (e.g. NETCONF, RESTCONF, IPFIX) can be judged on these specific requirements. 

>I'm okay either way on this one.

I have merged these into one requirement.  

>>Okay. The odd part is that 15 seems to recognize that it's just a 

Addressed in version 8.  

>architecture allows..." might make more sense.

This was written to provide additional clarification to the NETCONF/NETMOD group beyond the architecture document. 

> allow such a range of mechanism.  But I agree that 2119 usage is a bit 

Sue: Here we are trying to give the NETCONF/NETMOD folks an example of what the I2RS WG is thinking.