On Tue, 19 Jun 2018, Eric Rescorla wrote:
I'm asking if a common scenario will be that users of enterprise
VPNs who implement this feature will end up in a situation where the
VPN can impose TAs for any domain.
I explained before that I think "for any domain" can be strictly limited
on the client side, either by preconfiguration or by confirmation on the
VPN client side.
In IKEv1, the XAUTH attribute relaying the domain name typically only
appears once. When checking the Cisco documentation, I see:
domain name
Example:
Router (config-isakmp-group)# domain cisco.com
Specifies the Domain Name Service (DNS) domain to which a group belongs.
This does not suggest that there can be more than one. So my educated
guess here is that implementations in IKEv1 typically did not support
setting more the one domain name (we only support sending and receiving
one). Note that the _use_ of the domain name attribute in IKEv1 is a bit
unclear. Is it to be used only for resolv.conf style search lists, or was it
to constrain the domain(s) that should be looked up with the supplied
nameserver IPs?
Again speaking for our implementation, if we detect a local DNS server
running, we use the domain name and the obtained nameserver IPs to
reconfigure the DNS server to add a forward for only this domain name
via these nameserver IPs. If we did not find a local DNS server running
we will add the domain to the search option in /etc/resolv.conf and
prepend the nameserver IPs to /etc/resolv.conf. (and on termination of
VPN, we restore the old resolv.conf)
So I think most Enterprise configurations will only use one domain,
but most likely still expect the client to give them all DNS traffic
so they can just take over or make up any domains they want. With
more validating (stub) resolvers on devices, this will become more
problematic over time, and I suspect these networks will have to
consolidate things under their own internal domain. Because even if
the VPN will allow multiple domains via this draft, wifi and LAN
connections don't support this.
As a followup question, I claim that that's not presently true with
existing VPNs. In some cases, the VPN requires you to install
a new trust anchor in order to accept its cert, but that's not an
inherently necessary practice.
Note that the VPN server authentication is not under discussion here
at all. I'm not sure why you keep bringing this up.
You almost certainly will need to install some local webpki trust anchor
to make use of your internal TLS servers reachable via the IPsec VPN.
For example, to reach any of our internal redhat servers over HTTPS, I
need to install a redhat internal CA into my system/browser. I believe
this is extremely common (although I do hope it is less common to give
these internal CA's the CN="Certificate Authority")
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
