Subject: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 28 Sep 2016 14:31:49 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-14: 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:
----------------------------------------------------------------------

Thanks for the major revision, this is a lot better.  I have
one discuss point and a bunch of comments.

The discuss is: I think it's an error to mix the secure and
insecure transports in one set of protocol requirements. And
I would definitely put a DISCUSS on any protocol solution
that aims to weaken the security of e.g. port 443 or
equivalent. In other words, I think you need to rule out any
protocol solutions that weaken the secure transports that
you are re-using. I therefore suggest adding a new
requirement along these lines:

"SEC-REQ-NN: While I2RS might need to make use of both
secure and insecure transports, this MUST NOT be done in any
way that weakens the secure transport protocol, either as
used in I2RS, or especially not as used in other contexts
that do not have this requirement for mixing secure and
insecure modes of operation and that depend on security
being as good as we can provide."

So I'd like to discuss adding the above or similar.

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

- The topic of marking things as allowing insecure read
access has been discussed a lot so I won't get into it
again.

- section 4: "Data passed over the insecure transport
channel MUST NOT contain any data which identifies a person
or any "write" transactions." I don't get what identifying a
write transaction might mean?

- 4.1: "AAA protocols MAY be used to distribute these
identifiers, but other mechanism can be used." If I'm doing
TLS with mutual-auth, then I need a private key and
certificate. I don't think AAA protocols can transport those
(and they probably ought not) so I'm not sure what's meant
here.

- 4.2: What do "valid identity" and "valid identifier" mean?
If the same then use the same terms. But I think you need to
define "validity" or else say that work needs to be done
later. 

- 4.3: I think you're saying here that the i2rs client is
trusted to simply assert the secondary identifier. If so,
then saying that would be good. If not, then I don't know
what you mean.

- 4.4: I still don't see why it'd not be better to use a
different protocol for the non-secure stuff and avoid all
the potential discussion and pitfalls of trying to do all
this in one protocol.

- 4.4: "It is mandatory to use (MTU) on any I2RS client's
Write transaction or the configuration of an Event Scope
transaction." Which "it" do you mean?

- 4.4: The BCP107 stuff is still not useful.

- 4.5: "detect when the data integrity is questionable" -
I've no idea what that means. Nor what it could mean.  Can
you explain?

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 29 Sep 2016 08:05:56 -0400

Stephen: 

Version 15 has the following added: 

SEC-REQ-16:  The I2RS protocol makes use of both 
secure and insecure transports, but this use MUST NOT be 
done in any way that weakens the secure transport protocol
used in the I2RS protocol or other contexts that 
do not have this requirement for mixing secure
and insecure modes of operation.  

I tweaked the English in your text.  Does this satisfy your discuss?  If so, will you remove your DISCUSS.   I am working on version -16 to resolve your comments. 

Sue Hares 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, September 28, 2016 5:32 PM
To: The IESG
Cc: [email-masked]; Jeffrey Haas; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and 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.)

Thanks for the major revision, this is a lot better.  I have one discuss point and a bunch of comments.

The discuss is: I think it's an error to mix the secure and insecure transports in one set of protocol requirements. And I would definitely put a DISCUSS on any protocol solution that aims to weaken the security of e.g. port 443 or equivalent. In other words, I think you need to rule out any protocol solutions that weaken the secure transports that you are re-using. I therefore suggest adding a new requirement along these lines:

"SEC-REQ-NN: While I2RS might need to make use of both secure and insecure transports, this MUST NOT be done in any way that weakens the secure transport protocol, either as used in I2RS, or especially not as used in other contexts that do not have this requirement for mixing secure and insecure modes of operation and that depend on security being as good as we can provide."

- The topic of marking things as allowing insecure read access has been discussed a lot so I won't get into it again.

- section 4: "Data passed over the insecure transport channel MUST NOT contain any data which identifies a person or any "write" transactions." I don't get what identifying a write transaction might mean?

- 4.1: "AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used." If I'm doing TLS with mutual-auth, then I need a private key and certificate. I don't think AAA protocols can transport those (and they probably ought not) so I'm not sure what's meant here.

- 4.2: What do "valid identity" and "valid identifier" mean?
If the same then use the same terms. But I think you need to define "validity" or else say that work needs to be done later. 

- 4.3: I think you're saying here that the i2rs client is trusted to simply assert the secondary identifier. If so, then saying that would be good. If not, then I don't know what you mean.

- 4.4: I still don't see why it'd not be better to use a different protocol for the non-secure stuff and avoid all the potential discussion and pitfalls of trying to do all this in one protocol.

- 4.4: "It is mandatory to use (MTU) on any I2RS client's Write transaction or the configuration of an Event Scope transaction." Which "it" do you mean?

- 4.5: "detect when the data integrity is questionable" - I've no idea what that means. Nor what it could mean.  Can you explain?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Sep 2016 13:09:20 +0100

Thanks Sue,

That wording is fine and I've cleared.

Cheers,
S.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 29 Sep 2016 09:07:48 -0400

Stephen: 

This messages is to respond to your comments.   I've submitted a version 16 to deal with comments I could resolve.   I'm glad to work further with you on these comments - if you wish. 

Sue 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, September 28, 2016 5:32 PM
To: The IESG
Cc: [email-masked]; Jeffrey Haas; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)

>- section 4: "Data passed over the insecure transport channel MUST NOT contain any data which identifies a person or any >"write" transactions." I don't get what identifying a write transaction might mean?

Three types of transactions exists for the I2RS work:  Read, write, notify.   The data passed over insecure cannot identify any item that can be written so someone could use this to Act the device.  Do you have suggested wording? 
[no text added] 

> 4.1: "AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used." If I'm doing TLS with 
> mutual-auth, then I need a private key and certificate. I don't think AAA protocols can transport those (and they probably >ought not) so I'm not sure what's meant here.

I believe your comment is on: 
"SEC-REQ-03: 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. 
 AAA protocols MAY be used to distribute these identifiers, but 
 other mechanism can be used.  "

The identifiers are not identifiers at the TLS layer.  These are the application layer (management layer) identifiers.  

[no text added] 

> 4.2: What do "valid identity" and "valid identifier" mean?

Per RFC 4949 

   $ identity
      (I) The collective aspect of a set of attribute values (i.e., a
      set of characteristics) by which a system user or other system
      entity is recognizable or known. (See: authenticate, registration.
      Compare: identifier.)

   $ identifier
      (I) A data object -- often, a printable, non-blank character
      string -- that definitively represents a specific identity of a
      system entity, distinguishing that identity from all others.
      (Compare: identity.)

SEC-REQ-04 - seeks to determine that the I2RS client has a valid identity (set of attribute values) to work with this client.  
SEC-REQ-05 - seeks to determine the I2RS Agent identifier send in the I2RS protocol is a valid identifier is valid. 

The language is from RFC4949.  The asymmetry is intended in that the mechanisms for read, write, and notification utilized by NETCONF/RESTCONF over TLS use slightly different attributes to identify the I2RS Client.   The use of identity in SEC-REQ-04 encompasses the multiple identifiers.  

All of this is above the TLS layer. 
[no text added] 

>- 4.3: I think you're saying here that the i2rs client is trusted to simply assert the secondary identifier. If so, then saying that >would be good. If not, then I don't know what you mean.

This section provides the security for the multi-headed collision resolution, and the traceability of any changes. The I2RS client is trusted to simply assert the secondary identifier.   

[Text added in -16] 

>- 4.4: I still don't see why it'd not be better to use a different protocol for the non-secure stuff and avoid all the potential >discussion and pitfalls of trying to do all this in one protocol.

The management application mechanisms for notification are complex, and re-using these notification mechanisms between the secure/non-secure protocol provides a common base for these notifications.    
[no text added] 

>- 4.4: "It is mandatory to use (MTU) on any I2RS client's Write transaction or the configuration of an Event Scope transaction." > Which "it" do you mean?

Nice catch.  I've revised this text to: 

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. The default transport is a secure transport, 
   and this secure transport is mandatory to implement (MTI) in all I2RS agents,   
   and in any I2RS client which: a) performs a Write scope transaction which 
   is sent to the I2RS agent or b): configures an Event Scope transaction.  
   This secure transport is mandatory to use (MTU) on any I2RS client's Write transaction or 
   the configuration of an Event Scope transaction.

>- 4.4: The BCP107 stuff is still not useful.

The reason it is stated here is that we have routing systems being deployed with manual keys rotations rather than automatic.   The emphasis on limiting the manual keying systems. 

Since some of the data transmitted will formatted based on its content (web service up/down, peers up/down), 
Then some amount of contextual checking may indicated data is corrupted based on its content. 

Text changed to: 

Integrity of data is important even if the I2RS protocol is sending 
non-confidential data over an insecure connection. The ability 
to trace I2RS protocol messages that enact I2RS transactions 
provides a minimal aid to helping operators check how messages
enact transactions on a secure or insecure transport.
Contextual checks on specific non-confidential data sent over a 
insecure connection may indicate the data integrity is questionable.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Sep 2016 14:19:08 +0100

Hi Sue,

On 29/09/16 14:07, Susan Hares wrote:
> Stephen:
> 
> This messages is to respond to your comments.   I've submitted a
> version 16 to deal with comments I could resolve.   I'm glad to work
> further with you on these comments - if you wish.
> 
> Sue
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Wednesday, September 28,
> 2016 5:32 PM To: The IESG Cc:
> [email-masked]; Jeffrey
> Haas; [email-masked]; [email-masked]; [email-masked] Subject:
> Stephen Farrell's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and
> COMMENT)
> 
> 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.
> 
> 
DISCUSS:
> The discuss is: I think it's an error to mix the secure and insecure
> transports in one set of protocol requirements. And I would
> definitely put a DISCUSS on any protocol solution that aims to weaken
> the security of e.g. port 443 or equivalent. In other words, I think
> you need to rule out any protocol solutions that weaken the secure
> transports that you are re-using. I therefore suggest adding a new
> "SEC-REQ-NN: While I2RS might need to make use of both secure and
> insecure transports, this MUST NOT be done in any way that weakens
> the secure transport protocol, either as used in I2RS, or especially
> not as used in other contexts that do not have this requirement for
> mixing secure and insecure modes of operation and that depend on
> security being as good as we can provide."
> 
COMMENT:
> - The topic of marking things as allowing insecure read access has
> been discussed a lot so I won't get into it again.
> 
>> - section 4: "Data passed over the insecure transport channel MUST
>> NOT contain any data which identifies a person or any >"write"
>> transactions." I don't get what identifying a write transaction
>> might mean?
> 
> Three types of transactions exists for the I2RS work:  Read, write,
> notify.   The data passed over insecure cannot identify any item that
> can be written so someone could use this to Act the device.  Do you
> have suggested wording? [no text added]

Sorry but I still don't get it. If <frobble/> is potentially
writable but is also sent in a notification in clear, then
that identifies that there's a <frobble/> element, and for
most such things that'll mean someone can write it. So I
remain confused at to what you want to require here.

> 
>> 4.1: "AAA protocols MAY be used to distribute these identifiers,
>> but other mechanism can be used." If I'm doing TLS with 
>> mutual-auth, then I need a private key and certificate. I don't
>> think AAA protocols can transport those (and they probably >ought
>> not) so I'm not sure what's meant here.
> 
> I believe your comment is on: "SEC-REQ-03: 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. AAA
> protocols MAY be used to distribute these identifiers, but other
> mechanism can be used.  "
> 
> The identifiers are not identifiers at the TLS layer.  These are the
> application layer (management layer) identifiers.

You may want to clarify that. That said, if mutual-TLS is the
basis for authentication then there is a need to bind to the
identifier(s) in the client certs.

> 
> [no text added]
> 
>> 4.2: What do "valid identity" and "valid identifier" mean? If the
>> same then use the same terms. But I think you need to define
>> "validity" or else say that work needs to be done later.
> 
> Per RFC 4949
> 
> $ identity (I) The collective aspect of a set of attribute values
> (i.e., a set of characteristics) by which a system user or other
> system entity is recognizable or known. (See: authenticate,
> registration. Compare: identifier.)
> 
> $ identifier (I) A data object -- often, a printable, non-blank
> character string -- that definitively represents a specific identity
> of a system entity, distinguishing that identity from all others. 
> (Compare: identity.)
> 
> SEC-REQ-04 - seeks to determine that the I2RS client has a valid
> identity (set of attribute values) to work with this client. 
> SEC-REQ-05 - seeks to determine the I2RS Agent identifier send in the
> I2RS protocol is a valid identifier is valid.
> 
> The language is from RFC4949.  The asymmetry is intended in that the
> mechanisms for read, write, and notification utilized by
> NETCONF/RESTCONF over TLS use slightly different attributes to
> identify the I2RS Client.   The use of identity in SEC-REQ-04
> encompasses the multiple identifiers.
> 
> All of this is above the TLS layer. [no text added]

Sorry, no - I asked what "valid" means here and 4949 cannot
define that.

> 
>> - 4.3: I think you're saying here that the i2rs client is trusted
>> to simply assert the secondary identifier. If so, then saying that
>> >would be good. If not, then I don't know what you mean.
> 
> This section provides the security for the multi-headed collision
> resolution, and the traceability of any changes. The I2RS client is
> trusted to simply assert the secondary identifier.
> 
> [Text added in -16]
> 
>> - 4.4: I still don't see why it'd not be better to use a different
>> protocol for the non-secure stuff and avoid all the potential
>> >discussion and pitfalls of trying to do all this in one protocol.
> 
> The management application mechanisms for notification are complex,
> and re-using these notification mechanisms between the
> secure/non-secure protocol provides a common base for these
> notifications. [no text added]

Well, my guess is that that "common base" idea may end up being
a bad one. But we'll see later I guess.

> 
>> - 4.4: "It is mandatory to use (MTU) on any I2RS client's Write
>> transaction or the configuration of an Event Scope transaction." >
>> Which "it" do you mean?
> 
> and this secure transport is mandatory to implement (MTI) in all I2RS
> agents, and in any I2RS client which: a) performs a Write scope
> transaction which is sent to the I2RS agent or b): configures an
> Event Scope transaction. This secure transport is mandatory to use
> (MTU) on any I2RS client's Write transaction or the configuration of
> an Event Scope transaction.
> 
> The reason it is stated here is that we have routing systems being
> deployed with manual keys rotations rather than automatic.   The
> emphasis on limiting the manual keying systems.
> 
> - 4.5: "detect when the data integrity is questionable" - I've no
> idea what that means. Nor what it could mean.  Can you explain?
> 
> Since some of the data transmitted will formatted based on its
> content (web service up/down, peers up/down), Then some amount of
> contextual checking may indicated data is corrupted based on its
> content.
> 
> Text changed to:
> 
> non-confidential data over an insecure connection. The ability to
> trace I2RS protocol messages that enact I2RS transactions provides a
> minimal aid to helping operators check how messages enact
> transactions on a secure or insecure transport. Contextual checks on
> specific non-confidential data sent over a insecure connection may
> indicate the data integrity is questionable.
> 

Sorry, I'm still not getting it. Data integrity, as a network
service, is a binary yes/no thing. Questionable is not the result
from checking the output of a cryptographic function. Perhaps
you need to not use the term integrity when discussing data
sent via an insecure transport?

S.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 29 Sep 2016 09:48:49 -0400

Stephen: 

Thank you for your comments.   See below.    I've uploaded a version 17 to address these comments.  Thank you for explaining of these items 3 times. 

Sue Hares 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, September 29, 2016 9:19 AM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)

Hi Sue,

COMMENT:
>>can be written so someone could use this to attack the device.  Do you

>remain confused at to what you want to require here.

Ah... I am writing nonsense: 

Text changed to: 
Data passed over the insecure transport channel MUST NOT contain any data 
which identifies a person.

Text added in version 16
These requirements specify the requirements for I2RS peer (I2RS agent and I2RS client)
authentication. A secure transport (E.g. TLS) will authenticate based on these identities, but 
these identities are identities for the I2RS management layer. An AAA protocol distributing 
I2RS identity information SHOULD transport its information
over a secure transport.

Ah...good catch.  The word valid is the key.   See text added. 

Yes - the indication from NETCONF/RESTCONF is that they 
felt the common base was a good one.  I will be proposing the 
addition at IETF 97.   We shall see. 

>sent via an insecure transport?

Ah good catch. ... I will change the words from data integrity. 

New text: 

insecure connection may indicate the data has been modified.

S.