[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsn] Use case for double opt-in and other mechanisms for preventing unwanted subscriptions
Patil, Sanjay wrote: > > I am not sure if DOI completely solves the security concern you > mention, that is - rogue Subscriber targeting innocent Consumers via > NP (that allow third-party subscriptions). The DOI model requires not > just NP and Consumer both to support the DOI specific message > exchange, but it also largely depends upon the NP and Consumer > actually using the DOI protocol every single time a new Subscription > is made. Basically, I think that a security model is hard to enforce > when its design depends upon responsibilities distributed across > roles (which themselves may belong to different trust domains, making > it further complicated). Again, the idea is that we are protecting the /producer/ from being used as a means to spam innocent consumers. We can assume that the producer will act in its own best interests. A rogue producer could spam a consumer, but then a rogue subscriber could instead spam the user directly. Does that clarify? > > A better alternative for designing security may be to ensure that the > security solution for every role is self contained, and is applicable > in terms of every single message exchange such as ... > a> When a NP receives a Subscription request, it should be able to > verify that the Subscriber is genuine, and the Consumer-Subscriber > relationship is authentic. That's certainly a viable approach, but it may not always be feasible. Even if it's not, the NP may also ask the Consumer directly, if it knows how. > b> When a Consumer receives a Notification message, it should be able > to verify that the NP is authentic, and the notifications are based on > a valid Subscription. > > I am no security expert, but my general feeling here is that the above > model calls for a WSS style security, which I believe is in terms of > individual message exchanges and not based on a separate protocol for > trust (DOI, etc.). > > Thanks, > Sanjay > > -----Original Message----- > *From:* David Hull [mailto:dmh@tibco.com] > *Sent:* Monday, Nov 22, 2004 18:47 PM > *To:* Patil, Sanjay > *Cc:* wsn@lists.oasis-open.org > *Subject:* Re: [wsn] Use case for double opt-in and other > mechanisms for pre venting unwanted subscriptions > > Patil, Sanjay wrote: > >> >> Hi David, >> >> Just to be clear - Are you proposing DOI as a solution for the >> security concern of Consumer receiving unwanted Notifications. If >> yes, then I am not sure how it will work. DOI in essence depends >> upon a discipline followed by the NP to contact Consumer before >> bombarding it with Notifications. A rouge NP may not heed such a >> discipline to begin with. > > DOI will not stop a rogue NP. It's really aimed at protecting an > honest NP from rogue Subscribers. I think this is why I found > Tom's questions confusing. This is all centered around the > Subscriber-NP interaction. It happens, though, that in some cases > the NP will want to discuss the matter with the Consumer. If the > consumer doesn't know how to help with that, the NP may not be > able to approve the subscription. > > Let's drop back to current technology. I register for some > subscription service from a well-known commercial source, which I > trust because it has some well-known company's name on it. Before > that well-known company starts pumping messages at me, it sends me > a test message saying "did you really ask for this?". I send back > "yes", and we're off. If someone else had spoofed being me, I > would send back "no, sorry, doesn't ring a bell" and nothing > further happens. > > The main difference in the WSN case is that the subscription is > done by a Subscriber using WSN, instead of ad-hoc registry through > some web site. > >> >> On the the hand, DOI seems to be useful for a normal, >> non-security use case such as - Provide an ability to the >> Consumer to accept/reject notifications from a NP (for a >> particular Subscription). The questions in that case will be - >> how does a Consumer know which NP will provide DOI and which one not. > > That's a good point. > > In the WS-world, the /consumer/ would have to advertise an > "approve subscription" request/reply. Let me work through the > original example with the two points above in mind. The NP is > taking the view that it won't send anything out unless it knows > it's really wanted. So it has an array of possible tools, for > example: > > * Trust everything because it's a closed network. > * Trust known subscribers using some form of authentication. > * Convince itself that the subscriber /is/ the consumer. > * Look for a certificate from the Subscriber that proves the > consumer gave its OK (the NP has to have some knowledge of > the consumer through some other channel). Note that this is > different from the Subscriber proving /its/ bona fides to > the NP. In fact, the subscriber might be someone off the > street, as long as it has the right certificate. > * If the consumer supports "approve subscription" (i.e., DOI), > ask the consumer and only approve the subscription with the > consumer's OK. The NP doesn't have to trust the subscriber > at all. > * And if there is no way to know, fault. > > From a WSN spec point of view, we specify the "Approve > Subscription" req/rep, and say that consumers MAY support it and > NPs MAY use it. NPs MAY also use less formal, existing means > (specially formatted email or whatever). > > The question then is how the subscriber would find out about > failure. A truly rogue subscriber doesn't need to be told > anything (indeed, maybe shouldn't be told anything). But a legit > subscriber might well make an unwanted subscription without > knowing it, and deserves to get a fault back. > >> >> By the way, the proposed solution for a currently logged issue >> (WSN2.21: Consumer can not identify the subscription causing >> notifications) might provide a partial solution here, except >> that the WSN2.21 resolution depends upon useNotify option and it >> will require at least one Notification message being sent to the >> Consumer. > > I think this is a separate issue. This is a case of the NP > approving the subscription before any notify messages are sent. > >> >> Thanks, >> Sanajy >> >> -----Original Message----- >> *From:* David Hull [mailto:dmh@tibco.com] >> *Sent:* Monday, Nov 22, 2004 13:53 PM >> *Cc:* wsn@lists.oasis-open.org >> *Subject:* Re: [wsn] Use case for double opt-in and other >> mechanisms for preventing unwanted subscriptions >> >> Thanks for the clarification. I'm still not sure what other >> message exchanges between NP and consumer there might be. We >> only define one, namely notify, and that only if useNotify is >> true. >> >> I think the key point of WSN is its third-party nature. The >> Subscribe MEP between Subscriber and Producer contains a >> pointer (EPR) to the Consumer, and the rest of the message >> flow happens between Producer and Consumer. Intuitively, >> this seems different from a case where the Consumer makes a >> request to the Producer and gets a response. >> >> Does that apply to what you're saying? I'm afraid we're >> going to end up talking in circles around each other if we're >> not careful. >> >> Tom Maguire wrote: >> >>>Forgive my tortured english in the last post clarification below. >>> >>>Problems cannot be solved at the same level of awareness that created >>>them. -Albert Einstein >>>T o m M a g u i r e >>> >>>STSM, On Demand Architecture >>>Poughkeepsie, NY 12601 >>> >>>David Hull <dmh@tibco.com> wrote on 11/22/2004 04:20:07 PM: >>> >>> >>> >>>>Tom Maguire wrote: >>>> >>>> >>>> >>>>In double opt-in the consumer knows about the subscriber, >>>> >>>> >>> should have been two sentences; comma should have been a ? >>> >>>so it should have read >>>"In double opt-in the consumer knows about the subscriber? I believe >>>the consumer would just know about the producer." >>> >>> >>> >>>>No. >>>> >>>> >>>agree >>> >>> >>>>First, DOI is a message exchange between producer and consumer. The >>>>subscriber is not involved at all. >>>>Second, in the typical use case, the consumer may or may not know >>>>the identity of the subscribing entity. DOI applies in either case. >>>>I believe it >>>>would just be the producer? >>>>No. Generally something other than the producer (or consumer) is >>>>making the subscription, and the producer has no way of knowing a >>>>priori whether the subscription is appropriate. >>>>Nevertheless how is this any different from >>>>any other message exchange on the consumer? >>>> >>>>I'm not sure what this means. In the case I have in mind, the >>>>consumer is not a web service at all in the usual sense (yes, that >>>>is still covered by WSN). >>>> >>>> >>> >>>What I meant was; why is the 'notify' message exchange being treate >>>differently >>>then any other message exchange between the producer and the consumer >>>w.r.t. auth? >>> >>> >>> >>>>Tom >>>> >>>>Problems cannot be solved at the same level of awareness that created >>>>them. -Albert Einstein >>>>T o m M a g u i r e >>>> >>>>STSM, On Demand Architecture >>>>Poughkeepsie, NY 12601 >>>> >>>>David Hull <dmh@tibco.com> wrote on 11/22/2004 03:47:29 PM: >>>> >>>> >>>>Tom Maguire wrote: >>>> >>>> >>>> >>>>Is it not sufficient that security assertions or claims about the sender >>>>handle this? Why is the 'notify' MEP (as opposed to all the other MEPs >>>> >>>>the >>>> >>>>Notification consumer exposes) given special treatment in this regard? >>>> >>>>I >>>> >>>>do not understand why composition with WS-Security does not handle the >>>>requirement. >>>> >>>> >>>> >>>>What security assertions would handle the case where a consumer does not >>>>even know the subscriber exists? >>>> >>>> >>>>Tom >>>> >>>>Problems cannot be solved at the same level of awareness that created >>>>them. -Albert Einstein >>>>T o m M a g u i r e >>>> >>>>STSM, On Demand Architecture >>>>Poughkeepsie, NY 12601 >>>> >>>> >>>> >>>> >>>> >>>> >>>> David Hull >>>> >>>> >>>> >>>> <dmh@tibco.com> >>>> >>>> >>>> >>>>To >>>> >>>> 11/22/2004 03:07 wsn@lists.oasis-open.org >>>> >>>> >>>> >>>> PM >>>> >>>>cc >>>> >>>> >>>> >>>>Subject >>>> >>>> [wsn] Use case for double opt-in >>>> >>>> >>>> >>>> and other mechanisms for >>>> >>>>preventing >>>> >>>> unwanted subscriptions >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>The Use Case: >>>> >>>>Because subscriptions may be made by a third party on behalf of the >>>> >>>>actual >>>> >>>>consumer, there must be some means of ensuring that the consumer only >>>>receives notifications it is interested in. There are many possible >>>>relationships among the subscriber, producer and consumer. For example >>>> The subscriber is provably the same entity as the consumer. The >>>> producer should accept any subscription from the consumer on its >>>> >>>>own >>>> >>>> behalf. >>>> The subscriber, producer and consumer are all in the same isolated >>>> environment and implicitly trust each other. Again, there is no >>>> >>>>need >>>> >>>> to restrict subscription. >>>> The consumer has supplied the subscriber with a secure token >>>> >>>>(which >>>> >>>> the NP is able to recognize) authorizing it to subscribe on the >>>> consumer's behalf. The NP should reject subscription requests >>>> without proper authorization. >>>> The consumer does not know the subscriber even exists, but might >>>> >>>>be >>>> >>>> interested in some unsolicited subscriptions. It is thus up to >>>> >>>>the >>>> >>>> producer to determine interest, generally by sending a test >>>> >>>>message >>>> >>>> under the double-opt-in pattern. >>>> Either of the previous cases may apply. The producer should look >>>> >>>>for >>>> >>>> the appropriate secure token, and if it's missing, ask the >>>> >>>>consumer >>>> >>>> via double-opt-in. >>>> A notification producer may impose a quota on subscriptions >>>> >>>>directed >>>> >>>> toward a given consumer (perhaps because the consumer asked it >>>> >>>>to). >>>> >>>> In this case, a given subscription may either succeed or fail >>>> depending on what other subscriptions are open. >>>>Clearly, many more variants are possible. >>>>Discussion: >>>>In cases where the producer must query the consumer before beginning the >>>>subscription, arbitrarily much time may pass between the subscription >>>>request and the definitive answer. This asynchronous reply would best >>>> >>>>be >>>> >>>>handled through a callback mechanism, but we would probably rather not >>>>build this into the core subscribe exchange. In the case of secure >>>> >>>>tokens, >>>> >>>>it might make sense for the subscriber to be able to submit and verify a >>>>token for a particular consumer once (in the context of a secure >>>>connection) instead of passing it with every subscribe request. >>>> >>>>It would be desirable to push all such message exchanges out of the core >>>>Subscribe request/response. This is one driver behind having the >>>>subscriber and producer be able to first negotiate a "destination" >>>> >>>>cookie >>>> >>>>and then use that cookie in the actual subscribe request. Naturally, >>>> >>>>this >>>> >>>>is not the only way to cover these use cases. >>>> >>>> >>>> >>>> >>>>> >>>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]