SSH vs. IKE trust models (was Re: Insecure IKE Implementations Clarification)

[Thor Lancelot Simon]

On Fri, Dec 12, 2003 at 11:25:55PM +0100, Florian Weimer wrote:
> Thor Lancelot Simon wrote:
>
> > Yes and no. SSH is not, by itself, a network-layer encryption solution,
> > and there are many applications where that's really desirable. The other
> > issue is, of course, that SSH's model for authenticating host identities
> > is, itself, a mess: in this day and age, it is not acceptable to just
> > punt on the problem of first contact and pretend that users will reasonably
> > exchange key fingerprints offline.
>
> You don't exchange fingerprints, you just store them. Previously, I

Indeed, and you have no way to know that you are storing the right
fingerprint.

> > The widespread success of sniffing and MITM attacks on the SSH
> > protocol -- all due to users not doing what the protocol, by omitting
> > any means of using a hierarchy or web to validate host keys, requires
> > them to do -- should be proof enough of this.
>
> There are very few such attacks in the wild. Most machines which do not

That's not true; such attacks have been widely documented at every recent
IETF meeting.

Nothing prevents you from using certificate-authenticated IKE the exact
same way you use your web browser: store individual host certificates,
instead of the root certificate and the DNs of the parties you expect to
connect to. However, nothing *enables* you to use SSH with either a
hierarchical trust model (which you seem to not like) or a web-of-trust
model (ala PGP) where you decide whom to trust and how much, because
both have been proposed to the working group and both have been,
effectively, shot down. As I said, that is very unfortunate, and the
dsniff and other attacks at recent IETF meetings and elsewhere (e.g. on
college campus networks) illustrate that real users are suffering for
it in the real world right now.

Thor

[Florian Weimer]

Thor Lancelot Simon wrote:

> That's not true; such attacks have been widely documented at every recent
> IETF meeting.

This may be the case, but keep in mind that the attack is only possible
the first time you log into the server from a specific host. On my
notebook, all the keys I need have already been stored, that's why I can
use SSH securely even over untrusted networks.

If, at some conference, I used someone else's terminal to log into my
machines, a MITM attack would certainly be possible, but I don't know
much about the integrity of the terminal anyway.

> Nothing prevents you from using certificate-authenticated IKE the exact
> same way you use your web browser: store individual host certificates,
> instead of the root certificate and the DNs of the parties you expect to
> connect to.

For most organizations, it's not an option to roll out tens of thousands
of certificates. The resulting level of support calls is just
unacceptable. Passwords are somewhat ri$sky, but users grok that
concept pretty well. Especially on university networks, you'll have to
face the problem that users want to move their certificates/keys from
one system to another one. Such tasks are too complicated with current
VPN solutions (which might a feature on corporate networks, but some
networks are different).

> However, nothing *enables* you to use SSH with either a
> hierarchical trust model (which you seem to not like) or a web-of-trust
> model (ala PGP) where you decide whom to trust and how much, because
> both have been proposed to the working group and both have been,
> effectively, shot down.

So what? You can use patched SSH servers and clients (or proprietary
implementations) to get certificate-based authentication. There will
never be a world-wide SSH server PKI, no matter what the SSH standards
say. If you have to patch all your machines to use certificates, this
doesn't make much of a difference.

> As I said, that is very unfortunate, and the dsniff and other attacks
> at recent IETF meetings and elsewhere (e.g. on college campus
> networks) illustrate that real users are suffering for it in the real
> world right now.

For SSL, dsniff already handles the certificate case pretty well.
Unless both terminal and server are in the same PKI. Unfortunately,
you cannot reuse the web browser PKI for that because the costs are
prohibitive ($200 per SSH server is a hefty price tag).

If this issue bothers you so much, I will write a short Perl script
(based on LWP) that fetches SSH server keys from a given URL and adds
them to ~/.ssh/known_hosts. This way, you can import trust from the web
browser PKI.