Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
Paul Wouters <paul@nohats.ca> Tue, 31 December 2013 00:44 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011F61AE332 for <ipsec@ietfa.amsl.com>; Mon, 30 Dec 2013 16:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.162
X-Spam-Level:
X-Spam-Status: No, score=0.162 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9Khj4sUEGkG for <ipsec@ietfa.amsl.com>; Mon, 30 Dec 2013 16:44:50 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDC81AE228 for <ipsec@ietf.org>; Mon, 30 Dec 2013 16:44:48 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 9138280055; Mon, 30 Dec 2013 19:44:41 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1388450681; bh=Yk/0fzW7BuuS3f3I40ruAVRyc7rd3ni7srBPjoiDVvE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=h9Y91CF5ilM0rEJYE4OLG/q0hh1LhnIhdIh808FhJJTiQxvY/QHCV50kbErhHKuEP 0zsVf849EtCJhCLtU8q4BIVIacfzUyI+OM4jaMOGh3InXcj/z9jgh70mAZqZx/On9b E5Oy7QrJty6qlfOh4ZeuFc518LBje4kqunxsdvXw=
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8160B80048; Mon, 30 Dec 2013 19:44:41 -0500 (EST)
Date: Mon, 30 Dec 2013 19:44:41 -0500
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <C687BD9EA2204F1087D18646766A3C7B@buildpc>
Message-ID: <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 31 Dec 2013 00:44:53 -0000
On Tue, 24 Dec 2013, Valery Smyslov wrote: > I've just posted a draft, defining NULL Authentication method in IKEv2. > This method may be used for anonymous access or in situations, > when peers don't have any trust relationship, but still want > to get protection at least against passive attacks. This is what we (libreswan) have started implementing as well, although we called it AUTH_NONE instead of AUTH_NULL. We use private range number 201 for this exchange type. We also followed the PSK exchange method. But we are still looking at some issues and therefor have not yet written out our implementation as draft yet. For those interested, libreswan developers are meeting up in San Francisco in the second and third week of January to work on OE (both anonymous and authenticated). Ping me if you would like to attend. Valery's draft is a start, but we need to address a lot more than just defining a new IKEv2 AUTH method: 1) Use of IDs I don't think we should allow any IDs, as there could be conflicts with other non-anonymous connections. Or possibly a way to detect which non-anonymous IDs are accepted at the remote. I was leaning towards mandating the ID to be "anonymous" to make it extremely clear that this is an anonymous connection. 2) Endpoints Your draft does not state anything about the traffic selectors. I think it is important to specify it for only a single host-to-host connection only. Deployments who want to protect a whole subnet can use similar tricks to load balancers and capture port (4)500 and use the NAT-T capability of IPsec. Allowing subnet-to-subnet is just too dangerous because there are no verifiable claims yet about who owns what IP range. 3) Mode I would like to only support tunnel mode and not transport mode, due to the interaction with NATs - particularly multiple endpoints behind the same NAT router. We would hope this happens a lot if everyone enables OE (anonymous and non-anonymous). Obviously using AH also makes no sense so we should note that this is only valid for ESP. 4) Mandatory PFS It should be mandatory to do PFS with an appropriate DH group. 5) Priority The priority of the SPDs of any anonymous IPsec connection should be lower than the priority of any non-anonymous SPD. This ensures that an anonymous IPsec connection can never steal traffic from an authenticated IPsec connection. non-anonymous with anonymous IPsec Now this only covers anonymous IPsec. While better than plaintext, we do hope servers with stable hostnames will use IPSECKEY records to provide their public key, and that the clients will mostly use this new auth-none, while the server responds with its FQDN ID so the client can verify the connection is not MITMed. In fact, I think it is better for roaming devices to remain as anonymous as possible by not providing the server with an identity (and why I also do not like your proposal of allowing and ignoring the identity). I have not yet solved the issue of two servers and "return traffic". Say host A on public IP initiates anonymously to host B on public IP. Let's say both are mail servers. Host A has authenticated host B. Host A can now send traffic to host B encrypted. Host B can respond to that traffic. While the tunnel is up, host B needs to connect to host A for unrelated traffic. It has an IPsec connection up, but it has not authenticated this connection. It should not initiate traffic to host A. BTNS tried to solve this problem with changing the kernel and doing channel binding, but I don't think that solution has support anywhere. I can think of some methods on Linux to "hack" detection and support, but I'm not happy about it yet. Evil ranges Another unresolved problem of using tunnel mode is if a client uses somebody elses IP range. eg my laptop behind NAT using 8.8.8.8 should not be able to steal the remote's google DNS traffic. Again, I can see linux hacks to implement this but I'm still not happy with this. One way out is to use CP and assign IP addresses but since our clients and servers will have thousands of these of connections there will be clashes. Using IPv6 is possible but I'm not convinced the v6-in-v4 IPsec has seen enough deployment and might not be implemented widely. Other kinds of semi-anonymous connections We are trying to limit the number of different kinds of OE connections possible to make it as easy as possible to represent things back to the user. So we have left things like "ssh style leap of faith" out of this. Paul
- [IPsec] Fw: New Version Notification for draft-sm… Valery Smyslov
- Re: [IPsec] Fw: New Version Notification for draf… Yaron Sheffer
- Re: [IPsec] Fw: New Version Notification for draf… Valery Smyslov
- Re: [IPsec] Fw: New Version Notification for draf… Yaron Sheffer
- Re: [IPsec] Fw: New Version Notification for draf… Paul Wouters
- Re: [IPsec] Fw: New Version Notification for draf… Yaron Sheffer
- Re: [IPsec] Fw: New Version Notification for draf… Valery Smyslov
- Re: [IPsec] Fw: New Version Notification for draf… Paul Wouters
- Re: [IPsec] Fw: New Version Notification for draf… Yaron Sheffer
- Re: [IPsec] Fw: New Version Notification for draf… Paul Wouters
- Re: [IPsec] Fw: New Version Notification for draf… Yoav Nir
- Re: [IPsec] Fw: New Version Notification for draf… Valery Smyslov
- Re: [IPsec] Fw: New Version Notification for draf… Paul Wouters
- Re: [IPsec] Fw: New Version Notification for draf… Valery Smyslov
- Re: [IPsec] Fw: New Version Notification for draf… Paul Wouters