During the CCC meeting, I talked a lot with some of the kth-krb people. Of course, we spent some time debating the superiority of kerberos vs ssh. And it seems quite clear that the biggest Problem with ssh, as it is used today, is the lousy host authentication. That is, the "Unknown host key, continue anyway?" question that one answers yes to all too often. More precisely, a common scenario is as follows: I have some home-system where I keep most of the files and stuff I need. I visit some place with net-connectivity and ssh installed (the guest-system). I have not had any previous contact with the guest-system, but I have some level of trust in its security (it may be operated by a friend, conference organizer, whatever). I want to use this system to securely log in to my home system. With Kerberos, I'm told, I would run the kauth program, type my password, and get a (time-limited) ticket that provides _mutual_ authentication between me and my home system. With typical ssh usage, I just connect, store the hostkey the first time, and have no real protection at all against MITM attacks. Which is not really acceptable. One simple and reasonably practical solution is the use of fingerprints: I make a hard-copy of the fingerprint of my home system and keep in my wallet. And I make sure to verify the fingerprint of the received hostkey before I trust it. Note that I really need only one fingerprint; once I have the authentic hostkey of my home system, I can download my known_hosts file from there, or use some kind of certificates. This would work, and I'll implement support for it in lsh some day, but it still seems a little low-tech and cumbersome. It would be convenient to be able to use a short password to authenticate the home system (which one of the things kauth provides). So how to do that? There are several possibilities. One is to simply use kauth to get a ticket, and somehow use it for _mutual_ authentication during ssh keyexchange. If you are already running kerberos, I guess this is what you would want to do. For someone not running kerberos (e.g. me), it seems inconvenient to kerberize the home system just to use ssh from guest-systems, in particular as that would require sysadm work. And I also think kerberos is overkill when you want to authenticate one single message (in this case, a public hostkey). Another option is to provide a mechanism to download a hostkey from a system, authenticating it using a small shared secret (i.e. a password). You probably can't use your ordinary unix password, as I suspect that all such protocols would require the server to know the cleartext password. Or one could integrate that mechanism into the ssh-protocol, as a separate key-exchange algorithm, that you would use when you don't have the remote system's hostkey in the known_hosts file. I have to think more about this, but I'd appreciate some feedback. Are these approaches reasonable, and is any one of them preferable over the others? Do you know of any existing protocols that could be used to solve the problem? /Niels
