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

[Stephen Farrell <[e-mail]>]

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

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.