From owner-ietf-ssh@clinet.fi  Tue Sep 28 19:11:40 1999
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by torni.ssh.fi (8.9.3/8.9.3/SSH-1.14) with ESMTP id TAA04853;
	Tue, 28 Sep 1999 19:11:37 +0300 (EET DST)
Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7])
	by ssh.fi (8.9.3/8.9.3/SSH-1.16) with ESMTP id TAA04067;
	Tue, 28 Sep 1999 19:11:37 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id TAA03261
	for ietf-ssh-outgoing; Tue, 28 Sep 1999 19:11:13 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from samantha.lysator.liu.se (root@samantha.lysator.liu.se [130.236.254.202])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id TAA03240
	for <ietf-ssh@clinet.fi>; Tue, 28 Sep 1999 19:11:10 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id SAA22116;
	Tue, 28 Sep 1999 18:07:29 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id SAA25037;
	Tue, 28 Sep 1999 18:07:50 +0200 (MET DST)
To: Balazs Scheidler <bazsi@balabit.hu>
Cc: PSST mailing list <psst@net.lut.ac.uk>
Cc: ietf-ssh@clinet.fi
Subject: Re: authorization database
References: <19990928104602.A12358@balabit.hu>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 28 Sep 1999 18:07:50 +0200
In-Reply-To: Balazs Scheidler's message of "Tue, 28 Sep 1999 10:46:02 +0200"
Message-ID: <nn905r10kp.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2626
Lines: 59

[ A few paragraphs (marked IETF) seem very relevant for the ietf-ssh
  wg, hence the crossposting. ]

Balazs Scheidler <bazsi@balabit.hu> writes:

> I'm trying to work on the publickey authorization database in lshd. I'd like
> to ask for comments how to implement it.

It seems not entirely obvious how to get this right. Before commenting
on publickey usereuthentication, let me say something about
host authentication, which I feel is more urgent. More about user auth
in my next mail.

When connecting, the client should look for a file
.lsh/known_hosts/FQDN, where FQDN is the target host name provided by
the user, preferably completed to a fully qualified domain name (I
think it is possible to get adns to look up a host name using search
directives in resolv.conf, and return both the ip-unmber and the
FQDN).

If the file is found, it should contain a sequence of spki-style
public keys. The set of acceptable hostkey algorithms is derived from
this list, and for now that means dsa keys only.

If no such file is found, the client should consult some configuration
file to decide whether or not to connect at all, and to get any
trusted certificates that might be useful to authenticate the host.

There are several problems with supporting other hostkey algorithms.
One is that it doesn't quite fit in the model above (although I think
it might be possible to catenate spki objects with openpgp objects or
x509 certificates in a single file).

[ IETF ]

A more serious problem is with the protocol itself. An algorithm name
used for negotiating hostkey algorithm must uniquely determine (i)
encoding and padding of keys and data, as well as (ii) the actual
algorithm used, and (iii) key usage policies. Those requirements are
in the transport spec. This means that the defined algorithm names
"openpgp", "spki" and "x509v3" can't really be used; we have to use
something like "spki-dsa", "spki-rsa", "spki-rsa-signature-only", etc.
On a more practical level, consider a server that has two spki
hostkeys, one using rsa and the other using dsa, and a client that
only supports one of those algorithms. If both are called "spki",
there's no information in the algorithm negotiation that lets the
server choose the right key.

This is less of a problem for userauthentication; if the server doesn't
like a particular key, it will send a USERAUTH_FAILURE message, and
the client can try again with a different key. So in this case, (i) is
the important feature of an algorithm name, and (ii) and (iii) doesn't
matter very much.

Is there any way this can be improved or clarified in the spec?

[ IETF ]

/Niels Mller
