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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
