Subject: RE: [Simple] SIMPLE BoF agenda

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Feb 2001 16:50:41 -0500

Henning wrote:
> > The questions to ask are:
> > 
> > 1. do we need a presence server to client authorization 
> protocol at all,
> > 2. if so, what do we want it to do (requirements),
> > 2. should it be based on SIP
> > 
> 
> Given the wide variety of things one might want to express, I suspect
> that a form of program, such as an extended version of CPL, 
> is much more
> appropriate for the cases where the subscription arrives while no user
> agent is available. If a user agent is available, normal SUBSCRIBE
> processing would seem to work.

Well, not really. The semantics of subscribe mean something very specific.
If you accept a subscribe (ie., send 200 OK), that means you are the
presence agent for that subscription. So, we cannot just proxy the subscribe
to the PUA, and if it says 200 OK, then the subscription is authorized. It
may be authorized, but it also creates subscription state in the PUA, and
thats not what we want here.

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Friday, February 23, 2001 5:01 AM
> To: Jonathan Rosenberg
> Cc: Adam B. Roach; [email-masked]
> Subject: Re: [Simple] SIMPLE BoF agenda
> 
> The unhelpful nature of the response to my first posting of 
> known issues made
> the second of ones that I don't know if anyone is aware of 
> terse, if you'd like
> more info on any of them I'd be glad to detail them.

Please.

> > 1. do we need a presence server to client authorization 
> protocol at all,
> 
> I think this has to be yes.

I also think this is probably true. If our minimal goal is to be able to
emulate existing systems, we need this, as they do it.

> 
> >
> > 2. if so, what do we want it to do (requirements),
> 
> My preference would be to have an additional 'simple' 
> mechanism for describing
> accept and ban lists with what to do with unknowns. 

Thats different. There are two different authorization things going on here,
which can be referred to as a push and a pull. In the pull model, the PUA
tells the server, AHEAD OF TIME, about ban lists, accept lists, etc. I think
web will probably be the predominant mechanism for this, and I don't feel
that we need a formal protocol for it.

Pull is different. In this case, a subscription has arrived, and the server
wants to explicitly ask (i.e., pull info from the PUA), if its allowed. This
does require a protocol, and it is what we are talking about with QAUTH.

> I'd also 
> suggest that
> headers were taken on trust (Oh dear) or a single presence 
> server had to be able
> to authenticate all the parties involved, with the user able 
> to specify which
> policy to use.

Not sure I follow this. Can you rephrase?

> 
> This would simplify the implementation greatly by avoiding 
> many of the harder
> authentication problems that could be solved by a more 
> complete mechanism. It
> also prevents people using Subscribe and watching when 202s 
> become a 600
> response to guess when people are online.

No, no. You wouldn't do this. I think 202, plus the 4xx and 5xx, are pretty
much the only response codes that one should ever send. 

So, the call flow would be:

SUB           PA             PUA
 
    SUB
--------------->     QUATH
   202          -------------->
<---------------      200
                <--------------
   NOTIFY
<---------------
    200 OK
---------------->

That is, every subscription generates a 202 right away. THen, if the PUA is
around for a QAUTH, one is sent. If not, none is sent. If the PUA comes on
at a later time, it sends a QAUTH at that point.

If the QAUTH results in a negative response, no notify is ever sent.

This really completely decouples the subscription processing from the
authorization, which is, IMHO, highly desirable.

So, what are some of the requirements for such a QAUTH mechanism:

1. indicate the subscriber
2. indicate the presentity
3. indicate the requested duration of the subscription
4. indicate any parameters of the subscription (like filters and the like)
5. allow for a response that rejects the subscription
6. allow for a response that accepts the subscription
7. allow for a response that indicates a duration for the acceptance
8. allow for a response which indicates that the subscriber should be
rejected for a duration of X (this is needed, else refreshes will always
trigger a new QAUTH)
9. indicate that the PA authenticated the identity of the originator

One of the nastier problems is this: what if we want the PUA to authenticate
the subscriber using a shared secret? It would be a handy feature. In this
case, we couldn't easily use HTTP digest, since the exchange is actually
between the subscriber and the presence agent. We might be able to get
around that by having the PA shuttle the challenge and the credentials back
and forth between the subscriber and PUA (so that a challenge in the QAUTH
response is passed to the subscriber, and the credentials in the
re-subscription are passed to the PUA in the QAUTH). But, the response to
the challenge in the QAUTH is wrong, since the hash covers the method, which
is QAUTH here, not SUBSCRIBE.

S/MIME might work better, since we could include in the QAUTH the original
SUBSCRIBE and the signature over it.

> >
> > 2. should it be based on SIP
> 
> I wouldn't be competent to say, although if it is used I'd look at
> draft-nystrom-http-sasl-00.txt as a potential basis of an 
> extension to SIP to
> help with the inter domain problem. My gut feeling is 
> something else would be

would be....?

Not sure what you mean by interdomain problem. 

As a general thing, adding some SASL support to sip would be a good idea. It
would buy us authentication using a few additional mechanisms; of course, we
still wouldn't be able to do e2e confidentiality or integrity, since in
sasl, these work only over point to point connections. The SIP SASL draft
would probably look identical to draft-nystrom-http-sasl. 

For QAUTH, I suppose sasl would help in that we would have a few options at
our disposal that would allow the presence agent to authenticate itself to
the PUA, and vice a versa (of course, http digest already allows this).

-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: Mon, 26 Feb 2001 10:13:57 +0000

> thats not what we want here.

I think Henning was thinking of something similar to what I was suggesting.
(Comments below)

> that we need a formal protocol for it.

But I do think a common format for describing this would be useful so PUA from
one vendor can use Presence servers from other vendors. Hennings suggestion of a
modified version of CPL could be applied here e.g. I don't want anyone from
domain.com to subscribe to me but if they come from myorganisation.com let them.
Filtering on the event they are subscribing to would be useful as well. I'd
second this as a good idea.

> does require a protocol, and it is what we are talking about with QAUTH.

Yes, however, I was thinking about authentication generally. Apart from issues
of trust and authentication QAUTH suffers from transaction timeouts i.e. a PUA
comes online and is sent a QAUTH the user has to respond before the transaction
times out. (I now this issue was raised before!) This is why I thinking about
push mechanisms, beacause QAUTH gets messy and really requires a second new
method to work. (The server sends a QAUTH and gets a 202 back, when the user
allows or disallows the subscription the new method is used to communicate the
result. This is very ugly.)

> Not sure I follow this. Can you rephrase?

For example with CPL the To and From headers are taken as trusted, if
authentication is required it is assumed to have happened elsewhere, it is
difficult to see with out PKI how arbitrary subscribers can be authenticated.
The simplicication I'd consider follows the current system where a single entity
(ICQ, MSN etc) handles all the authentication. A user of the presenceservice.com
can assume [email-masked] is [email-masked] because they have
both authenticated them selves with one server.

For personal use I'd be happy to take headers on trust when issuing my presence
info, however at work I only want authenticated users to access the info. (But
this is back in push policies).

> SUBSCRIBE and the signature over it.

You still have the problem of how to request the credentials as the subscriber
will have seen the 202.

> > help with the inter domain problem. My gut feeling is

In an ideal world PKI would solve this, the subscriber signing the contact and a
timestamp (or something similar that verifies the user, location to send the
NOTIFYs to and prevents replay). Unfortunately SIP appears to be a bad choice,
certainly with the currently proposed QAUTH mechanism. An almost tongue in cheek
response would be for the server to SUBSCRIBE to the PUA to get Authentication
results in a NOTIFY to solve all but the shared secret (between the PUA and
subscriber) problem.

> Not sure what you mean by interdomain problem.

It is what you are discussing above when the server can't authenticate a
subscriber for a PUA
(or they wished to use a shared secret outside of knowledge of the server).

> the PUA, and vice a versa (of course, http digest already allows this).

Although HTTP digest does rely on shared secret, which is its biggest problem
for me.

James Undery