On Tue, Jun 19, 2018 at 1:00 PM, Paul Wouters <p...@nohats.ca> wrote:
> On Tue, 19 Jun 2018, Eric Rescorla wrote: > > The ID can say that, but as a practical matter, any enterprise that has >> a reasonable number of internal domains is just going to tell people >> to configure their client to accept any domain name. >> > > Which is the equivalent of an enterprise that requires you to accept the > TLS middleware box and its additional webpki CAs. Except we made it more > restrained to prevent abuse. > I'd prefer to establish the facts of the matter before we debate what ought to happen. My contention here is that as a practical matter, many clients will be required to accept any domain name that the VPN server asserts is internal. As far as I can tell, this is what the document itself says: In most deployment scenario's, the IKE client has an expectation that it is connecting, using a split-network setup, to a specific organisation or enterprise. A recommended policy would be to only accept INTERNAL_DNSSEC_TA directives from that organization's DNS names. However, this might not be possible in all deployment scenarios, such as one where the IKE server is handing out a number of domains that are not within one parent domain. What am I misunderstanding? All that is needed is to be able to authenticate the VPN server itself. >> > > This draft has nothing to do with authentication of the VPN server. That > is all done in IKE, possibly with certificates, but nothing related to > DNS whatsoever. This draft is about using a split-DNS setup where the > VPN client can keep using its own validating DNSSEC capable recursive > server, while allowing a cryptographic acception for mutually agreed > enterprise domains while still supporting DNSSEC for those enterprise > domains to protect against inside attackers. > Yes, I appreciate that point. I was responding to Nico's comment that "Generally the client must already have a trust anchor for the SG to begin with. " And it's not correct that in order to have a VPN gateway, you need to give it a full TA. -Ekr
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
