Re: [IPsec] draft-yamaya-ipsecme-mpsa-00
Paul Wouters <pwouters@redhat.com> Mon, 11 March 2013 17:25 UTC
Return-Path: <pwouters@redhat.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982B211E80F7 for <ipsec@ietfa.amsl.com>; Mon, 11 Mar 2013 10:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VQf7BuVZYlY for <ipsec@ietfa.amsl.com>; Mon, 11 Mar 2013 10:25:29 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A62D711E80CC for <ipsec@ietf.org>; Mon, 11 Mar 2013 10:25:28 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZPmRP5vp9z9h6; Mon, 11 Mar 2013 13:25:21 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vFn0lXDsFK1q; Mon, 11 Mar 2013 13:25:13 -0400 (EDT)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 11 Mar 2013 13:25:11 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 09BE080D39; Mon, 11 Mar 2013 13:25:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3E4480D38; Mon, 11 Mar 2013 13:25:05 -0400 (EDT)
Date: Mon, 11 Mar 2013 13:25:05 -0400
From: Paul Wouters <pwouters@redhat.com>
X-X-Sender: paul@bofh.nohats.ca
To: IPsecme WG <ipsec@ietf.org>
Message-ID: <alpine.LFD.2.03.1303111318140.26962@nohats.ca>
User-Agent: Alpine 2.03 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Cc: draft-yamaya-ipsecme-mpsa@tools.ietf.org
Subject: Re: [IPsec] draft-yamaya-ipsecme-mpsa-00
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 17:25:29 -0000
Regarding draft-yamaya-ipsecme-mpsa-00 The draft claims to be about "auto discovery and configuration function". However, I don't actually see any of that in the draft. I have no idea how nodes find out about other nodes they can talk IPsec to. What I do see in the draft is a mechanism for a gateway to relay keying material (nonces!!) for a shared IPsec SA to other nodes after authenticating such nodes. That raises a few questions for me: If we want to accomplish a gateway allowing authenticated parties into a collection of IPsec nodes, why not negotiate separate SA's? There is no real reason to use a single shared IPsec SA session key, and it vastly reduced the security. One conpromised node would reveal the IPsec SA keying material, and with that an attacker could decrypt all the traffic between all the nodes. Plus an attacker could just add a new node to the system (depending on the discovery/permission model that I don't fully understand) Why not distribute some kind of token or PSK between gateway and endpoints, so that two endpoints can then use that to setup the parent SA and do a proper setup of any child SAs with a unique keying material for those nodes? As a bonus, that will keep to a much closer deployment to the existing method. A compromised node might be able to attach itself to the group, but it won't allow the direct compromise of any other node-to-node traffic in the collection. Also this allows each node to reject any proposals for IP address ranges it is unwilling to relay to a particular node. Furthermore, I see no discovery method in the draft that tells a node which other nodes are available via this shared MPSA. How does a node know it can do the MPSA to another node? It seems the draft has no method for asking the gateway about this. Without such a discovery, administrators will still end up having to hardcode node configuration, which is exactly what we are trying to avoid. While the diagrams display there can be gateway-endnode and endnode-endnode traffic using the MPSA, I see no way how the endnode could know this. As a node, I have traffic destined for 192.0.2.1. Should I use an MPSA? I see no correlation between SRC / DST IP addresses and the MPSA. Does this mean any endnode can connect to any other endnode within the group and just make up its own ranges? like 0.0.0.0/0 <-> 0.0.0.0/0 ? That seems like a very weak trust model. Additionally, what if I want my node to be in more then one MPSA group ? Can I have two MPSA's ? How would I know a node is connecting to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association between nodes? Or will they just start sending me encrypted ESP for the MPSA? What if someone replays some MPSA encrypted traffic appearing from one node, will my node suddenly stop talking cleartext to it? That seems a weak authentication model. I find the terminology for "rollover time1" (ROLL1) and "rollover time2" (ROLL2) confusing, as it seems to actually be more representative of an "expiration date" and an "activation date". It seems to also overlap with "lifetime" (LIFE). Doubly so as the expiration for ROLL1 has to be related to the start of ROLL2. So we know when to roll, but we still need to connect to the gateway to get the keying material? So why not just limit everything to an expiration time for when the nodes have to contact the gateway again for the new MPSA keying material? The gateway is supopsed to rekey, but that can be difficult with clients behind NAT. Since the gateway informed the clients about the lifetimes, why not let the clients reconnect? So in short: - Distribute authentication information/permission, not encryption material (IKE SA's and traffic selectors are needed) - Devise a mechanism to obtain a list of active nodes or a method to ask the gateway if a certain node is avaialble via MPSA or not. - Reduce the information sent to the minimum required. - Agree on some kind of scope of IP addresses for the MPSA As it stands, I don't really see myself implementing this. There are too many unanswered security concerns, and it does not have enough discovery features in it for my needs. Paul
- Re: [IPsec] draft-yamaya-ipsecme-mpsa-00 Paul Wouters
- Re: [IPsec] draft-yamaya-ipsecme-mpsa-00 Praveen Sathyanarayan
- Re: [IPsec] draft-yamaya-ipsecme-mpsa-00 yamaya