Subject: RE: [Simple] SIMPLE BoF agenda

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Feb 2001 02:30:05 -0500

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 5:14 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Simple] SIMPLE BoF agenda
> 
> > 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.
> 
> 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.

I agree that we may want a policy language for presence. The motivations for
this are similar to CPL, but not as strong. We are not talking about end
users creating presence services; we are talking about end users defining
access controls (I appreciate that the difference is small). This could be
done through a web page, requiring no standards. As the definition of access
controls become more complex, a standardized middleware, perhaps even as a
CPL extension, is probably a good idea.

That still remains a different issue than what we are talking about here,
which is the presence server explicitly asking if a particular user can
subscribe at the time of subscription.

> > 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.
> 
> 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.)

So, are you saying some kind of pull mechanism, sip or not, isn't needed?
Or, are you saying that the pull mecahnism shouldn't be sip?

> 
> >
> > > 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?
> 
> 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.

We are not designing a monolothic system. We are designing a distributed
one. We cannot take this for granted.

> 
> 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).

There are two things here. FIrst, is defining access controls based on
authentication levels, and the second, is how authentication is done. The
first can be addressed through a policy language (and indeed, Jiri Kuthan
had proposed CPL extensions for exactly this). In the second, the PGP stuff
allows for the request to be signed on behalf of a third party, so that the
originating presence domain could sign the subscription, validating that it
believes the subscriber is who they say they are.

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

That is not clear. I am going to send a separate note on this issue.

> > 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.
> 
> You still have the problem of how to request the credentials 
> as the subscriber
> will have seen the 202.

Well, in the case of S/MIME, the presence server would have responded with a
401 first, and then only sent a 202 after an authenticated request was sent.

-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: Tue, 27 Feb 2001 12:22:20 +0000

> CPL extension, is probably a good idea.

Definitely.

> Or, are you saying that the pull mecahnism shouldn't be sip?

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)

> one. We cannot take this for granted.

I was trying to propose a simple trust model (trivial) authentication could be
designed for as the fully distributed strongly authenticated model is a
frightening prospect to design and implement. (And may be overkill for some
peoples needs.) I do realise the full proposal is a far harder prospect.

> had proposed CPL extensions for exactly this).

Which IIRC involved the scripts authenticating calls something that scared me at
the time.

> In the second, the PGP stuff

I don't understand "originating presence domain" in terms of it signing a
subscription, do you mean a outbound proxy for the subscribers PUA.

> 401 first, and then only sent a 202 after an authenticated request was sent.

Which again suggests the need for a CPL style policy language.