Subject: RE: [Simple] comments on rpids-01 - <relationship>

From: [email-masked]
Date: Mon, 14 Jul 2003 11:46:20 +0300

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, July 13, 2003 5:21 PM
> To: Jonathan Rosenberg
> Cc: Peterson, Jon; Simpletons (E-mail)
> Subject: Re: [Simple] comments on rpids-01 - <relationship>
> 
> 
> Jonathan Rosenberg wrote:
> 
> 
> > I'm not sure that works for presence, though. That is, I 
> don't think you 
> > could generate a SUBSCRIBE with appropriate caller preferences 
> > parameters to just get the presence of the executive and not their 
> > support staff.
> 
> Also, the authentication issues can get rather messy. It's 
> one thing to 
> find the secretary, it's another to convey "this random 
> person who you 
> have never met isn't a stalker but somebody where your boss has asked 
> you allow subscription (but only for as long as the boss is 
> willing to 
> be watched and no longer)". It's a lot easier if a single 
> trusted entity 
> subscribes to the <relationship> party.

Can't this be done by sharing an authorisation list between the secretary and her boss?

/Hisham

> 
> In my model, the boss (or her composer) subscribes to the 
> secretary, who 
> might limit that subscription to working hours. If the 
> secretary stays 
> late, he might then allow the boss later access. This all 
> works pretty 
> naturally, without the elaborate machinery that you'd need otherwise. 
> (You don't want the boss to be able to override all subscription 
> decisions, for example, so you can't just give her access to the 
> authorization database.)
> 
> 
> > 
> > I'm in agreement with Jon that we don't want to populate 
> Joe's presence 
> > document with tuples that really describe Bob, just because 
> Bob is Joe's 
> > assistant. But, Bob does represent a point of contact for 
> Joe, and I 
> > think that information itself is useful presence.
> 
> I think this is somewhere in-between. We have other entities, such as 
> voicemail systems, that are valid contacts and tuples. What is the 
> principal difference between my voicemail box and the 
> executive version, 
> with a live human being answering it?
> 
> 
> > 
> > So, how about this. We could mandate that when a contact 
> contains the 
> > <relationship> element, the tuple has no other information 
> except for 
> > open/closed. The <relationship> element can have an 
> attribute which says 
> > where to go to get the acutal presence for that user:
> > 
> >  <tuple id="7c8dqui">
> >           <status>
> >             <basic>open</basic>
> >             <contact>sip:[email-masked]</contact>
> >             <ep:relationship
> >          
> pres="pres:[email-masked]">assistant</ep:relationship>
> >           </status>
> >           <note>My secretary</note>
> >         </tuple>
> > 
> > This way, there is never actual presence information for 
> the secretary - 
> > only a reference to obtain it. But, the secretary is listed 
> as a contact 
> > point.
> 
> This seems useful in some circumstances, but I'm afraid it 
> doesn't solve 
> the authorization problem I mentioned above.
> 
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 04:59:03 -0400

> Can't this be done by sharing an authorisation list between the secretary and her boss?

Not generally. I'm not sure how sharing would work in practice (given 
lack of deployment of such mechanisms), but you would either have 
authorization lists with multiple-user access rights (not likely to be 
common, judging how typical 'accounts' work in other systems) or share a 
  key.

Even assuming this could work, this doesn't have the same functionality. 
For example, the secretary may only want to be visible to boss-permitted 
contacts from 9 to 5, but can't easily tell which contacts were 
authorized by the boss (so that the secretary can drop them at 5 and 
re-admit them at 9 the next day).

If we can make these requirements for the authorization work, I'd be 
less concerned and Jonathan's suggestion would work well.

The requirements are basically
(1) allow multiple parties to edit the authorization list
(2) the origin of each entry needs to be clear (who added it to the list)
(3) updates and relationship for the same watcher by different updaters 
need to be clear (example: Secretary has Alice in her "good" list, but 
boss adds Alice as well; Alice shouldn't disappear from that list after 
5 pm; whwat happens if there is a conflict?).

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 04:59:03 -0400

Henning

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 10:25:56 -0500

[Renamed this thread to "rpids-01 security and <relationship>"

> common, judging how typical 'accounts' work in other systems) or share a 

Is it possible to use URI leasing here and not worry about sharing
authorization lists?  Example: Assume that Jane subscribe to Joe's
presence and is duly authorized to do so.  Joe has a secretary, Bob,
whose tuple is in Joe's presence document.  Bob's URI is a leased URI,
temporally scoped and dynamically generated.  Only Jane who is
authorized to know Joe's presence can be privy to this leased URI.
The leased URI can be constructed in such a way as to make it hard
to replicate by accident (UUID?).

> re-admit them at 9 the next day).

Contacts coming to the secretary through the leased URI will be
automatically accepted...?

Is it worth pursuing this line of thought?  Does it makes authorization
lists unneccessary?  Just as I do not have a secretary, I am not a
security expert either :-)

> 5 pm; whwat happens if there is a conflict?).

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 10:25:56 -0500

Thanks,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 15:44:15 -0400

I think you are proposing effectively a 'ticket' (to use Kerberos 
terminology) where the ticket-granting agent (here, the boss Bob) grants 
access to the secretary Sam. I think this mostly works, particularly if 
this is encoded as a password, as in sam:[email-masked].

The two drawbacks I can think of are
- needs special support in secretary user agent; unless this is 
standardized, this isn't going to work in any usable way, while the 
"import" mechanism uses standard components that we already have.

- extending permissions becomes an issue. If the secretary stays late, 
it is not really clear what should happen. The secretary will drop the 
external party since the permission expired, which is not what you want.

The second is probably a smaller problem. The first one may be an 
example of a more general issue that might be usable elsewhere. (I can 
forward a call to a third party who will take the call since I "signed" it.)

Vijay K. Gurbani wrote:

>> Even assuming this could work, this doesn't have the same 
>> functionality. For example, the secretary may only want to be visible 
>> to boss-permitted contacts from 9 to 5, but can't easily tell which 
>> contacts were authorized by the boss (so that the secretary can drop 
>> them at 5 and re-admit them at 9 the next day).
> 
> 
>> (3) updates and relationship for the same watcher by different 
>> updaters need to be clear (example: Secretary has Alice in her "good" 
>> list, but boss adds Alice as well; Alice shouldn't disappear from that 
>> list after 5 pm; whwat happens if there is a conflict?).
> 
> 
> Thanks,
> 
> - vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 15:44:15 -0400

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 17:38:27 -0500

Henning Schulzrinne wrote:
> access to the secretary Sam. 

Yes.

> I think this mostly works, particularly if 

I was afraid of the first drawback, and at least now don't
have any more ideas besides standardizing something.

Just to be sure, by "import" above you mean including the
secretary's presence as a reference in the boss' presence document,
right?  If so, then we still have the authorization problem, no?

 > external party since the permission expired, which is not what you

The second one, as you note is a smaller problem and can boil down
to policy/business decisions.  Even in real-world boss/secretary
relationship, there will be a discrete set of calls deflected
from the boss to the secretary that go unanswered (secretary
gone for the day, on lunch, already on phone, ...)

 > The first one may be an example of a more general issue that might be 
 > usable elsewhere. (I can forward a call to a third party who will 
take > the call since I "signed" it.)

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 17:38:27 -0500

Yes.

Thanks,

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 20:44:46 -0400

Vijay K. Gurbani wrote:

>> terminology) where the ticket-granting agent (here, the boss Bob) 
>> grants access to the secretary Sam. 
> 
> 
> Yes.
> 
>> I think this mostly works, particularly if this is encoded as a 
>> password, as in sam:[email-masked].

I like this approach alot. I had the same thought upon reading 
Henning's note, but Vijay beat me to posting the idea.

> have any more ideas besides standardizing something.

I don't quite follow Henning's concern. I don't see why the 
secretary's user agent per se cares. Presumably all of this is handled 
in the presence server. What it DOES require is that the presence 
server have a way to derive a composed document that properly includes 
this ticket/gruu, and has established authorization policies that are 
appropriate. I suspect that those policies would be adminstratively 
determined, so that the secretary in general would not need to do 
anything for this to work.

BTW, this is a really good example of a complex presence 
transformation that is far beyond anything you can do with a SELECT 
kind of database operation.

> gone for the day, on lunch, already on phone, ...)

As I mention above, I suspect that there would be some basic policy 
that applies here. In fact, the "import" appraoch you have proposed, 
Henning, is identical to using a GRUU whose policy is: "the boss's 
authorization policy gets applied" to subscriptions to the gruu.

The benefit of the gruu approach is that you CAN have other policies 
if someone desires. Doing so seems much easier than in the import case.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 20:44:46 -0400

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 05:13:00 -0400

> right?  If so, then we still have the authorization problem, no?

No, that simply means that the presentity or composer takes a tuple 
summarizing the status of the <relationship> entity and delivers it to 
its subscribers.

> gone for the day, on lunch, already on phone, ...)

I'm primarily concerned about difficult-to-explain failure cases that 
can't be readily fixed, particularly for people that don't understand 
the underlying mechanics. Call-by-reference is always more brittle than 
call by value. With inclusion, if the boss-to-secretary subscription 
fails, the boss can deal with it, with local knowledge. If the 
ticket/reference fails, the boss won't know and will, at best, get some 
vague "your secretary refuses to be subscribed to" explanation.

Given the trade-offs, I see no reason to allow this trade-off be made 
locally rather than forcing one design or another.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 05:13:00 -0400

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 15:48:33 -0400

Jonathan Rosenberg wrote:

> I like this approach alot. I had the same thought upon reading Henning's 
> note, but Vijay beat me to posting the idea.

> I don't quite follow Henning's concern. I don't see why the secretary's 
> user agent per se cares. Presumably all of this is handled in the 
> presence server. What it DOES require is that the presence server have a 

Note that I'm not assuming that the boss and secretary presence server 
have anything to do with each other - they can be in different domains. 
I don't see how a GRUU helps here. The secretary isn't creating it; the 
URI can't be public (as otherwise the third party could just hand it out 
to everyone else.)

In the 'password' model that Vijay implicitly proposed, the boss can 
create a specific URI, such as E_k(customer,expiration,salt), which is 
then handed to the customer who wants to subscribe to the boss (and the 
boss' secretary) as a contact. Without further consultation, the 
secretary can verify that the boss has "signed" the subscription until 
the expiration time. This requires the secretary's presence server to be 
able to decode the password and verify it.

Can you explain the chain of events as you see them in a bit more detail?

> way to derive a composed document that properly includes this 
> ticket/gruu, and has established authorization policies that are 
> BTW, this is a really good example of a complex presence transformation 
> that is far beyond anything you can do with a SELECT kind of database 
> operation.

This is a simple compose operation; the select operation only addresses 
merging and filtering, not composition.

> As I mention above, I suspect that there would be some basic policy that 
> applies here. In fact, the "import" appraoch you have proposed, Henning, 
> is identical to using a GRUU whose policy is: "the boss's authorization 
> policy gets applied" to subscriptions to the gruu.

In the cases of distinct presence servers, I don't see how the boss' 
presence policy can apply.

> 
> The benefit of the gruu approach is that you CAN have other policies if 
> someone desires. Doing so seems much easier than in the import case.
> 
> -Jonathan R.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 15:48:33 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Jul 2003 03:47:54 -0400

inline.

Henning Schulzrinne wrote:

>> server have a 

Right, that is a problem. A variation below might fix that.

> Can you explain the chain of events as you see them in a bit more detail?

OK, here is the idea. We have watcher W, secretary S, boss B, all in 
different domains. Secretary S has granted permission for B to 
subscriber to him. B has given his presence server sufficient 
credentials so that the server can authenticate itself to S's server as B.

W subscribers to B. B's presence server subscribes to S, using B's 
credentials. S's presence server says OK, and returns the presence 
information B can see. B's presence server returns a presence document 
with a tuple for the secretary. It has a URI that resolves to B's 
presence server. W SUBSCRIBES to this URI. It routes to B's presence 
server. Since S's presence is available at B's presence server, B 
returns the presence status. It effectively becomes a state agent.

> presence policy can apply.

In the above scheme, it would work.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Jul 2003 03:47:54 -0400

inline.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Jul 2003 08:33:40 -0400

> returns the presence status. It effectively becomes a state agent.

Paint me confused, but that sounds very similar to my original 
(pre-password) proposal, where B subscribes to S and delivers that 
information to W, except that in your proposal it is delivered as a 
separate document and a separate subscription. I fail to see the major 
difference here, except for the additional complexity. One is inclusion 
by reference, the other by value.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Jul 2003 08:33:40 -0400

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Jul 2003 17:59:48 -0500

> returns the presence status. It effectively becomes a state agent.

My first thought on reading this was, "yikes! this is complex from
an implementation point of view".

Are we loosing sight of the fact that in majority of the cases,
when W subscribes to B, she is only interested in B's presence;
not S's.  If B is not available, B's presence document will list
S as a surrogate and W can then >>choose<< to click on the S's
URI to actively subscribe to S's presence.  But the decision on
whether to subscribe to S's presence is W's alone.  She does
not get it implicitly just because she subscribed to B's presence.

Using the import technique or if B becomes a state agent for S
complicates things tremendously.

Henning Schulzrinne wrote:
 > then handed to the customer who wants to subscribe to the boss (and
 > the boss' secretary) as a contact. Without further consultation, the
 > the expiration time. This requires the secretary's presence server to
 > be able to decode the password and verify it.

We had agreed that instead of populating B's presence document with
S's tuples, it was far better to provide a reference for S in B's
document (see
http://www1.ietf.org/mail-archive/working-groups/simple/current/msg01156.html)

So, using that concept and the idea of a 'ticket' I proposed earlier
we get something like this:

    <ep:relationship pres="pres:sam:[email-masked]">
       Assistant
    </ep:relationship>

The two problems with this approach that Dr. Schulzrinne pointed out
were:

    > - needs special support in secretary user agent; unless this
    >   is standardized, this isn't going to work in any usable way,
    >   while the "import" mechanism uses standard components that
    >   we already have.

and difficult to explain failure cases; again to quote:

    > With inclusion, if the boss-to-secretary subscription
    > fails, the boss can deal with it, with local knowledge. If
    > the ticket/reference fails, the boss won't know and will,
    > at best, get some vague "your secretary refuses to be
    > subscribed to" explanation

But I think that these problems maybe easier to deal with than
the alternative.  I wonder if some sort of two factor authentication
(like SecureID) can work here?  This will prevent replay attacks
as the surrogate's URI is good for a few minutes after the
boss's presence document is generated.  Some timing mechanism
(like this URI is good only from 10AM - 2PM) can be either
added as URI parameters or attributes to the <relationship>
element.

I believe that the <relationship> attribute is important enough
that some manner of convergence around how to implement and
understand its semantics will be advantageous down the line.

Thoughts?

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Jul 2003 17:59:48 -0500

Thoughts?

Thanks,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Jul 2003 21:48:56 -0400

> understand its semantics will be advantageous down the line.

Agreed; it would be nice to support all three models:
- plain 'pres' reference; let S and B work it out behind the scenes; 
does not appear to work well in terms of authorization

- ticket, but we would need to standardize the token to have any hope of 
being usable in practice; requires a shared secret between S and B and 
needs special support in S and B

- inclusion; requires extra effort only by B, but raises philosophical 
concerns

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Jul 2003 21:48:56 -0400