I ask that you please put aside your preconceived ideas and read the cga-tsig document with an open mind before you judge it. The document addresses the problem with the use of TSIG and SIG and introduces a new, combined method which can protect nodes against several types of attack. Karl asked how the node receives the IP address of the DNS as it can be the first point of a MITM attack. I just explained that this is not possible, as earlier explained, the node can retrieve this IP address in a safe manner during a first time retrieval. This has nothing to do with CGA-TSIG as it assumes that the node already learned the IP address of the DNS server in a safe way. This document only explains a new method for secure authentication during different scenarios.
Hosnieh > > you are conflating routing security/authentication with DNS service opaque > capabilities. > there already exist a number of methods for securing the DNS channel, [SIG(0), > TSIG, DNSCurve.] > and we can add your technique to the list. > > protecting the service is very different than protecting the channel. > > /bill > > > On 27September2013Friday, at 12:21, Hosnieh Rafiee wrote: > > > > > > >> 1. Passive surveillence of traffic going to DNS resolvers yielding > > meta-data. > > > > Again not possible, at least not in IPv6 if your resolvers and > > recursive resolvers are using cga-tsig. The signature and the CGA/SSAS > > algorithm prevent it. > > > >> 2. MITM who inserts himself between a particular DNS client and a > > particular DNS resolver, and provids false addresses and certificates > > for use in MITM attacks. > > > > Again this is not possible if you are using cga-tsig. > > > > > >> 3. A larger adversary who installs his own DNS resolver for a given > > geographic area by controlling the traffic at the router level into > > and out of that area to redirect DNS traffic to his DNS resolver, and > > then inserts MITM attacks on any connection out of the area he desires > > by supplying bogus addresses and/or server certificates. > > > > If you are using SeND with SSAS or centralized RPKI you can retrieve > > and verify your router in a local link. RA can include the > > (http://tools.ietf.org/html/rfc6106) DNS server options. This means > > that you receive a signed message from a router that was previously > > authorized via the centralized local RPK1. I am not sure whether or > > not DHCPv6 also includes security approaches that can be used for > > authentication. I believe that there was a draft about secure > > authentication using CGA in DHCPv6 as well. > > You can also us a scenario, like SSL, to verify your router > > certificate where the client has already configured the list of CAs. > > > > > >> The client is trying to retrieve the IP address and public key for an > > arbitrary server from the DNS resolver. This is subject to MITM attack. > > > > I guess that you did not quite understand the reasoning behind CGA and > > that is why you are asking a question about an issue that I have > > already explained. Your client retrieves this IP address from the RA > > message that is generated by the use of SeND with the DNS RA option (. > > Since this RA message is already signed and we assume that this client > > has already verified this router (centralized local RPKI that is > > explained in SSAS or other RPKI > > approaches) the attacker has no way of spoofing this message as it > > cannot spoof the content (due to the signature) and it cannot spoof > > the public key due to the binding between the public key and the > > source IP address > > > > > >> How does this prevent MITM from inserting himself between the client > >> and > > the resolver on the first connection to the resolver? > > > > Your node already knows the IP address of your resolver. > > > >> This is actually a capability of CGA (RFC 3972) or SSAS > >> (http://tools.ietf.org/html/draft-rafiee-6man-ssas ), which also > >> provides for the proof of address ownership. So, the client stores > >> the public key of the resolver in its cache. It will subsequently not > >> accept any messages > > from > >> attackers. > > > >> What if the public key being stored belongs to MITM and not the resolver? > > All client traffic is going to MITM. > > > > As I explained, you retrieve the IP address of your DNS server using a > > safe means after having authorized your router in the local link. Now > > if your MITM node is somewhere in the other network and tries to > > intercept the connection between your node and the resolver, since you > > node already knows the IP address of the resolver, it will reject the > > connection because the CGA/SSAS verification process fails. > > > >> Whom does the client "ask for the public key of the DNS server" from? > >> This > > is the step that is subject to MITM attack. > > > > I guess I have already responded this. > > > > > > Hosnieh > > > > _______________________________________________ > > perpass mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
