Jeffrey Altman <[EMAIL PROTECTED]> writes:
> 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.
The problem is that _even_ if you know the security implications, you
sometimes goon with an unauthenticated host key (yes, I'm speaking for
myself. This is confession-mode). Sometimes, I have the hostkeys
written down in my calendar, sometimes I do cat /etc/ssh_hostkey after
that I have logged in. The latter doesn't stop a clever MITM-attack,
of course. It's simply too inconvenient to do things right. So my main
objective here is to make security easier for those users who _are_
at least somewhat aware of the security issues.
> >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:
Before commenting on details, let me give a little rant about the
differences between kerberos and ssh, from my point of view. And when
I speak of ssh, I primarily speak about what you can do with the ssh2
protocol, not about current implementations.
First, there are several clue-ness scenarios:
1. clue-less user, clue-less or overworked sysadm.
In this case, we're basically screwed. No one can stop the user from
screwing up the system or giving his keys or passwords away to let
somebody else do it. I'll not say much about it.
2. clue-less user, clue-full sysadm.
This is almost as bad. What the sysadm can do is to limit the amount
of damage the user can cause, and limit the damage the user can cause
for other users on the system. This includes things like eliminating
buffer-overflows that lets the user gain root access, etc. This is
very important, but doesn't have much to do with authentication
mechanisms, so I'll not say much about this either.
3. clue-full user, overworked or clue-less sysadm.
This is one scenario that I think is important. I want to be able to
make secure connections and stuff even if my local sysadm doesn't have
a minute left after (hopefully) patching up known security holes on
the system. And I want this to be _easy_ to do for any user who cares
about it, without requiring lots of non-trivial hackery.
4. clue-full user, clue-full sysadm.
This is an important (but probably quite rare) case. I suspect this is
the case for any large organization that cares about security (or more
precisely: who cares about security, and has any chance of actually
getting some). So this ought to be the case that is most important for
you.
To me, it seems that kerberos is a unified solution for authentication
(and one with a few known problems). You have to deploy it in an
all-or-nothing fashion. We have the protocols, a centralized
security model, libraries and applications. Deploying it in the
scenario (3) is virtually impossible.
On the other hand, ssh supports scenario (3), for example both ssh and
sshd can be installed by a unprivileged user. [ Password authentication
in sshd won't work for systems with shadow passwords, but I consider
this a bug in the shadow mechanism. There ought to be a way for a user
to get his/her _own_ encrypted password out of the system, or some
more general verify_my_password(a_passwd) function ].
ssh is far from ideal; the support for both (3) and (4) could be a lot
better. To get there is partly an implementation issue, but we may
also need to define new authentication methods to use within the ssh
protocol. That's my interest in all this.
I think one problem with kerberos is that when you want to communicate
between to different sites (or realms, in kerberos-speak), the sysadms
of those realms must have had some previous contacts, and must have
installed a shared key for this realm-pair. Of course, ssh doesn't
quite solve this problem either, but the important difference is that
ssh at least makes it possible for users to solve the problem for
themselves, without any need for cooperation between the respective
sysadms.
> (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.
One solution to this is to use certificates, issued by the site's
sysadm, rather than raw hostkeys (I don't know of any ssh
implementations that actually supports this).
Personally, I like SPKI style certificates, and I think that
certificates with a validity field that requires an on-line check
should make it easier to revoke and change hostkeys. Of course, if the
certification key is compromised, we're screwed, but I don't think it
is possible to address this issue without some centralization
(kerberos ticket-granting server, the private key for the site's
certification keys, etc). Any such centralization provides some point
of attack that is more attractive than a random host.
> (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.
I think this is a unique feature of kerberos. I see that it can be
important under some circumstances, but I don't think that it is
crucial in the general case. Consider a site with a central
authentication server C (for instance using kerberos), and several
hosts. Now, a user sits down at a random host A, and logs in on
another host B. Now, A and C will see the user's cleartext password,
but not B. So if B was compromised, we're still somewhat safe.
But this is quite useless, unless we have some reason to believe that
it is a lot less likely that A is compromized than B. Under what
circumstances is this true?
As far as I can see, the typical case is that A is a machine in an
office, a lab or terminal room, and B is some kind of cpu- or
file-server. To me it seems a lot easier to ensure the security of B
(for example, you want to restrict who can get physical access to the
machine) than for A. I.e. the opposite of the above hypothesis seems
to be true.
There are of course other scenarios as well, for instance A may be a
reasonably well protected _personal_ computer, but this case is also
the case where it is reasonable to store a private key on A and use
something like ssh's publickey user authentication.
> Secure Remote Password would allow a password to be used with
> out transmitting any revealing data to the host.
Regardless of the above, it's a good thing to distribute the password
as little as possible. Ideally, only A should get the password
(there's no way around this, as far as I can see, except for things
like smartcards), and both B and C should stay ignorant. I'd like see
such an authentication protocol with ssh.
> (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.
Low-entropy passwords tend to be the weakest link in any security
system that relies on passwords. This is tricky; some of the
references in this thread try to address it. I don't know yet how well
one can do.
But I think kerberos is far from ideal here; I suspect you can mount a
dictionary attack [1] after recording some communication between you
and the kerberos server (correct me if this is utterly wrong). And if
the local machine is compromized, it may transmit your password to the
attacker as you type it. I'm willing to take for granted the security
of the local machine, because I don't see how I could get any security
at all without it.
[ NOTE: By a dictionary attack this I mean bruteforcing the passwd
space; I don't imply that you can do massive precomputations like on a
/etc/passwd file with small salt. I think this is about as much as you
can do agaist a reasonable scheme that encrypts a private key or other
_unknown_ data using a passphrase ].
> (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.)
ssh doesn't have any mechanism to let the sysadm revoke some keys from
a user's authorized_keys file (or for key revokation in general, for
that matter). This is not a protocol issue, but an implementation
issue. And a difficult one, I don't know how to do it right.
I want to give the user the authority to decide which keys are
authorized for logging into her account. If I don't do this, the
user still has the authority to decide with whome to share her secret
password, or to take instructions from unathorized persons on what to
use her account for.
What I really want to to is to give user's the ability to delegate
*some* of her power to certain keys or certificates. For instance, to
access some subset of her files, or run some programs.
> >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.
I'd like ssh to offer the features needed for large organizations. If
I can find out how.
Two final questions for those of you using kerberos: If you already
have kerberos up and running on your site(s), why would you consider
using ssh at all? If you want to combine them, would one of the
following possibilities suit your needs?
* Use kerberos to create an encrypted connection between your
machines. Run the ssh connection-protocol on top of that tunnel (i.e.
do things like starting shells, forward X and tcp, etc, but don't do
any of the ssh style authorization or encryption).
* Use ssh, but add an authentication algorithm that lets you login
using a kerberos ticket that you obtained earlier.
/Niels
