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

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

On Oct 28, 2004, at 6:52 PM, <[e-mail]> wrote:

>
>
>> -----Original Message-----
>> From: ext David R Oran [mailto:[e-mail]]
>> Sent: 28.October.2004 18:17
>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [Sip] Event Lists: Back-End Credentials
>>
>>
>>
>> On Oct 28, 2004, at 10:35 AM, [e-mail] wrote:
>>
>>> I didn't know that communication with IESG is one way only. Can the
>>> IESG member who is blocking this explain why this cannot be outside
>>> the scope of this document?
>>>
>>> Anyway, so how about an XCAP usage document that is carried
>> signed and
>>> encrypted to the server using HTTP. That xcap usage document can
>>> include realm, username and password for realms that the user knows
>>> will be needed by the RLS.
>>>
>> That's precisely the problem. Now the RLS can impersonate the
>> user and
>> do anything the user could.
>
> I thought the problem was how to transport the secret to the RLS. 
> Irrespective of how that is done (using XCAP or carrying it in the 
> SUBSCRIBE request itself), you will face the same problem you describe 
> above. So am I right in assuming that you're advocating Adam's latest 
> suggestion on RLS doing backend subscription using its own address?
>
I'm not sure what I'm "advocating", since I said in my original post 
that I don't feel strongly about the subject. Since I'm not in the 
middle of the fray amongst the folks who think we need RLS urgently, I 
can comfortably sit back and "advocate" not progressing RLS until we 
have at least a resticted subset of the delegation problem solved.

If the only alternatives on the table are whether to progress RLS with 
a security scheme that opens the user up to impersonation by a server 
he has very limited trust in, and progressing an solution that uses 
deprate credentials and hence either has limited utility or high user 
complexity (users have to directly subscribe or be limited to 
information available to the whole world), I guess I would vote for the 
latter.

>>
>>> Note that this is useful not just for backend
>> subscriptions, but also
>>> for any list usage we can think for that will result in backend
>>> requests being sent on behalf of a client.
>>>
>>> A server needing a secret key to use on behave of a user
>> can look in
>>> the XCAP document of that user.
>>>
>> Can I be your RLS server? Please? Pretty please?
>
> Ok, but if you behave :) You would expect a trust relationship between 
> the client and the RLS.
>
Yes, but a very limited one, not one that permits identity theft.

> /Hisham
>
>>
>> Dave.
>>
>>
>>> Regards,
>>> Hisham
>>>
>>>> -----Original Message-----
>>>> From: ext Adam Roach [mailto:[e-mail]]
>>>> Sent: 28.October.2004 17:16
>>>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
>>>> Cc: [e-mail]
>>>> Subject: Re: [Sip] Event Lists: Back-End Credentials
>>>>
>>>>
>>>> [e-mail] wrote:
>>>>
>>>>> Why isn't it enough to say that the way an watcher passes
>>>> the key to
>>>>> the RLS is outside the scope of this document?
>>>>
>>>>
>>>> Because that's exactly what the document says right now,
>> and the IESG
>>>> won't let it pass as a result.
>>>>
>>>>
>>>> /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]
>>
>>
>>
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