On Sat, 21 Sep 2013, Yoav Nir wrote:
I believe this would require a separate document. But I'm not sure that tying
it to an IP address is appropriate. IKE implementations work from behind NAT
devices and sometimes move around (see MOBIKE), so I think it would be more
appropriate to tie the record to any type of ID payload that we have in IKE: IP
address and FQDN at least, maybe also KEYID and RFC822 address.
You might need to profile the IKE IDs used for this.
On Sep 21, 2013, at 2:31 PM, [email protected] wrote:
I am interested in using a variant of DANE to bootstrap my IPSec IKE root
certificate trust. Is anyone aware of any work been done in this area?
From my understanding, it looks as though the is no technical issue with using reverse
DNS lookup for the IPSec target machine with DNSSec (although this may be a little
unreliable on the "real-world" internet), so returning standard DANE entries
for the IPSec certificate. Then I would simply use these as part of the standard IPSec
certificate validation algorithm.
Looking at similar proposed applications of DANE, such as the
draft-ietf-dane-srv, mostly this involves defining an appropriate protocol
query name (for example _ipsec.123.123.123.123.in-addr.arpa).
Is this something that would fit into an existing document either from the IKE
side or the DANE side? Or would it be worth me creating an more extensive
proposal?
We (freeswan) tried to use the reverse and failed. It's even worse now
with IPv6.
If you think of clients running a DNSSEC validating resolver themselves,
than having a module in the DNS server that looks up IPSECKEY records in
the forward, signed by DNSSEC, and then instructs the IKE daemon to
setup a tunnel would require no new standards document. Just ensure you
ignore the "gateway" property as it is not secure without the coupling
to the reverse tree.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
