Subject: [IPsec] IPSEC & DANE (RFC4025)

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Jul 2012 11:31:00 -0400 (EDT)

The IPSECKEY issue came up a few times today in the dane meeting without
being explained. This is the issue (see https://tools.ietf.org/html/rfc4025 )

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  precedence   | gateway type  |  algorithm  |     gateway     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
       ~                            gateway                            ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               /
       /                          public key                           /
       /                                                               /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

You can specify a gateway. So one could have:

www.google.com. IN IPSECKEY 10 1 2 1.2.3.4 <keyblob>

This would instruct ipsec clients supporting IPSECKEY to initiate IKE with
RSA and said public key to 1.2.3.4 for all traffic to www.google.com. This
allows one to specify a dedicated IPsec machine.

I can put in:

paul.example.com. IN IPSECKEY 10 1 2 1.2.3.4 <anotherkeyblob>

Of course, I don't control 1.2.3.4 (google does), which has IKE using
keyblob and not otherkeyblob. So it will fail to establish a working
IPsec tunnel.

But my kernel SPD/SAD can only have one src:dst policy. In the case of
failure to do IKE, this would be a block to prevent plaintext leaks.

So if i can trick a client into connecting to paul.example.com, I can
ensure that user will not be able to talk to www.google.com.

Clearly, a lot of this will depend on local policy/implementation that
is not specified in any RFC. And depending on soft vs hard fail this
would be a DoS or a downgrade attack.

The core problem is that anyone can make a claim about someone elses'
IP address with respect to the public key. We have no way of knowing
who is telling the truth here. We could if we placed the key in the
reverse, but that's exactly what freeswan/openswan tried to do, and
in reality no one really controls their reverse to add records to it.

The difference with TLS is that the client has a concept of the
terminal name it connected to, and has its own src-dst transport,
whereas for IPsec we only have one src-dst for the entire host.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 14:03:11 -0400

>>>>> "Paul" == Paul Wouters <[email-masked]> writes:
    Paul> But my kernel SPD/SAD can only have one src:dst policy. In the case of
    Paul> failure to do IKE, this would be a block to prevent plaintext leaks.

    Paul> So if i can trick a client into connecting to paul.example.com, I can
    Paul> ensure that user will not be able to talk to www.google.com.

This "attack" and the usage you gave for IPSECKEY is not consistent with RFC4322.
By the time that IPSECKEY RR was approved, RFC4322 was already approved
(don't be confused by the order of the document numbers...).   RFC4322 specifies TXT
RR.  An RFC4322-bis that specified IPSECKEY, and IKEv2 was envisioned,
but never compelted.

    Paul> Clearly, a lot of this will depend on local policy/implementation that
    Paul> is not specified in any RFC. And depending on soft vs hard fail this
    Paul> would be a DoS or a downgrade attack.

RFC4322 specifies it.
Section 3.2 discussed "OE-permissive" (fail-to-clear) and "OE-paranoid"
(fail-to-drop) versions.  Openswan by default put the 0.0.0.0/0 into
OE-permissive policy bucket, so if IKE failed, then the "%hold" should
get replaced with a %pass.

    Paul> The core problem is that anyone can make a claim about someone elses'
    Paul> IP address with respect to the public key. We have no way of knowing

"claim", yes, but not enforce.
OE failed initially because of lack of control over reverse, and later,
due to there being no reverse for systems on the NATwork.

    Paul> The difference with TLS is that the client has a concept of the
    Paul> terminal name it connected to, and has its own src-dst transport,
    Paul> whereas for IPsec we only have one src-dst for the entire host.

Agreed.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Jul 2012 16:58:56 -0400 (EDT)

> This "attack" and the usage you gave for IPSECKEY is not consistent with RFC4322.

Isn't it stating the same with different syntactic sugar?

4.3.2.1.in-addr.arpa. IN TXT X-IPsec-Server(P)=A.B.C.D public-key

So if I control the reverse 4.3.2.1 and trick you into a lookup for OE,
and put google's A.B.C.D with "boguspublic-key" in there, wouldn't I have
the exact same issue? And as per 4322, I could have my records DNSSEC
signed. It doesn't help google.

> get replaced with a %pass.

So what happens in my case? Either google is blocked, or google is
downgraded to plaintext. Or the application could distinguish between
my suggested boguspublic-key versus the real google public-key. But
again, the only authoritave way for who controls A.B.C.D can be found
that reverse tree, which we deem unusable at large.

> due to there being no reverse for systems on the NATwork.

Yes, and what I'm saying is that current methods for tying DANE to IPSEC
fail, because there is no binding to the legitimacy of the proclaimed
gateway.

The simple case where a server is doing OE for itself is not an issue.
That works, but I don't think that would move out of the hobby space.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 19:00:49 -0400

>>>>> "Paul" == Paul Wouters <[email-masked]> writes:
    Paul> So what happens in my case? Either google is blocked, or google is
    Paul> downgraded to plaintext. Or the application could distinguish between
    Paul> my suggested boguspublic-key versus the real google

Google is plaintext, you never had the right to speak for it.

    Paul> Yes, and what I'm saying is that current methods for tying DANE to IPSEC
    Paul> fail, because there is no binding to the legitimacy of the proclaimed
    Paul> gateway.

I assume by "current methods", you mean RFC4322? 
Or is there another proposal that I've missed?