+ more > From: Stephen Farrell, May 17, 2016 2:24 PM > > > Hiya, > > On 17/05/16 18:45, Eric Voit (evoit) wrote: > > Hi Stephen, > > > >> Stephen Farrell, May 03, 2016 8:23 PM > >> > >> Stephen Farrell has entered the following ballot position for > >> draft-ietf-i2rs-pub-sub-requirements-06: 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-pub-sub-requirements/ > >> > >> > >> > >> > >> > ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> > >> > >> > I have what I hope are two very easily sorted things that I'd like to > chat about: > >> > >> (1) 4.2.5, para2: > > It's para 3 now. Not sure if that changed in this rev or if > I goofed. If the latter, apologies;-)
Yes. That is what caught me too. I was answering for Paragraph 2. > >> Hang on - this is 2016 isn't it? :-) Why would we > >> ever have a pub/sub service whose subscribers can pretend to be the > >> service? > > > > I am not sure I understand. The Subscription Service is located on > > the Publisher. Having the Publisher and Subscriber mutually > > authenticate each other makes sense. > > > > If you mean something else and you are wondering if whether a > > Subscriber can also be a Publisher for the information it receives, > > yes it can. Having a collector/controller as a middle-man is a very > > valid implementation. But there is nothing which binds such > > independent subscriptions together. > > The problem is that the text says "it SHOULD be possible to provide > cryptographic authentication in such a way that no Subscriber can > pose as the original Subscription Service" > > I see no reason for that SHOULD. The implication I take from it > is that someone wants to use purely symmetric keying which seems > pretty odd. I'd say better text would be to say that "Subscribers > MUST NOT be able to pose as the original Subscription Service" > maybe. Your text is better. Changed. > > > >> (2) Don't you need a statement somewhere that commensurate security > >> needs to be provided for pushed notifications as was used for the > >> original subscription? That might be a little hard to phrase > >> correctly but I hope we agree that the notifications ought not be > >> significantly less secure than the subscription. > > > > We had some interactions with Ben Campbell on this topic. In > > general we are doing our best to decouple the subscription > > establishment and maintenance from the underlying transport options. > > This is because there are implementations (for example wholly within > > an MSDC) which don't require payload encryption. Still most > > implementations should have transport encryption. So after several > > interactions with Ben, the text leading off Section 4.2.5 now reads: > > > > Some uses of this Subscription Service will push privacy-sensitive > > updates and metadata. Good deployment practices will bind this > > generated information within secure, encrypted transport layer > > mechanisms. For example if NETCONF is used as transport, then > > [RFC5539] would be a valid option to secure the transported > > information. The Subscription Service can also be used with > > emerging deployment contexts as well. As an example, deployments > > based on [i2rs-usecase] can apply these requirements in conjunction > > with those documented within [i2rs-protocol-security] to secure > > ephemeral state information being pushed from a Network Element. > > > > Does this hit your objective? > > Not quite, though it is related. > > If you added "Commensurate strength security mechanisms MUST > be defined (and SHOULD be used) for all of the stages of > the pub/sub process, for example using the same algorithms > and endpoints for keying for both subscription and publication > stages would seem advisable." > > The thing to avoid is e.g. using some really strong mechanism > for the subscription but something much weaker or with worse > endpoints for the publication (or vice versa). > > Sorry if that wording is a bit vague, I didn't re-read the > entire doc to get the context right. I see what you are getting at now. How about the requirement text: "For any encrypted information exchanges, commensurate strength security mechanisms MUST be available and SHOULD be used. This includes all stages of the Subscription and update push process." Thanks, Eric > Cheers, > S. > > > > > Eric > > > >> > >> ---------------------------------------------------------------------- > >> > >> > COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> > >> > - I wondered if this was maybe of interest to more than just i2rs, and > if so, > >> whether any effort had been made to try figure out if these > >> requirements work for folks who don't care about i2rs? It'd seem a > >> shame to work on this but stop one step short of being > >> appropriately general. (But you probably already checked that I > >> guess.) > >> > >> - 4.2.2, last para: The MUST here seems like it may be quite > >> onerous, in general. Did someone think all of that through? For > >> example, what if the reason for declining is that the Subscriber > >> doesn't have sufficient privilege? Saying what privilege is needed > >> would be a breach of least-privilege. Transient errors may also > >> make this very hard to do well. I'd suggest s/MUST/MAY/ and to also > >> turn the information returned into a hint and not a promise. > >> > >> - 4.2.5, para 1: saying there "MUST be mutual authentication" is > >> odd - the usual terms would be "MUST implement" or "MUST use" which > >> of those does "MUST be" mean? > >> > >> - 4.2.8: when you say fetch... by whom? Is there an implicit > >> requirement in the title of the subsection? > >> > >> > >> _______________________________________________ i2rs mailing list > >> [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
