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

[David R Oran <[e-mail]>]

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

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

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

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

> 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).
>
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
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: [phone]
Email: [e-mail]

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