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


To: Wesley Griffin <wgriffin@tislabs.com>
Cc: Dan Massey <masseyd@isi.edu>, <dnssec@cafax.se>
From: Roy Arends <Roy.Arends@nominum.com>
Date: Sat, 7 Jul 2001 17:12:01 +0200 (CEST)
Delivery-Date: Sun Jul 8 21:41:08 2001
In-Reply-To: <20010707095846.C25300@tislabs.com>
Sender: owner-dnssec@cafax.se
Subject: Re: SSH keys in DNS

On Sat, 7 Jul 2001, Wesley Griffin wrote:

> * 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.

Sorry to burst this again, but this is a standard rollover issue. Whenever
you roll a keyset over, take the TTL in account. i.e. wait for a certain
amount of time before obsoleting the old key. If one is concerned with
emergency key rollovers, always advertise a key with TTL=0.

Note that name-convention for the owner name does not solve caching
problems. I would still have to query for _sshv2.example.com. KEY while
there still can be the old _sshv2.example.com. KEY cached.

Ofcourse, one can define that a keyID should be in the owner name, that
would solve it.

Regards,

Roy Arends
Nominum


Home | Date list | Subject list