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 protected]] Sent: Thursday, September 29, 2016 9:19 AM To: Susan Hares; 'The IESG' Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT) 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 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 attack 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. Ah... I am writing nonsense: Text changed to: Data passed over the insecure transport channel MUST NOT contain any data which identifies a person. > >> 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. 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. > > [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. Ah...good catch. The word valid is the key. See 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] Well, my guess is that that "common base" idea may end up being a bad one. But we'll see later I guess. 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. > >> - 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? Ah good catch. ... I will change the words from data integrity. New text: 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 has been modified. S. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
