[OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP clients

[Adrian Georgescu]

First of all, there is no correlation on protocols level between the  
SIP Subscribe from a foreign domain and the HTTP GET requests the  
watcher performs for fetching an icon stored in an XCAP server in a  
foreign domain. So technically you cannot enforce  a policy about who  
is allowed to HTTP GET your icon.

According to OMA everything is pipe between operators that have  
agreements between them. So by proxying all HTTP requests to an  
outbound proxy of operator A the HTTP request will arrive with some  
extra asserted headers to operator B who will then trust them and  
honor the HTTP request based on them. This is non-sense on the Internet.

Protecting an icon is also complete non-sense as once somebody fetched  
it no matter by what means or credentials it can post it on Facebook  
and the rest of the universe got it. Is a picture in the end,  
something you display in a small area of a remote device, something  
you published in the first place to be reachable and not some credit  
card secret details. If you think you need high security for an icon  
do not publish it in the first place.

The only reasonable thing you can do with the icon is to anonymize the  
URL so that people cannot simply guess it. The ones who obtain the URL  
from the Notify with presence Event can fetch it because they know  
where it is. This is what we are now building in OpenXCAP.

--
Adrian





On Nov 19, 2009, at 12:58 PM, Iñaki Baz Castillo wrote:

> El Jueves, 19 de Noviembre de 2009, Thiago Rondon escribió:
>> Iñaki,
>>
>> In this scenario that you said, alice could fetch bob's icon store in
>> the XCAP server by authentication as alice, how the security roles  
>> works?
>>
>> For example, if you can just give access to alice to see bob's icon  
>> if
>> alice in the 'whitelist' of presence-rules.xml ?
>
> That's a very good question for which there is no specifications  
> (AFAIK).
> However the server could have local policies (i.e: alice can get  
> bob's icon,
> after authentication, since alice's domain matches bob's domain).
>
> Inspecting the pres-rules of bob would be the more ellegant  
> solution: if bob
> allows alice to see his status, then it makes sense that alice could  
> fetch
> bob's icon (same as in XMPP, MSN networks).
>
> However it requires that the XCAP server inspect bob's pres-rules,  
> but it
> could be feasible.
>
>
>
>>
>> Thanks!
>> -Thiago Rondon
>>
>> Iñaki Baz Castillo escreveu:
>>> Hi, authorization in IETF's pure XCAP is not defined. This is: a  
>>> XCAP
>>> request doesn't identify the originator but just the requested  
>>> user's
>>> document.
>>>
>>> A too much simplistic workaround is requiring authentication for  
>>> all the
>>> requests and just allow the request if the credentials username  
>>> matches
>>> the request XUI.
>>>
>>> However this is not valid for some cool XCAP applications as  
>>> fetching
>>> users' icon (alice couldn't fetch bob's icon stored in the XCAP  
>>> server as
>>> alice cannot authenticate as bob).
>>>
>>> As I sad above, IETF didn't manage it. Instead there are some  
>>> solutions
>>> born in OMA, 3GPP and so...
>>>
>>> The solution is adding an identity header in the client request
>>> identifying the desired identity (SIP or TEL URI), so the server  
>>> would
>>> ask authentication based on  the identity rather than on the XUI.  
>>> This
>>> would allow the server to authorize alice (after authentication) to
>>> access bob's icon.
>>>
>>> This header can be:
>>>
>>>  X-XCAP-Preferred-Identity
>>>    and/or
>>>  X-3GPP-Preferred-Identity
>>>
>>> In OMA architecture, where there is an aggregation proxy in front  
>>> of the
>>> XCAP servers, the proxy authenticates the client and asserts its  
>>> identity
>>> by adding "X-XCAP/3GPP-Asserted-Identity" (some mechanism as in  
>>> pure SIP
>>> protocol).
>>>
>>> I've already implemented it in my Ruby XCAP client library  
>>> (version 1.2):
>>>  http://dev.sipdoc.net/projects/ruby-xcapclient/news
>>>
>>> I suggest to include it in other XCAP clients (AG's Python  
>>> xcapclient,
>>> sipsimpleclient, Blink...).
>>>
>>> Regards.
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>
>
> -- 
> Iñaki Baz Castillo <ibc at aliax.net>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel