Re: [sipcore] Security Issue

[Dean Willis <[e-mail]>]

On Dec 8, 2010, at 12:15 PM, Samir Srivastava wrote:

> Hi,
>
>   Paul, you will be getting two copies, as I didn't include sipcore  
> in earlier email.
>
>   This is with reference to ciphersuite draft long time back. When  
> we were discussing the issues with SIPS vs Proxy-Require/ Require  
> etc within SIP group (which I see as concluded group now). I am  
> getting back to active within IETF SIP activities.
>
>   I want to know what we had decided for the below Or these issues  
> are still open
>
> 1) Securing messages with different URI schemes such as im:, pres:,  
> tel: etc.
>

Who cares? Nobody actually seems to be willing to use most of these  
URIs. They're really more like placeholders for the sake of argument  
than they are well-used URI schemes. There have been some arguments  
made for tel:, but it obviously has no security properties.


> 2) I see SIPS as standard now, how did we decide for feature control  
> case, e.,g. Presence information sent over the secure channel and it  
> is distributed over the unsecure channel to the watchers.

There is no such control. Much like the State Department recently  
learned, once their cables had been compromised, the WikiLeaks people  
were technically free to send them out via an unsecured channel.

> 3) Degradation of cipher-suites if group with security advisor agreed
>

No assertion about cipher-suite are made by the URI family used.
>
> 4) Security with other Secure Protocol. Such as double enryption due  
> to TLS and IPSEC tunnel.between two SIP addressable end points.
>

Multiple encryption may happen, but it's transparent to the user  
systems.

Really, all we have is that if SIPS is used as a scheme, the sender  
can have a warm feeling (but not certainty) that downstream proxies  
will use SIPS to relay the message. It's a MUST-level requirement in  
the spec, but nodes can break the rules without getting caught (at  
least in normal cases). This says nothing about the behavior of user- 
agents, including back-to-back user agents that act somewhat like a  
proxy.

--
Dean