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