Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda)

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 23:54:44 -0500

-----Original Message-----
>From: Adam Roach (EUS) [mailto:[email-masked]]
>Sent: Thursday, March 15, 2001 7:20 PM
>To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; Robert Sparks
>Cc: 'Christian Huitema'; [email-masked]'
>Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda)
>
>
>> -----Original Message----- 
>> From: Jonathan Rosenberg [mailto:[email-masked]] 
>> 
>> > From: Ben Campbell 
>> > 
>> > I would be somewhat concerned about a server keeping state 
>> > for rejected subscriptions. That sounds like an opening for a 
>> > DoS attack. 
>> > 
>> 
>> Well, pending transaction state is even worse, if you think 
>> about it. I 
>> don't see any way around keeping pending transaction state. I 
>> suppose you 
>> could introduce restrictions like, no more than 50 pending 
>> subscriptions for 
>> one presentity at a time. This should cover the majority of normal use 
>> cases, and allow the server to drop pending subscriptions 
>> associated with 
>> attacks. 
>Couldn't we retain only *one* "pending" or "rejected" transaction 
>per each authenticated user (subscriber) per presentity? (and, of 
>course, *no* state for unauthenticated users). Or is it too much 
>to ask that the subscribing entity have a relationship with the 
>server? 

No, I don't think thats sufficient. THe problem is that an attacker might be
able to obtain a large number of authentic (but anonymous) accounts (think
yahoo mail), and use those to launch attacks. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: James Undery <[email-masked]>
Date: Fri, 16 Mar 2001 09:06:31 +0000

I've changed the subject as this is an important, separate issue.

> yahoo mail), and use those to launch attacks.

This can be solved with a change to the way SUBSCRIBE works, basically the 202
response only returns contacts present in the SUBSCRIBE. That way the presence
server only needs to use the SUBSCRIBE to generate the response and the NOTIFY
and doesn't need to store state about the SUBSCRIBE. (200s are unaffected)

Comments gratefully received

James Undery