Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS

Jonathan Rosenberg <jdrosen@cisco.com> Thu, 29 March 2007 13:40 UTC

Return-path: <mmusic-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWurv-0007TO-Ow; Thu, 29 Mar 2007 09:40:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuru-0007TJ-Oj for mmusic@ietf.org; Thu, 29 Mar 2007 09:40:46 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWurt-0005wU-FJ for mmusic@ietf.org; Thu, 29 Mar 2007 09:40:46 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2007 09:40:45 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2TDejsv023811; Thu, 29 Mar 2007 09:40:45 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2TDeRH5015860; Thu, 29 Mar 2007 13:40:45 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:40:30 -0400
Received: from [192.168.1.104] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 09:40:29 -0400
Message-ID: <460BC1CB.1090401@cisco.com>
Date: Thu, 29 Mar 2007 09:40:27 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: EKR <ekr@networkresonance.com>
Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS
References: <20070327130229.AB26F1CC22@delta.rtfm.com>
In-Reply-To: <20070327130229.AB26F1CC22@delta.rtfm.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Mar 2007 13:40:29.0761 (UTC) FILETIME=[D0D9A310:01C77207]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2126; t=1175175645; x=1176039645; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:=20Re=3A=20[MMUSIC]=20ICE-tcp=3A=20TLS=20then=20STUN=20or=20STUN =20then=20TLS |Sender:=20 |To:=20EKR=20<ekr@networkresonance.com>; bh=CjavlZ9GBCWboERO910qP8rrfSSCikCLkTguUawBPSA=; b=zf8sCF0/jeqaNrX7QK2YD4oawNnbj5ois0UsvC6NZASBIKHRxU+88GMfDwULjvPe0zhgkkMn b/a6SY0g9JCfPDjZZMvTlZSVLZ7EBN3XomK+tEvb8Maj0gA3bw2Ei8sC;
Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: IETF MMUSIC WG <mmusic@ietf.org>
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org

inline.

EKR wrote:

> Jonathan Rosenberg <jdrosen@cisco.com> wrote:
> 
>>STUN then TLS
>>-------------
>>
>>+ avoids doing TLS handshakes except on connections that are selected by ICE
>>+ consistent with how we are doing DTLS where the STUN is clearly not
>>protected by SRTP and would happen prior to the DTLS handshaking
>>- Likely to be really hard to implement since most TLS stacks probably
>>won't let you interleave data like this
> 
> 
> Let's examine this question a bit. There are two things you have to do
> to make this work:
> 
>  1. Insert a shim layer in between the TLS stack and the network to
>     bypass the STUN. Most stacks I'm familiar with allow this. I 
>     know OpenSSL does, as does PureTLS.
>  2. Demux TLS and STUN. This is relatively easy (see the description
>     in draft-mcgrew-tls-srtp).
> 
> So, I'm not sure this is that hard to do.

Well, one idea on the demux is if we are using the contrans framing, the 
TLS runs ONTOP of the framing so the demux is trivial.

One thing I wasnt sure of is whether the stacks allow these shimes to 
exist only prior to the handshake completing or through the entire 
duration of the tls connection?


> 
> 
>>- will lose the TLS protection on STUN itself, introducing possible
>>framing attacks whereby a MITM modifies the STUN lengths to disrupt
>>frame sync
> 
> 
> Not sure I understand this issue. It's of course trivial to DoS a 
> TLS over TCP connection by disrupting its frame sync...

A concern was raised on the behave list that an attacker could modify 
the length attribute of stun messages, and disrupt framing on the tcp 
connection and consequently trash the connection. I guess your point is 
that this is possible with regular TCP/TLS too....

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic