Subject: [dane] DANE and IPsec

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jul 2015 17:13:01 +0300

Hi

I see that our milestones still contain a DANE with IPsec document, although the WG has not yet discussed or adopted such a document.

There is one proposed document (draft-osterweil-dane-ipsec). That one ties DANE to opportunistic encryption. While interesting, I think we need a far more basic document. This is what I would like to propose.

IPsec as defined in RFC 4301 has a static configuration. Specifically, there is a data structure called PAD (peer authorization database). This structure contains a list of peers authorized to communicate with this IPsec entity, and for each such peer the following:
 - protocol and method for authentication
 - authentication data
 - constraints on the types and values of IKE IDs sent.
 - location, such as IP address (or DNS name).

For example, we might have a peer that will use IKE with certificates to authenticate, its certificate will have an alternate name that says “vpngw”, It will send an ID payload that says “VPN Gateway” and it’s located at 192.0.2.5.

What I can see DANE doing is reducing many of those fields in the PAD to a single field: and FQDN.  So a PAD record for a peer when DANE is used will have:
 - protocol and method (IKE with DANE)
 - FQDN: as in vpngw.example.com <http://vpngw.example.com/>

The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP address and a DANE record. The DANE record can be used to identify the certificate or raw public key used in IKE. And the document can specify what the ID payload looks like: in all likelihood the FQDN itself is a good idea. Similar to the way a TLS client gives the TLS server a hint of identity using SNI, IKE has an IDr payload in the IKE_AUTH request which should perform a similar function. 

What do people think?  

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 15:03:43 +0000

On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir wrote:

> The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
> address and a DANE record. The DANE record can be used to identify the
> certificate or raw public key used in IKE.

What prevents IP address hijacking (mallory.example publishes
alice.example's IP address and now mallory's IPSEC keys are used
to encrypt traffic to alice)?

I thought that Paul Wouters is working on a more comprehensive
specification, IIRC in an IPSEC working group where it can get
better informed review.  This is much more of an IPSEC design
problem, than a DANE design problem.

Once the IPSEC parts are in good shape, perhaps the document can
be discussed here for any final DANE-specific issues (details of
just the DANE RRset used for the document).

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Jul 2015 11:09:02 -0400 (EDT)

> to encrypt traffic to alice)?

This is the biggest problem yes. At best, you can detect you got
two different IPsec pubkeys for the same IP (say 8.8.8.8) and
then you have to disconnect both to prevent encrypting to the attacker.

(eg if i put in evil.nohats.ca. IN A 8.8.8.8 along with an IPSECKEY
  and have you trigger opportunistic IPsec to evil.nohats.ca)

Of course, a layer of NAT or one-local-ip-per-remote could address
that but it is extremely ugly. So we (libreswan) are still undecided.

> problem, than a DANE design problem.

Yoav is one of the core IPsec people, so that's good :)

> just the DANE RRset used for the document).

I'm not sure if we need a new record. We could use IPSECKEY with
some restrictions (gateway option must be unused)

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 15:29:48 +0000

> then you have to disconnect both to prevent encrypting to the attacker.

I also thought that Nico had some ideas about extending the socket
API so that one could associate a socket endpoint with a "domain",
not an IP address, and some sort of "connection latching", but I
am just repeating terms I don't fully understand.

Anyway, my takeway was that this a difficult problem, and that the
DNS keying records were not the difficult parts, so I think that
perhaps this work is best done elsewhere.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jul 2015 18:40:45 +0300

> On Jul 2, 2015, at 6:03 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Not sure I follow. Mallory publishes
 - mallory.example.com  IN  A 192.0.2.5
 - mallory.example.com  IN TLSA ....

But there’s also 
 - alice.example.com IN A 192.0.2.5
 - alice.example.com IN TLSA ....

So Mallory can push people looking for his IPsec entity to go to Alice’s IPsec entity. Once there they might accept the public key they’re presented with (if he has copied the contents of the TLSA record) or not. Assuming Mallory cannot publish alice.example.com records, where is the attack?

> problem, than a DANE design problem.

Paul is working on host to host IPsec for opportunistic encryption. The problem I would like to solve is that configuring the PAD is (1) hard, and (2) unwieldy, because any changes to your certificate requires updating the static configuration on all your peers.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 15:48:00 +0000

On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote:

> But there's also 
> So Mallory can push people looking for his IPsec entity to go to Alice's
> IPsec entity.

No, Mallory might be able to hijack the traffic keys to 192.0.2.5
(Alice's IP address), and then MiTM the traffic in question (BGP
attack or equivalent).  If there's no risk of MiTM, just do anon-DH
and you're done, no need for a PKI.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jul 2015 20:04:37 +0300

> On Jul 2, 2015, at 6:48 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

It’s the Internet. MitM is always a risk. But I’m still not getting it. IPsec traffic keys are negotiated with the IKE protocol, which provides both authentication and key exchange with D-H. How could mallory hijack traffic keys?  If Mallory doesn’t have the private key that matches the public key in Alice’s TLSA record ([1]) then IKE will fail.

Yoav

[1] I’m assuming here use of the same TLSA record as in TLS, but it could be another type of record

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 17:08:31 +0000

> >> - mallory.example.com  IN TLSA ....

Mallory publishes her own TLSA record for keys she possesses.

> >> - alice.example.com IN TLSA ....

Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5
supercedes or displaces Alices.

> >> So Mallory can push people looking for his IPsec entity to go to Alice's

No, Mallory can cause people trying to connect to Alice's IP address
to use Mallory's keys.

> It's the Internet. MitM is always a risk. But I?m still not getting it.
> IPsec traffic keys are negotiated with the IKE protocol, which provides
> both authentication and key exchange with D-H. How could Mallory hijack
> traffic keys?

The IKE protocol negotiation takes place with Mallory, standing in
for Alice.

> If Mallory doesn't have the private key that matches the
> public key in Alice's TLSA record ([1]) then IKE will fail.

Alice's key is not used.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jul 2015 21:02:03 +0300

> On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Ah, I see the source of my confusion.  

I never think of a PAD as a table indexed by IP address. The “key” for the PAD is a peer, so in practice it might be indexed by an internal name (such as the “conn” labels in the ipsec.conf file in all *swan implementation) or it might be indexed by the content of the ID payload that we expect that peer to present in IKE.

There is no entry for 192.0.2.5.  I’m suggesting that there should be a static entry in the PAD for “alice.example.com”. DNS is used to resolve this to an IP address and to a public key. Unless mallory can affect “alice.example.com” entries, the victim never gets to see his records, because she never looks for them.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 18:22:26 +0000

On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote:

> I never think of a PAD as a table indexed by IP address. The "key" for
> the PAD is a peer, so in practice it might be indexed by an internal name
> (such as the "conn" labels in the ipsec.conf file in all *swan
> implementation) or it might be indexed by the content of the ID payload
> that we expect that peer to present in IKE.
> 
> There is no entry for 192.0.2.5.

At the end of the day though, IPSEC needs to apply policy to
application traffic presented to the kernel (almost universally)
via the socket API.  The socket API gives the kernel a transport
endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to
use Mallory's keys for that same address or Alice's.

I think you mentioned that your design locates both the IP address
and the keys from DNS, so if the peers in the PAD database turn
rogue, they might subvert other peers, right?

> I'm suggesting that there should be a static entry in the PAD for
> "alice.example.com".  DNS is used to resolve this to an IP address
> and to a public key. Unless mallory can affect "alice.example.com"
> entries, the victim never gets to see his records, because she never
> looks for them.

mallory.example is another domain in the PAD.  Either domain can
return IP addresses that properly belong to someone else.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jul 2015 22:09:46 +0300

> On Jul 2, 2015, at 9:22 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> use Mallory's keys for that same address or Alice’s.

Host to host IPsec is very rare. VPNs are far more common and the packets don’t get there by a socket API.

But regardless, let’s assume that the local address is 198.51.100.2. So the quintuple for the connection would be (UDP, 198.51.100.2:704, 192.0.2.5:53)

The first thing a kernel does is look up with quintuple in the security policy database (SPD). Much like the PAD, the SPD is static. So if this quintuple is matched in the SPD, we get the tunnel endpoints (which may or may not be the same as the addresses on the packets) from the SPD. In this case we get that the remote endpoint is “alice.example.com”. Mallory’s entries never make it into the (static) SPD.

> rogue, they might subvert other peers, right?

I’ve only configured Alice. If she turns rogue, she can send me to Mallory’s gateway and tell me to expect Mallory’s keys. What good it would do her, I don’t know.

> return IP addresses that properly belong to someone else.

Sure, but that only makes a difference to people looking for mallory. The protected domain of mallory’s IPsec host/gateway is pre-configured. Unless we use route-based VPN, and then we’re as secure as the routing protocol.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 19:40:00 +0000

On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote:

> > use Mallory's keys for that same address or Alice?s.
> 
> Host to host IPsec is very rare. VPNs are far more common and the packets
> don't get there by a socket API.

The attack I had in mind is not an attack on VPNs.  It is an attack
on IPSEC in transport mode.  If you want to use DANE as a PKI for
VPN tunnel key management (where both the gateway IP and the key
material are provided via DNSSEC), that should work.

The hard part is the transport-mode use-case.

So we were talking past each other.  You were thinking tunnels,
and I was thinking transport.

DANE for VPN tunnels should be simple enough as you suggest,
and can simplify key management.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jul 2015 23:29:45 +0300

> On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

I agree, and I think that is something DANE can do.

> The hard part is the transport-mode use-case.

If the SPD entries are specific and pre-configured, the same reasoning as for VPNs applies. Things change if you want the SPD and PAD to be dynamic, such as reading them from DNS.

There is RFC 4025 with the IPSECKEY record. So when the application performs a DNS lookup for www.example.com, the OS could also ask for an IPSECKEY record and get both public key and a gateway address. If we set the gateway address to be equal to the server address, this is the transport-mode use-case. Again, this all begins with the DNS name, so mallory cannot do anything. 

There are issues, though. if the application does not perform a DNS lookup (such as if the user entered http://93.184.216.34 instead of www.example.com) then the IPSECKEY entry is not read. RFC 4025 suggests using  reverse DNS, but we know that reverse DNS doesn’t work too well.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 21:28:38 +0000

On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote:

> If the SPD entries are specific and pre-configured, the same reasoning as
> for VPNs applies. Things change if you want the SPD and PAD to be dynamic,
> such as reading them from DNS.

Dynamic.

> There is RFC 4025 with the IPSECKEY record. So when the application performs
> a DNS lookup for www.example.com, the OS could also ask for an IPSECKEY
> record and get both public key and a gateway address. If we set the gateway
> address to be equal to the server address, this is the transport-mode
> use-case. Again, this all begins with the DNS name, so mallory cannot do
> anything.

Mallory can often trigger DNS lookups for her own domain, which
can return IP addresses that collide with Alice's domain.  How
is that handled?

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 3 Jul 2015 01:01:43 +0300

> On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the address through reverse DNS. I don’t know in what percentage of the Internet that would work.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 22:47:44 +0000

On Fri, Jul 03, 2015 at 01:01:43AM +0300, Yoav Nir wrote:

> RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the address
> through reverse DNS. I don?t know in what percentage of the Internet that
> would work.

Exceedingly little, it could make more sense at that point to just
publish the keys under in-addr.arpa.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jul 2015 11:07:23 -0300

The problem is two different keys in two different domains in combination with traffic hijacking.

If I steal your 8.8.8.8 route, and trick you into looking up and doing IKE to my domain google.nohats.ca with A record 8.8.8.8, you start encrypting all google DNS to me. That is, your applications do not know the encryption of 8.8.8.8 is setup using ipseckey records not from google. There is a disconnect between system and application with IPsec that you do not have with TLS or SSH

Normally this is hard, but in coffee shop wifi it would be easy.

Sent from my iPhone

> On Jul 2, 2015, at 15:02, Yoav Nir <[email-masked]> wrote:
> 
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jul 2015 11:12:03 -0300

> 
> Host to host IPsec is very rare.

But that's what we are trying to change :)

> But regardless, let’s assume that the local address is 198.51.100.2. So the quintuple for the connection would be (UDP, 198.51.100.2:704, 192.0.2.5:53)

I don't think you want a tunnel per netflow, and still the application has no way of knowing or verifying the entity of the destination encryption.

>  Unless we use route-based VPN, and then we’re as secure as the routing protocol.

Doing authnull yes, but the point of using DNSSEC is to get a firm proven grip on the remote identity.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jul 2015 11:14:54 -0300

See my previously sent email. There is still a problem. I can explain more once I have a real keyboard

Sent from my iPhone

> On Jul 2, 2015, at 17:29, Yoav Nir <[email-masked]> wrote:
> 
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jul 2015 11:16:21 -0300

The reverse failed. It is only useful in private cloud deployments lacking other types of authentication for publishing pubkeys (ldap, Kerberos , etc)

Sent from my iPhone

> On Jul 2, 2015, at 19:01, Yoav Nir <[email-masked]> wrote:
> 
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 3 Jul 2015 21:32:56 +0300

> On Jul 3, 2015, at 5:07 PM, Paul Wouters <[email-masked]> wrote:
> 

Seems like a limitation of DNS security. DNSSEC can authenticate that “mallory claimed that mallory.example.com is at 8.8.8.8”, but DNSSEC does nothing to tell me whether the claim is true. Ordinarily you gain nothing by pointing your DNS name at a wrong IP address. 

What you are proposing is to use DNS queries to build a reverse directory in the SPD+PAD. You resolve mallory.example.com and get an IP address (8.8.8.8) and a TLSA (or IPSECKEY) record.  You use that to build a database that uses the IP address as key and maps 8.8.8.8 to the pubkey in the IPSECKEY record. So you use the value 8.8.8.8 which nobody other than mallory vouches for, and which nobody guarantees us uniqueness for, and you use it for a key.

This fails even without malice. Suppose both www.example.com and tools.example.com are on the same server. We can get the right identity by using IDr in IKE_AUTH or SNI in TLS. Depending on which of these you resolved last, you will get a mapping in the SPD from 93.184.216.34 to one of the public keys. You will use that to initiate IKE, and you might use the wrong one.

If we really wanted secure opportunistic, we’d need to authenticate claims tying IP addresses to names. Perhaps the resource PKI from BGP security could get us there.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jul 2015 15:33:40 -0400 (EDT)

> Seems like a limitation of DNS security. DNSSEC can authenticate that “mallory claimed that mallory.example.com is at 8.8.8.8”, but DNSSEC does nothing to tell me whether the claim is true. Ordinar…

Yes it is.

> This fails even without malice. Suppose both www.example.com and tools.example.com are on the same server. We can get the right identity by using IDr in IKE_AUTH or SNI in TLS. Depending on which o…

No because you would either use one key for both or publish both keys in
DNSSEC.

> If we really wanted secure opportunistic, we’d need to authenticate claims tying IP addresses to names. Perhaps the resource PKI from BGP security could get us there.

But I doubt that information will be easilly acessable to endusers. It
would be nice.

Paul