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 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
