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


To: Dan Massey <masseyd@isi.edu>
Cc: dnssec@cafax.se
From: Wesley Griffin <wgriffin@tislabs.com>
Date: Sat, 7 Jul 2001 09:58:49 -0400
Content-Disposition: inline
Delivery-Date: Sun Jul 8 21:41:07 2001
In-Reply-To: <20010706162926.A4020@bb.east.isi.edu>; from masseyd@isi.edu on Fri, Jul 06, 2001 at 04:29:26PM -0400
Sender: owner-dnssec@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: SSH keys in DNS

* Dan Massey <masseyd@isi.edu> [07/06/01 16:29]:
> On Friday, July 06, 2001 at 03:58PM, Wesley Griffin wrote:
> | So I've been working on modifying the OpenSSH client to lookup host keys
> | via DNS and I've run into an issue with the KEY record and
> | protocol/algorithm octects.
> | 
> | I thought that perhaps the way to proceed would be to request 2 protocol
> | values from IANA: an SSHv1 protocol value and SSHv2 protocol value. But
> | I'm wondering if since it is still the SSH protocol, just a different
> | version, whether this is the appropriate method.

> Right now, at worst, you get two RSA keys for ssh.  Try the first RSA
> key and if matches the key presented by the host then you are done.
> Otherwise try the second RSA key.  

One of the actions of the client is to detect when a host key has
changed, and print out an appropriate warning message. As an example,
let's say there is a server that has a v1 RSA key in DNS and the 
administrator has just upgraded the server and created a v2 RSA key and
added it to DNS as well.

The client, which is using a caching nameserver, connects to the server,
and uses the v2 protocol. When the client requests the keys from DNS, it
gets back the cached answer and tries to compare the only RSA key in
DNS.

Obviously the compare fails, but it is not correct for the client to say
the host key has changed. In fact, the host key is not in DNS. But the 
client cannot know this because all it has is an SSH RSA key from DNS.

Albeit this is a somewhat contrived answer, but from an application 
robustness standpoint I think valid, I've already run into this problem
in my testing and it took me a while to figure out why my keys weren't 
comparing right... until I realized I had upgraded the client and not 
put the new v2 RSA keys into DNS.

Certianly there are other, more administrator-mistake, errors, like
having 2 v2 RSA keys in DNS, but not a v1 RSA key. The client again
doesn't know that the correct error is "host key not found" instead of
"host key changed". But those can be attributed to admin errors.

> Also, a server could choose to use the same RSA key for both v1 and v2 
> so then there is only one SSH RSA key in the DNS if this is concern.  

Right, if there is only one RSA key and it matches what the client has
then we're happy.

-- 
Wesley Griffin                                                  NAI Labs
wgriffin at tislabs.com                                     443.259.2388

Home | Date list | Subject list