Re: [secdir] [MMUSIC] Review of draft-saito-mmusic-sdp-ike-06

Eric Rescorla <ekr@networkresonance.com> Mon, 28 December 2009 21:23 UTC

Return-Path: <ekr@networkresonance.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4989B3A680A; Mon, 28 Dec 2009 13:23:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.105
X-Spam-Level:
X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 jZgkM7FOTLYZ; Mon, 28 Dec 2009 13:23:45 -0800 (PST)
Received: from kilo.networkresonance.com (unknown [216.187.66.243]) by core3.amsl.com (Postfix) with ESMTP id C91163A67BE; Mon, 28 Dec 2009 13:23:44 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E81706C9A9A; Sat, 26 Dec 2009 12:38:45 -0800 (PST)
Date: Sat, 26 Dec 2009 12:38:45 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Makoto Saito <ma.saito@nttv6.jp>
In-Reply-To: <4B2F9611.8020308@nttv6.jp>
References: <20091130004123.DBE146C3D38@kilo.networkresonance.com> <4B2F9611.8020308@nttv6.jp>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20091226203845.E81706C9A9A@kilo.networkresonance.com>
Cc: mmusic@ietf.org, draft-saito-mmusic-sdp-ike@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] [MMUSIC] Review of draft-saito-mmusic-sdp-ike-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2009 21:23:46 -0000

At Tue, 22 Dec 2009 00:36:49 +0900,
Makoto Saito wrote:
> > My skepticism is that setting up a VPN for applications like this
> > seems like overkill. VPNs have a bunch of ancillary security
> > implications that aren't really necessary for these applications.
> > It's important to remember that IPsec provides not only a network
> > connectivity function but also a firewalling function.  (RFC 4301 S 2.1),
> > and I worry that we're confusing these two to some extent. Consider
> > the last case, the gaming system. In this case, we don't want to
> > open a generic VPN connection, we want to open a connection directly
> > to the gaming up. Why is IPsec a good mechanism here? The
> > other examples seem to raise the same issue.
> 
> Actually, joining the same local network makes DLNA perform very
> effectively.
> 
>   We are particularly focusing on LAN-based applications
> so that it is not necessarily an overkilling to set up VPN for those
> applications. For example, DLNA is used to share private contents
> inside the LAN but it doesn't have sufficient security mechanisms
> for the use over the Internet. So we think VPN is a simple solution
> for that purpose. Anyway, we already have the implementation for
> this application and start to deploy them.

So, this likely is bad design by DLNA--the distinction between LAN and
WAN just isn't strong enough security-wise to support this. ISTM
better to fix this issue than to perpetuate it.


> > I should also mention that in terms of implementation complexity,
> > ICE seems like a real problem. The issue here is file descriptor
> > and channel management. The obvious way to implement an ICE stack
> > (and the way that mine works) is that the stack opens socket(s)
> > locally and then presents an abstraction to the application which
> > it can then use to read and write on. However, in this case, we
> > have three separate pieces of code (and probably execution contexts)
> > which all need to send/receive data on the same socket:
> > 
> > - The ICE stack
> > - The IKE stack
> > - The IPsec stack
> > 
> > And the demultiplexing between these is data dependent. Doesn't this
> > mean that we'll need a central dispatcher process whose job it is
> > to hand off the packets to each other module? I'm having trouble
> > visualizing this being something people are willing to implement.
> 
> The demultiplexing process is simply a combination of existing
> demultiplexing processes of ICE and IKE-NAT-T. That is,
>     if bits 0..31 == 0, dispatch to IKE module
>     else if bits 32..63 == magic-cookie, and parsing packet yields
>        STUN fingerprint, dispatch to ICE module
>     else dispatch to IPsec module
> 
> Anyway, it is true that the combination of ICE and IKE/IPsec is
> complicated because ICE by its nature complicated. We don't think
> ICE should be a MUST in this specification. In fact the environment
> where we are deploying this we actually don't need ICE, but we
> foresee a need for ICE despite its complexity in different
> environment where this specification may be deployed.

I think you're missing my point, which is that intermixing 
IPsec packets with STUN/ICE/IKE packets requires a fairly
inconvenient system architecture.



> > 3. Security Model
> > As I understand it, the way that this system is intended
> > to work is that the home system has an ACL indexed by remote
> > AOR. If a SIP call comes through allegedly from a permitted AOR
> > (via RFC 4474) it allows the VPN connection to be established.
> > That seems to place a very large amount of trust in the SIP
> > proxy. In essence you're giving the SIP proxy the keys to your
> > firewall. I can't really see any circumstances in which I would
> > be willing to do that.
> > 
> > By contrast, classic IPsec/SSH/SSL VPNs rely on credentials
> > that are immediately on the the remote side. That seems far
> > more secure. 
> 
> SIP proxy is not necessarily given a strong authority to
> establish a VPN into a home network.
> This draft does not eliminate other authorization or
> authentication that a user or an implementation might
> want to perform before bringing up the VPN.  For example,
> password authentication can be used in addition to what
> is described in the draft.  This is described in Section 8.

Wait, so I now need two separate authentication mechanisms
plus I have to worry about coordinating my firewall and IPsec
with the SIP authentication? This seems problematic.


> > I am also concerned about the fairly loose coupling between the
> > authentication at the IKE layer and the firewall hole punching.
> > As I understand it, the SIP/ICE system doesn't do any authentication
> > at all: it just punches a hole and then propagates the packets to
> > the IKE/IPsec system without looking at them at all. I don't
> > see any immediate way to exploit this, but it's not clear to me
> > that it's safe either.
> 
> I'm afraid that there is a misunderstanding here, and likely
> there is a text in the draft that is misleading.
> In our use cases, a home router is a SIP UA and it doesn't
> open a hole to the home network until IPsec tunnel is established.
> The holes which SIP/ICE try to open are on external routers such
> as a large scale NAT on ISP network. In either case, the home network
> never sees a packet until both SIP and IKE negotiations have completed
> successfully.

I'm not talking about the home network. I'm talking about the
interaction between the NAT/firewall on the home router
and the rest of the networking system on the same router.


> > 4. Multiplexing
> > Why are you using the same channel for IKE and IPsec tunnelling?
> > IKE supports multiple media channels. This seems like an architectural
> > issue, which is why I have it in general comments.
> 
> RFC3947 and 3948 specify the method of IPsec NAT traversal and
> it uses the same channel for IKE and IPsec. We don't try to do
> anything special here.

Hmm... I'm surprised to hear that, but I guess if/when this goes up
for IETF LC the IPsec experts can weigh in if there is a problem.

-Ekr