Subject: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT)

From: "Alvaro Retana" <[email-masked]>
Date: Wed, 17 Aug 2016 18:53:27 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-07: No Objection

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/

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

I have the same concerns as others around the secure transport, but I'm
not putting in a DISCUSS because the concerns are already well
represented.  Just one additional comment on the topic:

I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol
MUST be able to transfer data over a secure transport and optionally MAY
be able to transfer data over a non-secure transport") and this text from
Section 3. (Security-Related Requirements): "…MUST be able to exchange
data over a secure transport, but some functions may operate on a
non-secure transport."  The latter text talks bout "some functions" using
a non-secure transport, while SEC-REQ-09 implies that everything may use
it.

Other comments from Section 3.1. (Mutual authentication of an I2RS client
and an I2RS Agent) 

-- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture]
sets the following requirements".  I'm not sure what you mean my "sets",
as there are no requirements (labeled as such) in the architecture
document.  If there are, then this section doesn't seem to be needed (as
others have mentioned).  Maybe "these requirements are derived from the
architecture", or something similar may be more appropriate.

-- What is a "valid identifier"?  A couple of requirements where a "valid
identifier" "MUST" be confirmed are listed, but no indication as to what
that may be in this document or the architecture one.   The definition of
identifier doesn't help…

-- SEC-REQ-05 and SEC-REQ-06 sound the same to me.  What is the
difference?  BTW, if there is a difference, instead of "IETF" I think
that "standardized" may be better.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Aug 2016 22:36:11 -0400

Alvaro: 

I just uploaded version -08.txt.  Please review it to see if has changed your feelings on the secure transport.   See comments below. 

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]] 
Sent: Wednesday, August 17, 2016 9:53 PM
To: The IESG
Cc: [email-masked]; Jeffrey Haas; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT)

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

>I have the same concerns as others around the secure transport, but I'm not putting in a DISCUSS because the concerns are already well represented.  Just one additional comment >on the topic:

Please see if I have answered these questions in version -08.txt and in the email. If not, please let me know. 

>I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a >non-secure transport") and this text from Section 3. (Security-Related Requirements): "…MUST be able to exchange data over a secure transport, but some functions may operate >on a non-secure transport."  The latter text talks bout "some functions" using a non-secure transport, while SEC-REQ-09 implies that everything may use it.

I do not see the contradiction in -08.txt.  

"The I2RS client and I2RS agent using the I2RS protocol MUST be able to exchange 
data over a secure transport, but some functions may operate on a non-secure
transport." 

This says the I2RS client and I2RS agent must support using the I2RS protocol over a security transport, but I2RS client software and I2RS agent software may operate on non-secure transport.  

Other comments from Section 3.1. (Mutual authentication of an I2RS client and an I2RS Agent) 

>-- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements".  I'm not sure what you mean my "sets", as there are no requirements 
> labeled as such) in the architecture document.  If there are, then this section doesn't seem to be needed (as others have mentioned).  Maybe "these requirements are derived 
> from the architecture", or something similar may be more appropriate.

You are correct, the I2RS architecture does not label such requirements.  

We got into discussing a strawman protocol, and we found we needed to restate the I2RS architecture documents design in the specific requirements listed now in version 8 as:  SEC-REQ-01 to SEC-REQ-07.   In this case the restatement is useful (see Joel's comment).  Do you have a suggestion for another term than "sets".  

>-- What is a "valid identifier"?  A couple of requirements where a "valid identifier" "MUST" be confirmed are listed, but no indication as to what

Actually, the security people indicated that a "valid identifier" was the appropriate term.  You have an identity which is expressed as an identifier. The identifier can (or cannot be) a valid identifier for the identity.   Identity consists of loss of features.  An identifier is the way to express the identity in a protocol. 

>  SEC-REQ-05 and SEC-REQ-06 sound the same to me.  What is the difference?  BTW, if there is a difference, instead of "IETF" I think that "standardized" may be better.

Merged these into one in version -08.txt .  Let me know what you think of the merge. 

Sue

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 18 Aug 2016 02:53:28 +0000

On 8/17/16, 9:36 PM, "iesg on behalf of Susan Hares"
<[email-masked] on behalf of [email-masked]> wrote:

Sue:

Hi!

...
>>be able to transfer data over a >non-secure transport") and this text
>>from Section 3. (Security-Related Requirements): "ŠMUST be able to
>>exchange data over a secure transport, but some functions may operate
>>>on a non-secure transport."  The latter text talks bout "some
>>>functions" using a non-secure transport, while SEC-REQ-09 implies that
>>>everything may use it.
>
>non-secure
>This says the I2RS client and I2RS agent must support using the I2RS
>protocol over a security transport, but I2RS client software and I2RS
>agent software may operate on non-secure transport.

-08 still has these two pieces of text:

"SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure
transport and optionally MAY be able to transfer data over a non-secure
transport."

...and...

>From Section 3: "...MUST be able to exchange data over a secure transport,
but some functions may operate on a non-secure transport."

Again, the difference is that the latter text mentions "some functions"
(which seems in line with the changes you made in this version to
highlight that not everything could be run over an insecure transport),
while SEC-REQ-08 basically says that the i2rs protocol MAY be run over
non-secure transport -- but it doesn't limit the i2rs protocol to some
functions or some type or information.

>>-- The text says that the "I2RS architecture
>>[I-D.ietf-i2rs-architecture] sets the following requirements".  I'm not
>>sure what you mean my "sets", as there are no requirements
>> labeled as such) in the architecture document.  If there are, then this
>>section doesn't seem to be needed (as others have mentioned).  Maybe
>>"these requirements are derived
>We got into discussing a strawman protocol, and we found we needed to
>restate the I2RS architecture documents design in the specific
>requirements listed now in version 8 as:  SEC-REQ-01 to SEC-REQ-07.   In
>this case the restatement is useful (see Joel's comment).  Do you have a
>suggestion for another term than "sets".

See above.

...
>
>
>>  SEC-REQ-05 and SEC-REQ-06 sound the same to me.  What is the

Now the single requirement just sounds redundant...

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Aug 2016 23:03:23 -0400

Alvaro: 

How about the following for the introduction to section 3:

The security for the I2RS protocol requires mutually authenticated I2RS
clients
and I2RS agents. The I2RS client and I2RS agent using the I2RS protocol MUST
be able to exchange 
data over a secure transport.  Optionally, the I2RS Client and I2RS agent
MAY operate
on a non-secure transport to transfer a specific set of non-confidential
data 

I think this matches SEC-REQ-08 

SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
   secure transport and optionally MAY be able to transfer data over a
   non-secure transport.  A secure transport MUST provide data
   confidentiality, data integrity, and replay prevention.

The default I2RS transport is a secure transport. 

A non-secure transport can be used for publishing telemetry data 
or other operational state that was specifically indicated to
non-confidential in the data model in the Yang syntax.  
Anything not specifically marked as "non-confidential" MUST 
be transmitted over a secure transport connection. 

The configuration of ephemeral data in the I2RS Agent by the 
I2RS client SHOULD be done over a secure transport. It is anticipated
that the passing of most I2RS  ephemeral state operational 
status SHOULD be done over a secure transport.  
As draft-ietf-i2rs-ephemeral-state  notes
data model MUST indicate whether the transport
exchanging the data between I2RS client and I2RS agent is 
secure or insecure. The default mode of transport is 
secure so data models SHOULD clearly annotate what data nodes can 
be passed over an insecure connection.

What do you think? 

For SEC-REQ-05, I re-read it now and it is redundant.  I changed to: 

SEC-REQ-05: Identifier distribution and the loading of these identifiers
into I2RS agent
 and I2RS Client SHOULD occur outside the I2RS protocol prior to the 
 I2RS protocol establishing a connection between I2RS client and I2RS agent.

 (One mechanism such mechanism is AAA protocols.)

What do you think? 

These will be uploaded in a version -09.txt 

Sue 

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[email-masked]] 
Sent: Wednesday, August 17, 2016 10:53 PM
To: Susan Hares; 'The IESG'
Cc: 'Jeffrey Haas'; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Alvaro Retana's No Objection on
draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT)

Sue:

Hi!

...
>
>>I think there is a contradiction between SEC-REQ-09 ("The I2RS 
>>protocol MUST be able to transfer data over a secure transport and 
>>optionally MAY be able to transfer data over a >non-secure transport") 
>>and this text from Section 3. (Security-Related Requirements): "ŠMUST 
>>be able to exchange data over a secure transport, but some functions 
>>may operate
>>>functions" using a non-secure transport, while SEC-REQ-09 implies 
>>>that everything may use it.
>
>"The I2RS client and I2RS agent using the I2RS protocol MUST be able to 
>on a non-secure transport."
>

...and...

Again, the difference is that the latter text mentions "some functions"
(which seems in line with the changes you made in this version to highlight
that not everything could be run over an insecure transport), while
SEC-REQ-08 basically says that the i2rs protocol MAY be run over non-secure
transport -- but it doesn't limit the i2rs protocol to some functions or
some type or information.

>>[I-D.ietf-i2rs-architecture] sets the following requirements".  I'm 
>>not sure what you mean my "sets", as there are no requirements  
>>labeled as such) in the architecture document.  If there are, then 
>>this section doesn't seem to be needed (as others have mentioned).  
>>Maybe "these requirements are derived  from the architecture", or 
>>something similar may be more appropriate.
>
>this case the restatement is useful (see Joel's comment).  Do you have 
>a suggestion for another term than "sets".

See above.

...

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 18 Aug 2016 03:12:53 +0000

On 8/17/16, 10:03 PM, "iesg on behalf of Susan Hares"
<[email-masked] on behalf of [email-masked]> wrote:

Hi!

>I think this matches SEC-REQ-08

It does. 

Now that the text is in sync, it makes me wonder why it needs to be
mentioned twice (and not just in the requirements section).

...
> (One mechanism such mechanism is AAA protocols.)

Looks good to me.

Thanks!

Alvaro.