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 protected]] Sent: Wednesday, September 28, 2016 5:32 PM To: The IESG Cc: [email protected]; Jeffrey Haas; [email protected]; [email protected]; [email protected] 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] > 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? >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] >- 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. - 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. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
