Re: [sipcore] Security Issue

Dean Willis <dean.willis@softarmor.com> Thu, 09 December 2010 20:53 UTC

Return-Path: <dean.willis@softarmor.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F7B28C131 for <sipcore@core3.amsl.com>; Thu, 9 Dec 2010 12:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Level:
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex2nvNh-+aNn for <sipcore@core3.amsl.com>; Thu, 9 Dec 2010 12:53:38 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B9EDC28C122 for <sipcore@ietf.org>; Thu, 9 Dec 2010 12:53:38 -0800 (PST)
Received: by gyd12 with SMTP id 12so1781703gyd.31 for <sipcore@ietf.org>; Thu, 09 Dec 2010 12:55:08 -0800 (PST)
Received: by 10.91.203.6 with SMTP id f6mr91460agq.30.1291928108425; Thu, 09 Dec 2010 12:55:08 -0800 (PST)
Received: from [192.168.2.102] (cpe-66-25-6-220.tx.res.rr.com [66.25.6.220]) by mx.google.com with ESMTPS id c28sm1683675ana.21.2010.12.09.12.55.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Dec 2010 12:55:06 -0800 (PST)
Message-Id: <D7A44F51-554E-4B70-B0F1-91258A05FB20@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Samir Srivastava <samirs.lists@gmail.com>
In-Reply-To: <AANLkTi=7CAFgeqzk=Dt6n58KDgoEezw4-ZrA0Z4B5-AW@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 9 Dec 2010 14:55:04 -0600
References: <AANLkTinEk6VpQYKoNHPhowv69-7V1KwDgC1o9sbQjssU@mail.gmail.com> <4CFFA995.8000408@cisco.com> <AANLkTi=7CAFgeqzk=Dt6n58KDgoEezw4-ZrA0Z4B5-AW@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Security Issue
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2010 20:53:39 -0000

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