Subject: [sipcore] Security Issue

From: Samir Srivastava <[email-masked]>
Date: Wed, 8 Dec 2010 00:25:32 -0800

Hi,

  I am getting active after a long pause. Trying to figure out the details.

  I posted earlier on the SIP Implementors regarding the

  1)  security for other URI such as IM, PRES, TEL
  2)  feature control such as presence information sent over the secure
channel is distributed over the unsecure channel.
  3)  Alongwith other issues, which I was pointing earlier on the list.

  Does anybody has answer to 1) and 2) or not or what is the plan?
  Paul, Dale other folks active here and active there too. I was expecting
it might have resolved either way to know the result.

Thx
Samir Srivastava

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Dec 2010 10:51:49 -0500

IIUC you posted earier to sip-implementors, not sipcore.

If your issues are simply implementation concerns, it would be best to 
continue your discussion there.

If you think your issues are deficiencies or errors in the specs, then 
this is probably the right place. If so, please repost here the details 
you are concerned with.

(I seem to recall some message(s) on the subjects you mention, but not 
any details. I get too much mail to monitor and respond more than 
sporadically and opportunistically to sip-implementors.)

	Thanks,
	Paul

On 12/8/2010 3:25 AM, Samir Srivastava wrote:
>    Paul, Dale other folks active here and active there too. I was
> expecting it might have resolved either way to know the result.
> Thx
> Samir Srivastava
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Samir Srivastava <[email-masked]>
Date: Wed, 8 Dec 2010 10:15:09 -0800

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.

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.

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

4) Security with other Secure Protocol. Such as double enryption due to TLS
and IPSEC tunnel.between two SIP addressable end points.

  The answers to above will help me in deciding to bring the next version of
cipher-suite draft to the community,

Thx
Samir

On Wed, Dec 8, 2010 at 7:51 AM, Paul Kyzivat <[email-masked]> wrote:

> If you think your issues are deficiencies or errors in the specs, then this
> is probably the right place. If so, please repost here the details you are
> concerned with.
>
> (I seem to recall some message(s) on the subjects you mention, but not any
> details. I get too much mail to monitor and respond more than sporadically
> and opportunistically to sip-implementors.)
>
>        Thanks,
>        Paul
>
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Dec 2010 14:55:04 -0600

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