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

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Mar 2001 17:15:21 -0500

The consensus at the end of this sub-thread, as I understand
it, was to abandon the idea of QAUTH as specified in qauth-00
and look for other mechanisms (Jonathan has proposed subscribing
to subscription attempts as an alternative)to obtain authentication.

So, QAUTH is abandoned and new implementors should not pursue it.

Where/when should work on replacing its functionality take place?

I don't see that it fits under the current SIMPLE charter (feel free
to argue with me). Should we table the concept for possible future
consideration then, or formally boot it to the sip-events arena? (A
generalized solution there would be valuable).

RjS

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 10:18 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: RE: [Simple] SIMPLE BoF agenda
> 
> 
> 
> 
> On Wed, 28 Feb 2001, Jonathan Rosenberg wrote:
> 
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: James Undery [mailto:[email-masked]]
> 
> > > I really think using the current QAUTH proposition is far 
> > > from ideal and if it
> > > can't be improved something else (non SIP based) should be 
> > > considered. The
> > > transaction time-out issue is a real killer, I'd be 
> > > interested in comments on
> > > using Subscribe and Notify for pull mechanism (my only 
> > > concern at the moment is
> > > horrendous recursion).
> > 
> > Well, there is a way to use SUB/NOT that would allow us to 
> converge the
> > push/pull mechanisms.
> > 
> > Consider the set of subscribers to a presentity as a piece 
> of dynamically
> > changing state. Call this state the "subscription list for 
> presentity A". I
> > can easily imagine that it is possible for entities 
> (typically, presentity
> > A) to subscribe to this state. So, when it changes (such as 
> when a new
> > subscriber X asks for a subscription to A), this causes a 
> NOTIFY to be sent
> > to anyone watching "subscription list for presentity A" - 
> probably A. Now,
> > at this time, A can choose to push a new policy list to the 
> server. This new
> > policy list is one which blocks X. Whenever a presence 
> server receives a new
> > policy, it automatically runs that policy against existing 
> subscriptions. 
> > 
> > Note that we even proposed a data format for representing 
> the state of
> > "subscription lists". See
> >
> http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-imp
p-watcherinfo-
> 00.txt.
> 
> So, lets assume that we use a CPL variant to express policy. Assume http
is
> used to push these policies into the server. The flow would look like
this:
> 
> 
> subscriber               presence server                  presentity
> 
> SUB
> ------------------------------>
> 
> 202 OK
> <------------------------------           NOTIFY w/ subscription state
>                               ---------------------------------->
>                                            200 OK
>                               <----------------------------------
>                                    http POST w/ CPL
>                               <----------------------------------
>                                    200 OK
>                               ----------------------------------->
> 
> In this way, policy information is always passed using a single mechanism,
> but it is triggered using a NOTIFY.
>
 
I think this is a better solution as with a properly configured policy
list/script it would address info leakages (for those concerned with
that sort of thing) by defaulting to display offline until the subscriber 
was accepted.

James Undery

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 14 Mar 2001 14:27:32 -0800

Uh, I do not recall any such consensus. We find that QAUTH is actually
quite useful.

> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 2:15 PM
> Subject: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda)
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 14 Mar 2001 17:42:13 -0500

> Sent: Wednesday, March 14, 2001 4:15 PM

Do you think there is a need for a generic event agent to be able to
delegate authorization decisions? If so, then it would belong in sip-events.
I'm not sure I see that to be the case. Presence has the fairly unique
requirement to allow a human to make the authorization decision on demand, a
feature for which delegated authorization is very useful. I am not sure the
concept generalizes very well.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Mar 2001 18:19:57 -0500

If the idea were good for two or more event packages, not
necessarily all, then the problem should be solved there.

RjS

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 4:42 PM
> To: Robert Sparks
> Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF
> agenda)
> 
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 12:21:59 -0500

> Sent: Thursday, March 15, 2001 9:37 AM
> To: 'James Undery'; Robert Sparks
> Cc: 'Christian Huitema'; [email-masked]'
> > I am all for a CPL style language to control generic sip 
> > event subscriptions
> > and also agree this should be done outside the SIMPLE WG.
> > 
> 
> First off, I do like the elegance of a CPL style mechanism plus a
> subscription to the list-of-subscribers as opposed to QAUTH, 
> at least as
> currently specificed. But their are two scenarios that make 
> me a little
> queasy. The first I think is fairly severe, the second is more of an
> inconvenience:
> 
> 1. X subscribes, and my rules allows the subscription. I am 
> notified that X
> has subscribed and realize that I do not want X to see my 
> presence state. I
> publish new rules to prevent X from re-subscribing. But it is 
> too late, X
> already has my presence information. 

Well, that seems reasonable. You did, after all, explicitly allow the user
to subscribe. Even with the old QAUTH mechanism, if authorization data
already existed for a subscriber, the QAUTH wasn't sent. Think about it. If
QAUTH was needed even for subscriptions where authorization data was already
present, the system could never provide presence services for you when you
were offline.

With the notify approach, you at least get told that someone has subscribed
to you, and been accepted. You can, at that point, push new policy and tell
the server to discard the subscription. With QAUTH, you wouldn't even get
the QAUTH, so you'd have no way of knowing that they subscribed!

Also, would the new rules apply
> immediately, or would X keep his subscription until it 
> expires, and merely
> be prohibited from re-subscribing?

Immediately. The subscription would be deleted (meaning no more NOTIFYs are
sent), and the policy database would be updated to reject future
subscriptions (of course, reject may still mean 202 + NOTIFY w/ bogus data)

> 
> 2. Y attempts to subscribe, but is rejected by my rules. If I 
> knew that Y
> wanted to subscribe I would allow it. But since I never get a 
> notification
> that Y wants to subscribe, I have no reason to update my rules.

Same as above. You explicitly TOLD the server to disallow the user. If you
believe that authorization data can never actually be used, what is the
point of having it?

-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: "Christian Huitema" <[email-masked]>
Date: Thu, 15 Mar 2001 09:32:44 -0800

Jonathan,

At the core of the debate is whether the authorization of subscription
is specified in the protocol, or is left to a side channel. I agree that
the side channel model can work: the user receives a notification that
some action is requested; the client pushes state in the server; the
state can be either temporary or permanent; the server uses the new
state for the current subscription and possibly for the subscriptions to
come. When you say that "Policy is pushed using something like HTTP +
CPL," you are really saying that the server decisions are based on
parameters that are exchanged through a client/server protocol that is
either proprietary or specified in another standard. In fact, the net
result will be a set of proprietary configuration interfaces, based on
your preferred combination of HTTP, CPL, XML, HTML Forms and SOAP, with
various degrees of integration between the presence UI and the
management UI. Now, it may well be that this is what the group wants,
that we don't feel confident that we can make this part of the standard
now. Is this true?

-- Christian Huitema

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Mar 2001 13:53:55 -0500

First, please don't take my argument to be a defence of QAUTH. I am merely
questioning whether the policy-rules plus notification of changes to my list
of subscribers meets the requirements.

Should it be possible for me to write policy that says:

1. Accept anyone in my domain
2. Accept anyone in my buddy list
3. Reject [email-masked] (assume foo is a known stalker)
4. Any one else, _ask_me_first.

It seems to me that rule 4 is not possible. I could make a rule that says
"accept anyone else, then tell me you did it" and then push new policy if
someone I didn't think about subscribes. I can prevent them from getting
future presence information, but I cannot take back the fact that the server
already gave them my current information.

Now, maybe we do not have a requirement to handle rule 4. If that is our
consensus, I am okay with it. But I want to make sure we explicitly make
that decision.

> From: Jonathan Rosenberg 
> Sent: Thursday, March 15, 2001 11:22 AM
> To: Ben Campbell; 'James Undery'; Robert Sparks
> Well, that seems reasonable. You did, after all, explicitly 
> allow the user to subscribe. Even with the old QAUTH 
> mechanism, if authorization data already existed for a 
> subscriber, the QAUTH wasn't sent. Think about it. If QAUTH 
> was needed even for subscriptions where authorization data 
> was already present, the system could never provide presence 
> services for you when you were offline.
> 
> With the notify approach, you at least get told that someone 
> has subscribed to you, and been accepted. You can, at that 
> point, push new policy and tell the server to discard the 
> subscription. With QAUTH, you wouldn't even get the QAUTH, so 
> you'd have no way of knowing that they subscribed!
> 
> 
> Immediately. The subscription would be deleted (meaning no 
> more NOTIFYs are sent), and the policy database would be 
> updated to reject future subscriptions (of course, reject may 
> still mean 202 + NOTIFY w/ bogus data)
> 
> > 
> Same as above. You explicitly TOLD the server to disallow the 
> user. If you believe that authorization data can never 
> actually be used, what is the point of having it?
> 
> -Jonathan R.
> 
> ---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 15:09:57 -0500

> Sent: Thursday, March 15, 2001 1:54 PM
> To: Jonathan Rosenberg; 'James Undery'; Robert Sparks

It is absolutely a requirement.

> It seems to me that rule 4 is not possible. 

No, not true at all. The whole idea is that if the presence server has no
explicit accept/reject authorization, it marks the subscription as pending
and waits to be told what to do. In all cases, when there is a change in the
set of subscriptions (either accepted, rejected, or pending), a notification
is sent to subscribers of the "watcher list". So, it is easy to do what you
want. Note that a pending subscription will generate a 202+NOTIFY, but the
content of the NOTIFY is made up and not useful.

What you cannot do is:

1. accept anyone in my domain
2. for anyone, ask me first

since these are inconsistent. This is what I thought you were talking about.

-Jonathan R.

---

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Mar 2001 15:56:28 -0500

> No, not true at all. The whole idea is that if the presence 
> server has no explicit accept/reject authorization, it marks 
> the subscription as pending and waits to be told what to do. 
> In all cases, when there is a change in the set of 
> subscriptions (either accepted, rejected, or pending), a 
> notification is sent to subscribers of the "watcher list". 
> So, it is easy to do what you want. Note that a pending 
> subscription will generate a 202+NOTIFY, but the content of 
> the NOTIFY is made up and not useful.
> 
> What you cannot do is:

Ah, I had not grokked that the list of subscriptions included "pending"
subscription. Therefore the user can push new policy, and the entire list of
subscriptions, including pending ones, gets re-checked against the new
policy.

I would be somewhat concerned about a server keeping state for rejected
subscriptions. That sounds like an opening for a DoS attack.

---

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

> From: Ben Campbell 
> Sent: Thursday, March 15, 2001 3:56 PM
> Ah, I had not grokked that the list of subscriptions included 
> "pending" subscription. Therefore the user can push new 
> policy, and the entire list of subscriptions, including 
> pending ones, gets re-checked against the new policy.
> 
> 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.

The presence document should probably mention this.

-Jonathan R.
---

---

From: "Adam Roach (EUS)" <[email-masked]>
Date: Thu, 15 Mar 2001 18:19:36 -0600

> From: Jonathan Rosenberg [mailto:[email-masked]]
>
> > From: Ben Campbell
> > 

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?

/a