Subject: [SIMPLE] Presence Authorization

From: "Oded Cna'an" <[email-masked]>
Date: Wed, 6 Jun 2001 16:18:10 +0200

Hi,

I read Jonathan's proposal on presence authorization and the comments made
by Robert and Theodore and would like to add some comments.

I agree with Jonathan that the QAUTH mechanism is not suitable for presence
authorization in the general case, but I think that the proposed solution
has an intrinsic fault regarding who should handle presence authorization
and watcher lists. As this is a fundamental question in the definition of a
presence server, I'll start from he beginning.

A general presence server (PS), in my view, handles 3 basic tasks:

1. Collection and aggregation of presence information - a PS updates the
presence information by both connecting to different 'sensors' (location
servers, reachability servers, velocity servers etc.) and receiving updates
from presentities as to their status (availability, location etc.).

Presence information is aggregated so that the server holds the latest
presence state of a presentity based on all the UAs currently registered.

2. Manage subscription (not authorization) of entities that wish to receive
presence notifications on specific presentities. These entities must already
be approved to receive notifications.

3. Issuing notifications to watchers whenever the presence information
changes. Normally, a presence server would also support querying of presence
information as defined in RFC 2778.

Presence servers work hand in hand with applications that require presence
info (e.g., IM, UM, call routing, content delivery etc.) in a way that these
applications supply the logic part and the PS takes care of presence
collection and distribution. The main point is that these services are
separated from the PS.

If we take a SIMPLE based IM service as an example, this service requires an
implicit/explicit login/logout actions, manages message routing (and
possibly storing) and is the interface for presence information.

The translation of these operations into a SIMPLE work flow can be done as
follows (although this is not the only way):

      UA                  IM             PS
      |     REGISTER       |              |
      |------------------->|   REGISTER   |
      |                    |------------->|
      |                    |   200 OK     |
      |       200 OK       |<-------------|
      |<-------------------|              |
      |                    |              |
      |    SUBSCRIBE       |              |
      |------------------->|  SUBSCRIBE   |
      |                    |------------->|
      |                    |     200 OK   |
      |      200 OK        |<-------------|
      |<-------------------|              |
      |                    |   NOTIFY     |
      |      NOTIFY        |<-------------|
      |<-------------------|              |
      |                    |              |
      |     MESSAGE        |              |           OTHER UA
      |------------------->|           MESSAGE           |
      |                    |---------------------------->|
      |                    |              |              |
      |                    |            200 OK           |
      |      200 OK        |<----------------------------|
      |<-------------------|              |              |

As shown above, the actions are performed against the service (in this case
IM) that passes them (if appropriate) to the PS.

Subscription authorization, in the general case, is related to a service and
not the PS. As an example, let's say that I am connected to 2 different
services (IM and UM) that use the same PS as their back office (a typical
scenario for mobile operators and enterprises). Approving subscription to
user a@b on the UM service does not mean that I approve subscription to that
user on the IM service.

The above analysis dictates a solution in which the service is responsible
for the subscription authorization and the presence server is informed by
the service, which users can receive presence info on a certain presentity
(subject to PS provisioning).

This approach, that separates between the services and the PS was adopted by
the PAM forum and is at the basis of the PAM API.

Thanks,
------------------------
Oded Cna'an
VP, New Technologies
Odigo Inc.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Jun 2001 00:19:08 -0400

> -----Original Message-----
> From: Oded Cna'an [mailto:[email-masked]]
> Sent: Wednesday, June 06, 2001 10:18 AM
> To: SIMPLE Mail List (E-mail)
> Cc: Avner Ronen (E-mail); Gabriel Matsliach (E-mail)
> Subject: [SIMPLE] Presence Authorization
> 
> 
> Hi,
> 

I think they do handle authorization, but I strongly feel that how the
authorization is done can, and should, be extremely flexible. The proposed
watcherinfo provides one, and only one, means for authorization that is
needed to solve an important common case (which is why we factor it out into
a separate and orthogonal document set).

> collection and distribution. The main point is that these services are

I agree 100%. In fact, you should have a look at the application component
architecture for SIP:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01
.txt

which is all about the separation of applications from application-unaware
components, including media servers, conferencing servers, and presence
servers.

> not the PS. 

Absolutely. However, the PS still needs to do authorization, but of a
different sort. In this model, the PS needs to authorize that the
subscription is coming from a trusted application (in this case, the IM
service). That is generally accomplished in SIP using transport layer
security techniques. The IM service would have a secure connection to the
PS, using SSL/TLS. The authorization policy of the PS would be to accept all
subscriptions that come over this connection. The IM service would handle
the service level authorization, as you describe.

As an example, let's say that I am connected to 2 
> different

While I agree in principle, practically speaking, this is not going to
provide real security. If I want to get at your presence for IM, but you
refuse, I can simply ask for your presence for UM, get accepted, and then
use that information for other purposes.

> the PAM forum and is at the basis of the PAM API.

I hope I have been clear in that I don't think what you are proposing is at
odds in any way with the SIMPLE model. In your case, you would simply not
use the watcherinfo based authorization. Instead, your authorization is
based on transitive trust between and application and the presence server.
Standard ways in SIP exist to establish such a relationship. Of course, how
the application makes its decision on authorization is also an
implementation decision, and there is nothing that would prevent you from
running PAM for this purpose.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Jun 2001 01:18:07 -0400

> From: Oded [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 10:39 AM
> To: 'Jonathan Rosenberg'; 'SIMPLE Mail List (E-mail)'
> Cc: 'Avner Ronen (E-mail)'; 'Gabriel Matsliach (E-mail)'
> Subject: RE: [SIMPLE] Presence Authorization
> 
> 
> The debate over how to upload and retrieve watcherinfo 
> documents assumes
> that these lists should be stored on the presence server 
> while it seems much
> more logical to store these lists on the services (IM/ UM etc.).

No, it doesn't make that assumption. We are just talking about protocols. We
are not specifying whether the notifications for watcherinfo come from a
presence server, or a decoupled application server. Thats an implementation
choice.

> The presence server (PS) should be defined as an application 
> that supplies
> presence services to real applications (presence 
> providers/consumers). The
> logic of how to handle these lists is usually different among 
> services and
> thus cannot reside on the PS itself.

And its perfectly acceptable to build a system that way.

> 
> The presence server need not know anything about the subscription
> authorization process (that can be different from one service 
> to another).
> When user A approves to reveal his presence to user B, the 
> service(!) adds B
> to A's permit list and notifies the PS.

My point was that there is still authorization happening here at the PS,
even in this case. The PS needs to know that the subscription request is
coming from an application that is trusted to do its own authorization.
Without that, some random user can just bypass the application server that
provides this service, and send a SUBSCRIBE directly to the presence server.

> 
> Note also, that some services may not implement a deny list, 
> and some even
> not require subscription authorization. In other words, since 
> the PS cannot
> know in advance which applications will be using it and their internal
> logic, it should leave the logic to the services.

Its a reasonable way to build a system, yes, but not the only way.

> 
> Jonathan, in your comments you imply that in a certain 
> implementation, the
> service can manage authorization and the PS may use an 
> 'accept all' policy.
> The problem is that this implementation will not be 
> compatible with other
> implementations that implement authorization on the PS and not in the
> service.

Why? 

Consider two cases. Case one, is where the application is within the same
administrative domain as the PS. In this case, the administrator of the
domain sets the policy of the PS to "accept SUBSCRIBEs only over the TLS
connection from the application server". Since no one but the AS from that
domain talks to the presence server, it works just fine. Perhaps you are
concerned that one cannot buy a presence server that works this way, because
everyone has assumed that the PS manages authorization. Well, as I have
argued, there are a ton of different authorization mechanisms. WHich ones
are included in which presence servers is an issue for RFPs, not RFCs.
Sounds like a reasonable RFP line item is "the PS should be able to
authorize requests based on the DN provided in TLS credentials". 

Case two, is where the application is in one domain, and the PS is in
another domain. This is a tricky case. The PS in the other domain has a
right to challenge the application, and it has a right to authorize based on
the actual user of the application, or on the domain of the application
itself. I don't think you can dictate what the policy of such a PS has to
be.

> 
> It's important that SIMPLE defines where these lists are 
> managed and who to
> contact to manage them.

I don't think this needs to be specified, at least not in an RFC. 

> 
> To conclude, SIMPLE should define how to upload/retrieve watcherinfo
> documents, but this command should be performed against the 
> service and not
> the presence server. I agree that presence servers may be 
> allowed to manage
> these lists but the protocol should encourage doing it on the 
> service level,
> as a main stream approach.

It is a general design goal of SIP that the less thats specified, the
better. This is particularly the case for how networks are architected. I
believe the success of SIP stems, in part, to its flexibility to solve a lot
of different problems because it doesn't say too much about how to build
networks. Invariably, every single provider I've talked to has their own
ideas about how to build a network, and about what boxes perform which
functions. I believe we should contineu with that direction in SIMPLE, and
keep things like this at the discretion of the implementors and network
designers, not in the protocol.

-Jonathan R.

---