[ A few paragraphs (marked IETF) seem very relevant for the ietf-ssh wg, hence the crossposting. ] Balazs Scheidler <[EMAIL PROTECTED]> 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 Möller
