[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list