Re: [dane] [IPsec] Bootstrapping IPSec from DNSSSEC/DANE
Paul Wouters <paul@cypherpunks.ca> Mon, 30 September 2013 14:52 UTC
Return-Path: <paul@cypherpunks.ca>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13EB21F9C33; Mon, 30 Sep 2013 07:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level:
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599]
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 DJln6KUnqpqc; Mon, 30 Sep 2013 07:52:19 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7621F9AF0; Mon, 30 Sep 2013 07:52:18 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cpRQp2r58z9Mv; Mon, 30 Sep 2013 10:52:02 -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 V4tdxpOL2kMY; Mon, 30 Sep 2013 10:52:01 -0400 (EDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 30 Sep 2013 10:52:00 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 8EF0E805F2; Mon, 30 Sep 2013 10:51:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 86594805F1; Mon, 30 Sep 2013 10:51:59 -0400 (EDT)
Date: Mon, 30 Sep 2013 10:51:59 -0400
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: david.lloyd@fsmail.net
In-Reply-To: <7039763.53681380486188849.JavaMail.www@wwinf3715>
Message-ID: <alpine.LFD.2.10.1309301034040.23817@bofh.nohats.ca>
References: <7039763.53681380486188849.JavaMail.www@wwinf3715>
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 WG" <ipsec@ietf.org>, dane WG list <dane@ietf.org>
Subject: Re: [dane] [IPsec] Bootstrapping IPSec from DNSSSEC/DANE
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Sep 2013 14:52:25 -0000
On Sun, 29 Sep 2013, david.lloyd@fsmail.net wrote: > Thanks for the various responses. I have also been asked for a little clarification on what I am trying to achieve, so I'll give a quick overview. > > There's not much to it... Basically, we have three independent groups who have certificate-based IPSec (on IPv6), and now they'd like occasionally to connect to each other. The obvious solution is to cross-sign certificates, but we have also recently implemented DNSSEC, so I was wondering if there was a better/another way. Or maybe: I have a shiny new hammer called DNSSEC, and a lot of things are starting to look like nails. > > In terms of getting IPSec based off DNSSEC, the two RFCs 4025 and 4322 actually do pretty much what I want (plus or minus that it'll look very different to the way I am configuring TLS DANE). I am going to see if I can get those to work. We have been working on re-doing IPsec OE (which can use DANE/DNSSEC) using IKEv2. We will be writing up our findings in a new draft and implement this in libreswan. The core functionality is not hard. The problem is in cornercases and trying not to get stuck in too many of them like the BTNS work did. > For the other things that were talked about: > > Mobile devices and NATs - It is true that reverse lookup is inappropriate for these scenarios, but ultimately this is just a rejig of the problem that the incoming ipaddress is not particularly useful in these scenarios. If a server wishes to verify such connecting clients, it'll have to choose something else as an identifier (and thus it falls back into the traditional CA/Kerebros setup) Forget the reverse. You either use the forward lookup with DNSSEC using a locally running DNSSEC resolver or you if you don't find anything, you try an anonymous (MITMable) IPsec directly. > > So I think that the answer is that I can do this with existing technology, with some basic restrictions in that I'll need to be running my own reverse DNS lookup for my deployment - which seems entirely sensible as I want to have control over which ip addresses "exist" in my environment. Yes. the problems are mostly in the local implementation. How to deal with NAT and overlapping IP addresses. How to ensure there is no malicious NAT-T pre-NAT IP attempts at traffic stealing (eg 8.8.8.8) How (or if) to present the difference of "anonymous IPsec" versus "one or two sided authenticated IPsec" to the user. What to do when the roles of initiator/responder change and the connection was only authenticated by the original initiator. I hope to have a rough draft and implementation ready in Vancouver, Paul
- [dane] Bootstrapping IPSec from DNSSSEC/DANE david.lloyd
- Re: [dane] Bootstrapping IPSec from DNSSSEC/DANE Yoav Nir
- Re: [dane] Bootstrapping IPSec from DNSSSEC/DANE James Cloos
- Re: [dane] [IPsec] Bootstrapping IPSec from DNSSS… Paul Wouters
- [dane] Bootstrapping IPSec from DNSSSEC/DANE david.lloyd
- Re: [dane] [IPsec] Bootstrapping IPSec from DNSSS… Paul Wouters
- Re: [dane] Bootstrapping IPSec from DNSSSEC/DANE Alex Maurin