[Sip] Event Lists: Back-End Credentials

[Adam Roach <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip