Subject: [Sip] Event Lists: Back-End Credentials

From: Adam Roach <[email-masked]>
Date: Tue, 26 Oct 2004 01:06:20 -0500

After a discussion with Dean about some of the issues surrounding the 
back-end credential issue that I raised earlier on the list, I struck 
upon a solution that might get us past this logjam.

The lynch pin to this solution is that the RLS does not ever pretend to 
be the user. Instead, it always subscribes as its own identity. It can 
present credentials as necessary to authenticate itself, but only as 
itself, not as its subscribers.

A consequence of this is that, lacking any other mechanism, the 
resources in a resource list for which the RLS is not authoritative will 
contain only the information that their notifier is willing to reveal to 
the RLS -- which is generally the same information they would render to 
unauthenticated users. In some cases, this might result in no useful 
information being transferred.

Of course, the resource would still be present in the RLMI document; 
this gives the subscriber the *option* to directly subscribe to any 
resources for which the RLS is not authoritative. To facilitate the 
client's ability to perform such subscriptions, the RLMI documents would 
be enhanced with a flag which indicates whether the RLS is authoritative 
for the resource.

Finally, we would mention in the document that future work may define a 
mechanism by which the subscriber can pass the RLS an authorization 
token; the RLS could include this token in requests to show that it has 
been authorized by the user to send SUBSCRIBE messages for arbitrary 
resources on the user's behalf (mostly likely for a limited time period).

Of the solutions we've seen so far, I think this one is the cleanest 
from a security perspective. Further, it will almost certainly allow us 
to progress the draft now, and separate the delegation problem so that 
it can be solved in a way that works well with the other identity and 
authentication work currently underway (and might even be reusable in 
other applications, such as dial-out conference bridges).

Thoughts?

/a

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: David R Oran <[email-masked]>
Date: Wed, 27 Oct 2004 08:48:07 -0400

On Oct 26, 2004, at 2:06 AM, Adam Roach wrote:

> The lynch pin to this solution is that the RLS does not ever pretend 
> to be the user. Instead, it always subscribes as its own identity. It 
> can present credentials as necessary to authenticate itself, but only 
> as itself, not as its subscribers.
>
This factors the security issues, but introduces an inconvenience in 
that any authorization policies have to know about the RLS in addition 
to the user on behalf of whom the RLS is doing the list management. 
Whether this constitutes a major or minor inconvenience is worth 
pondering.

> resources in a resource list for which the RLS is not authoritative 
> will contain only the information that their notifier is willing to 
> reveal to the RLS -- which is generally the same information they 
> would render to unauthenticated users. In some cases, this might 
> result in no useful information being transferred.
>
This strikes me as closer to "major" than "minor" if an important use 
case is buddy lists - which I suppose it is. If the RLS is in fact some 
kind of "shared resource" and doesn't have an identity controllable by 
the user it is acting on behalf of there would be little motivation for 
anyone to trust it and hence policy devolves to the anonymous 
subscription case in most instances. That would seem to do substantial 
damage to the utility for buddy lists.

> client's ability to perform such subscriptions, the RLMI documents 
> would be enhanced with a flag which indicates whether the RLS is 
> authoritative for the resource.
>
Sure, but that's just saying that the RLS optimizations are of less 
value, and the subscriber's job of sorting through the policy versus 
overhead tradeoffs is made harder.

> Finally, we would mention in the document that future work may define 
> a mechanism by which the subscriber can pass the RLS an authorization 
> token; the RLS could include this token in requests to show that it 
> has been authorized by the user to send SUBSCRIBE messages for 
> arbitrary resources on the user's behalf (mostly likely for a limited 
> time period).
>
That's a form of delegation which seems like it would work well for 
this purpose.

> from a security perspective. Further, it will almost certainly allow 
> us to progress the draft now, and separate the delegation problem so 
> that it can be solved in a way that works well with the other identity 
> and authentication work currently underway (and might even be reusable 
> in other applications, such as dial-out conference bridges).
>
True, but are the tradeoffs with other aspects of utility and 
complexity right? I'm not sure but on the small amount of thought I've 
given this it strikes me as questionable.

> Thoughts?
One option is to delay RLS until we have delegation (at least in the 
limited context of RLS) solved, since as you point out above 
subscribers may have to fall back to separate subscriptions to all the 
resources anyway.

I'll observe that once a spec gets through to RFC, the enthusiasm to 
enhance it to do its full job wanes, and the complexities of multiple 
variants in the the wild reduces the practical utility of the "correct" 
solution.

I don't feel strongly about this one way or the other.

Dave.

> /a
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]