OpenSSH Key Storage

[Carson Gaspar]

--On Friday, February 01, 2002 7:37 PM +0100 Markus Friedl 
<markus at openbsd.org> wrote:

> On Fri, Feb 01, 2002 at 01:18:08PM -0500, Carson Gaspar wrote:
>> Sadly, after reading the RFC, it looks like the server never sends its
>> name  during the key exchange, making the first (and better) option
>> impossible. I  hope I'm wrong and just mis-understood the documents.
>
> why should the server send it's name? if you trust the name
> the server sends, then you can trust the key, too.

I'm not _sure_ I understand. Are you saying that:
(a)
- receive the host key
- if the host key exists in known_hosts, trust it.

is equivilant to:
(b)
- receive the name and host key
- if the name/key pair exists in known_hosts, trust it
?

Hmmm.... it may be. Let's look at what happens now:
(c)
- receive the host key
- if the (name|ip)/key pair exists in known_hosts, trust it

Let's examine the threat model:

Previous known_hosts entry:
- Attacker spoofs host, without stealing key. (a) issues unknown host 
warning. (b) and (c) issue host key changed warnings.
- Attacker spoofs host, after stealing key. None of the methods issue a 
warning.
- Attacker steals key, but does not spoof IP address or DNS entry. (c) 
treats as new key.
No previous known_hosts entry:
- Attacker spoofs host, with or without key - All 3 methods issue unknown 
host warning.

So I think (a) differs from (b) in 2 ways:

- (b) allows ssh to differentiate identity key changes from new identities.
- (b) allows ssh to present the identity in a human-friendly format.

(b) differs from (c) as follows:

- (c) has the IP or DNS external binding validation (which could optionally 
be applied as an extension to (b)), but I assert that it adds dubious extra 
security.
- (c) cannot determine if different IP:PORT pairs, or different names, or 
sets of names and IP:PORT pairs are the same identity without manual 
configuration

Can anyone find a flaw in my analysis? Did I miss any corner cases?

-- 
Carson