The SSH mutual authentication problem which you describe is only one
of many problems that I see with the SSH authentication methods.
You are someone who knows what security is. Therefore, you know
better than to simply click 'ok' and accept the host key when the
dialog pops up. The problem is that most users do not know anything
about host keys. All they know is that they want to connect to the
host. They don't care about security nor want to be bothered with it.
Therefore, they will click 'ok' on anything as long as it connects
them to the host. From the perspective of the security manager for a
large population this is unacceptable.
>From my perspective there are several things that we want for a secure
connection:
(1) mutual authentication of the client and host on every connection
without the user being involved in the decision.
(2) the client's password should never be transmitted to the host
(3) client secrets should never be stored on disk even if encrypted
if the quality of the pass phrase cannot be verified by the
system adminstrator
(4) client credentials must be revokable by the system adminstrator
and recycling of credentials must not be allowed.
These things must be done for the following reasons:
(1) the end user has no basis upon which to determine whether or not
a given host is the one they want to connect to. No matter what
system we use for secure login's we will not be able to prevent
host's from becoming root compromised.
When a system is root compromised it is possible for the attacker
to steal the host's credentials for use is faking out a client.
In the case of Kerberos it is possible to issue new host
credentials every day without affecting the ability of clients
to mutually authenticate. With SSH public key pairs, changing
the host public key appears to the user as if an attack is taking
place.
(2) Because a host may be compromised it is not acceptable for an
end user's credentials in the form of a password to be sent to
to a host. Sending a password over an encrypted mutually
authenticated channel only prevents the password from being
read in transit. It does not prevent a compromised host from
sending the credentials somewhere else.
This is solved by Kerberos using the password to communicate
via encrypted messages with a trusted third party. SSH public
key authorization also avoids sending of the password. But
when public key is not being used the password is sent across
the encrypted wire.
Secure Remote Password would allow a password to be used with
out transmitting any revealing data to the host.
(3) In general user's choose really poor pass phrases and store their
private keys on insecure systems (windows, mac, ...). When
private key files are stolen from insecure systems or even when
stolen from secure systems after they are root compromised,
access to the keys in most cases becomes a simple dictionary
attack. The quality of the encryption algorithm used to
protect them becomes irrelevant.
Kerberos does not store pass phrases on disk and its credentials
expire in a short period of time in those situations where they
must be. Kerberos allows the quality of the pass phrase to be
enforced centrally by the system administrator.
(4) When a host is compromised and the private keys and lists of hosts
on which they have been used have been stolen, it is imperative
that a system adminstrator have the ability to force expiration
of the pass phrase and prevent its re-use. Otherwise, it is
impossible for the system adminstrator to know that an account
will be secure after it is reactivated.
Since users are not security conscious and approach it as a hassle
to overcome instead of something they should be actively
considering user's are likely to use the same public key pairs on
multiple systems. They are also likely to not change them when
a host has been compromised (if they are even aware that it was.)
>From my perspective SSH authentication as it currently stands is
wonderful for a single knowledgeable user who wants to implement some
security in an environment that does not support any. However, the
use of passwords and raw public keys are inappropriate for any large
organization that wants to implement a serious security policy. In
those environments the SSH authentication mechansims must be replaced
by some thing that is trustworthy and manageable: Kerberos, perhaps
Secure Remote Password, or public key certs if and only if there is an
infrastructure available to issue, distribute, verify, and revoke the
certs.
- Jeffrey Altman
[EMAIL PROTECTED] (Niels Mwller) wrote:
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
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
