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

From: "Christian Huitema" <[email-masked]>
Date: Thu, 15 Mar 2001 08:59:08 -0800

> From: James Undery [mailto:[email-masked]]
> 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".

Sure. You take whatever default action you want. But this does not
alleviate the need for asking the presentity, as soon as they come on
line. At this stage, the server can issue a QAUTH, and, if the answer is
OK, start publishing actual information. We can presumably come with
another mechanism, but you have a couple of design considerations:

1) We must have an acknowledged exchange, in which the query describes
the requested subscription and the reply provides a yes/no answer.

2) We must be able to fork the request so as to reach the user at their
current location.

It seems to me that QAUTH solves the two requirements. A simple NOTIFY
does not.

Indeed, if the subscription expires before the presentity ever comes on
line, the server will just forget it. As for DoS attacks, it is clear
that some protection is required. An obvious possibility is to have the
server simply reject un-authenticated subscribes.

---

From: James Undery <[email-masked]>
Date: Thu, 15 Mar 2001 17:10:54 +0000

> It seems to me that QAUTH solves the two requirements. A simple NOTIFY

1) The NOTIFY solution acknowledges the PUA has seen the subscription
request why does a yes / no answer need to be provided, I might just want
them to never hear rather than get rejection when they refresh the
subscription (I hope I explained why in our previous correspondence on the
list about info leakage).

2) The NOTIFY doesn't fork no it goes directly to the place I have
registered as wanting it to go to. (Actually I could make it fork if that
was what I really wanted.)

> line, the server will just forget it

I think you misunderstood me I meant what if the QUATH transaction times out
while the user is deciding if they want to allow the subscription or not.

James Undery