[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 understand that DOI will help protect NP from being misused by > Subscribers (for spamming Consumers). The question is are we going to > mandate DOI in BaseN. Definitely not. I'm arguing that we should make sure that it's supportable as such, and possibly define any appropriate message exchanges normatively. > If not, then does it still retain its value? For example, with DOI > being optionally supported by NP and Consumers - What is to be done > by NP when a Consumer does not support the DOI message exchange; the > NP is left with either making some assumptions about the authenticity > of the Subscriber or figuring out alternative ways to find out the same? Right. DOI is one of several tools an NP may use to be sure no one is trying to use it nefariously. If it can't be sure (and it needs to be sure), it should refuse to make the subscription and fault instead. This is a general statement, regardless of whether DOI is available or not. > Similarly a Consumer who chooses to support DOI will never be sure > that all the NPs will invoke the DOI message exchange. True. The best it can do is not give out its endpoint to anyone it doesn't trust. This doesn't seem particular to notification, though. > > So, in that sense, DOI seems to be just one way of protecting a > particular entity (NP in this case) under particular assumptions. I > can imagine another scenario where each Consumer publishes > its approved list of Subscribers and all NPs are expected to check the > list first before creating any Subscription. Another scenario may be > to protect the world from rogue NP, where Subscriber first checks with > Consumer before contacting a NP, if the Consumer is ok to accept > notifications from a particular NP based on the past experience, etc? > Should we name these models and standardize them as well in BaseN? I > don't think so. Again, I don't think that these belong in BaseN (or at least not "base BaseN" :-). DOI is worth considering, though, because it's already widely used in various forms, and I don't believe that moving to WSN would eliminate the already-evident need for such measures. > > Again, I think that before standardizing upon DOI like protocols, we > should first look at whether a security solution can be designed using > existing security technologies such as WSS. We should do both. I don't think that WSS can completely eliminate the need for DOI. There will be some systems where WSS will be known to be usable by all interested parties and DOI would not be needed. But I don't think that such systems are the only place where WSN could be useful. I cited a case with a subscription-hunting bot, but it has been pointed out to me that the bot is not necessary. In the present-day cases where some form of DOI is used, it's because anybody can access the subscription page and make a subscription directed at a given address. The obvious migration path is for such pages to offer a WSN interface as well as the ad-hoc POST-based one. This would drive browsers to include Subscriber functionality. In such cases, it should be the vendors' decision (and not ours) whether the Subscriber should have to use some security mechanism. My guess is at least some would want to stick with their current model: I subscribe completely insecurely, I get back a test message and acknowledge it, and then the notifications start coming in. The next step (an independent step, actually) would be to formalize the DOI exchange. Then if I'm using a hypothetical WSN-aware Mozilla, I can subscribe via the browser, and the mail handler knows how to acknowledge the resulting test message (because the browser told it to look out for one). Standardizing DOI abstractly allows the same pattern to work even if we're not using SOAP/Mime/HTTP/SMTP. Again, requiring the Subscriber to supply a certificate and the Consumer to tell the Producer about it beforehand, all using standard security protocols, will also work. We should allow for both cases. // > > Thanks, > Sanjay > > -----Original Message----- > *From:* David Hull [mailto:dmh@tibco.com] > *Sent:* Tuesday, Nov 23, 2004 13:46 PM > *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: > >> >> 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]