To:
Ted.Lindgreen@tednet.nl
Cc:
dnssec@cafax.se
From:
Dan Massey <masseyd@isi.edu>
Date:
Wed, 18 Apr 2001 15:59:22 -0400
Content-Disposition:
inline
Delivery-Date:
Thu Apr 19 06:43:57 2001
In-Reply-To:
<200104181420.QAA15334@omval.tednet.nl>; from ted@tednet.nl on Wed, Apr 18, 2001 at 04:20:44PM +0200
Sender:
owner-dnssec@cafax.se
User-Agent:
Mutt/1.2.5i
Subject:
Re: Keys at apex problem
On Wednesday, April 18, 2001 at 04:20PM, Ted Lindgreen wrote: | -The ssh client, like any client, should look at the zoneKEY for | any SIG other than the SIG over the zoneKEY itself. So it looks | at "the SIG from the east.isi.edu key (stored at easti.isi.edu)" | - To Jakob Schlyter question: if a SIG fails, something is broken | or hacked. | But I think that a well designed client would only check the | relevant SIGs: ssh-KEY-SIG against the zoneKEY and the zoneKEY-SIG | against the parent-zoneKEY, etc. and would ignore other SIGs. | So, if a relevant SIG fails, the zone is broken or hacked, if a | non-relevant SIG fails nobody would know. | I've tried to walk through this from the resolvers point of view, The only real result is that now I have a headache... This sort of intersects with how a resolver works discussion and I think the answer is different depending on whether the resolver uses trusted keys (option A) or TSIG (option B). Consider this scenario: The nameserver ns is my forwarding nameserver. It is NOT authoritative for isi.edu or east.isi.edu, but someone had asked it for the east.isi.edu zone key so it has cached the KEY set for east.isi.edu and the SIG from isi.edu. To make it really clear, imagine ns is the on-site nameserver at the IETF and the resolvers are on the laptops of people attending the IETF. Resovler 1 has been configured with the isi.edu zone key and wants the ssh key for east.isi.edu. Resolver 1 asks ns for the KEY of east.isi.edu. ns replies with the cached KEY set for east.isi.edu and the SIG from isi.edu. Resolver 1 can authenticate the key set and can search the key set to find the ssh key. If the isi.edu SIG can authenticate the east.isi.edu ssh key, Resolver 1 has the answer and is done. If the SIG by east.isi.edu should authenticate the east.isi.edu ssh key, then the resolver code has to be more complex. First the resolver must determine if east.isi.edu is at the apex of zone. This can be done by searching the east.isi.edu keyset and looking for a zone key. If it finds the east.isi.edu zone key, then the Resolver knows that the east.isi.edu key should be used to authentiate the east.isi.edu ssh key. The resolver can use the existing keyset and SIG from isi.edu to obtain the east.isi.edu zone key. Next it must bypass the fowarder and go get the SIG by east.isi.edu directly from an east.isi.edu authoritative server. Once it has the SIG it can verify the KEY set using the east.isi.edu KEY and SIG. Finally resover 1 has the ssh key and is done. Resolver 2 has been configured with a TSIG to ns. Resolver 2 also wants the ssh key for east.isi.edu. The nameserver ns doesn't know or care if Resolver 2 wants the ssh key, ipsec key, zone key, whatever. All ns knows is that Resolver 2 wants the KEY set for east.isi.edu. This data is cached and marked authenticated. ns should return this with the ad bit set. Resolver 2 sees the AD bit and checks the TSIG. Resolver 2 sorts through the KEY set and pick out the ssh key. The AD bit was set based on the SIG from isi.edu. The SIG from east.isi.edu was never used and there is no way for resolver 2 to tell ns to use this SIG. It seems like Resolver 2 has to rely only on the SIG by isi.edu. (this is okay accoriding to Scott's reading of the spec, right?) Does anyone know what lwresd does in this scenario? In my opinion, "KEYs other than zone KEYs MUST not be stored at apex of a zone" keeps looking better. Dan