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

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

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 11:47 AM
> To: Christian Huitema
> Cc: [email-masked]
> Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF
> agenda)
> 
> 
> 
> 
> Christian Huitema wrote:
> 
> > Bottom line, whatever programming you do in the server, 
> there has to be
> > an escape clause that say "well, can't tell in general 
> whether I want to
> > accept or block this <range of users>, so ask me before you publish
> > anything!"
> 
> You publish "The presentity is offline".
> 
> > This is when you need something like QAUTH -- and since we
> > have QAUTH, we may as well keep it. Indeed, this begs the 
> question of
> > what to do when the user is offline -- the simple solution is to not
> > provide information until the user had a chance to approve 
> or disapprove
> > the subscription.

Christian - there is no debate that a mechanism to ask the subscriber is
needed. What is being debated is how this is done.

> 
> If the presentity is really offline how does QUATH work? 
> (CPIM is required
> by this WGs charter so an immediate NOTIFY MUST be issued.)
> 
> Does the presentities PUA return 180 Asking until the user 
> responds, what
> happens if the request timesout waiting for the user, if it 
> doesn't time out
> how do you stop people DOSing the presence server?

If the user is offline (i.e., not even registered to receive QAUTH), then
the presence server would need to 202 the subscription, and wait for the
presentity to come back online. It would know this by registrations; when
the PUA came online, it would register support for QAUTH, and then the
server initiates a QAUTH transaction for the pending subscriptions.

If the registration for QAUTH is there, but the user is not answering, the
presence server is in a bind. It will need to 202 the subscription, as
always, and then periodicaly retry the QAUTH, cancelling each after a
timeout. Very, very ugly.

I prefer the NOTIFY, followed by push of policy, for a LOT of reasons:

1. The issue for QAUTH is *what entities are allowed to make authorization
decisions for this presentity*. With QAUTH, we associate this data with the
entities that can register QAUTH method handling at a registrar for that
presentity. This is, IMHO, really overloading the meaning of registrations.
Registrations establish location and presence state in the network, they are
not about establishing authorization policies.

2. what happens if multiple entities are allowed to make authorization
decisions? So, each would presumably register QAUTH contact addresses for
that presentity. This results in forking of QAUTH. Well, we know that this
is not going to work. What if one recipient of the QAUTH rejects the
subscription, and the other accepts it? Only the 200 OK is forwarded
upstream, which means that the subscription is accepted so long as any one
of the recipients accepts. Yikes. Not what you want. In general, if there is
a notion of multiple entities that can grant authorization (and I think its
a good idea), the rules for combining the authorization decisions from each
of the entities need to be at the discretion of the proxy. This cannot ever
work with QAUTH. At the core, forking is ideal for session establishment
functions, NOT for policy functions!

3. The timeout issue with QAUTH, as described by James above, makes handling
of the case when the PUA is registered to receive QAUTH, but the user is not
at their desk, very problematic.

4. QAUTH will require authentication of the *response* to QAUTH, which is
something we have weak support for right now in SIP.

So, my proposal, of using notifications to alert authorizers of the
subscription, followed by a push of policy, solves all of these problems.
Lets consider them in turn:

1. With this proposal, there can be separate policies about who gets
notified when subscriptions are requested, and who is allowed to push policy
decisions into the server. Thats because we use different mechanisms for the
two. No overloading at all.

2. Multiple entities making authorization decisions works great. each will
subscribe to get notified when subscriptions for the presentity are
requested. Each can then push policy into the server independently, probably
with http carrying a CPL kind of thing. This means that the presence server
has access to everyones policy decision, and can be programmed to combine
them in any way.

3. what if the PUA is offline? Easy! When the user starts their client,
first thing it does is resubscribe to the "subscription listing for the
presentity". THis will generate a notification, with a list of all the
active, denied, and pending subscriptions. The PUA can then query the user
on all pending ones, and then use HTTP to push a new set of policies for
those users.

What if the PUA is active (meaning, receiving notifications of changes in
presence state), but the user is not at their desk? Easy! The PUA software
always responds 200 OK to every notify, and pops a window to ask for
authorization. This window can sit idle forever. There are no pending SIP
transactions. When the user accepts, the PUA software pushes the policy in a
new HTTP request. 

4. No need for response authentication. Policy is pushed using something
like HTTP + CPL. Client authentication mecahnisms in HTTP are well
understood, and lots of means are at aour disposal.

Note also how this approach unifies things; there is one, and only one way
policy gets into the server. Sometimes the policy is triggered as a result
of a subscription, and sometimes, its not. But, the mechanism is the same.

-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: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 15 Mar 2001 12:53:34 -0500

If we use something like CPL, this would in all likelihood be uploaded
as part of the generic request handling mechanism. (This makes sense, I
believe, since in many cases, the filtering rules are similar. If I
don't want to hear from user X, I probably don't want to have him
subscribe to me, either. The converse isn't true, obviously.)

Thus, one such mechanism could be REGISTER.

It would indeed be nice if we could agree on one mechanism, as otherwise
a crucial piece will be missing and be different for every single
service provider. Just relying on form + HTTP is, in my opinion, a bad
idea, as it doesn't work well with devices with limited screen
resolution. 
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs