On Tue, Mar 24, 2015 at 10:50:11PM +0000, Osterweil, Eric wrote:
> https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02
You need to explain a lot of details about how the PAD, SPD, and SAD are
manipulated to obtain secure behavior.
In particular, simply adding PAD entries (with the IPSECA keys)
identified by IP address (so that traditional IPsec implementations just
work) would result in a catastrophic security failure: each zone
answering forward A & IPSECA lookups could give you their keys for
someone else's IP address!
You don't mention the PAD nor the SAD, so I assume that you missed their
significance when reading RFC4301.
You really need to study the IPsec architecture [RFC4301] closely and
carefully. Also, any work like this absolutely needs review from
whatever WG has IPsec as its remit.
What you need to do is state that the client must follow a sequence of
steps like this[*]:
0. Lookup the peer's IP address and IPSECA RRs by forward name
1. insert a PAD entry identified by the peer's FQDN (NOT IP address!)
2. request an IKE_SA between the local and remote peer
3. atomically obtain/lock a 5-tuple (with that peer) not currently in
use by other processes/sockets on the system
4. setup a *narrow* SA pair for that 5-tuple, and insert the SA pair
into the SAD
5. add narrow entries to the SPD for that 5-tuple to PROTECT
6. connect() your socket (even with UDP, of course)
7. use the connected socket
8. tear down the socket, SPD and SAD entries; the PAD entry can stay as
long as the RR's TTL says.
Or something along those lines.
That's just the conceptual part. Then you need to figure out how
applications will cause this dance to happen -- the API. Perhaps you'll
need to add a socket option for requesting the use of IPsec with narrow
SA pairs and a specific peer ID and public keys.
Without a socket option for this (or a pseudo address family that
relieves applications of the need to do DNS lookups) the most likely API
scenario (perhaps for a PoC) would be that the application must use
PF_KEY to talk to the IKE daemon to get it to do a lot of the above
sequence of steps. But then you have to worry about how to tear down
state when the application crashes.
Once you have a proof of concept you need to test that it does not fall
to the attack described above. Setup two forward names pointing to the
same IP address and with different public keys, then race clients and
show that they always get their traffic protected by SAs with the
correct peer ID. In particular, the peer should not have the private
keys for the "attacker"'s name, and so clients trying to speak to the
attacker always fail.
[*] This is a suggestion as a starting point, and to illustrate the
complexities involved. I only just thought that up in a few
minutes; there could be mistakes there too.
Nico
--
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
