Re: Insecure IKE Implementations Clarification
On Fri, Dec 12, 2003 at 11:00:31PM +0100, Florian Weimer wrote:
> Thor Lancelot Simon wrote:
>
> > For what it's worth, the possibility of this general type of attack was
> > repeatedly discussed in the IPsec working group and is a major reason
> > why XAUTH was abandoned. The particular password-stealing attack that I
> > describe as been widely discussed among IKE implementors for at least two
> > years; other implementors probably independently noticed it at least as
> > early as I did, which was three years ago.
>
> And we have technology deployed that solves exactly the same problem in
> a reasonable way: SSH.
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. 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.
Yes, there are multiple implementations out there that implement both
chain-of-trust (certificate) and web-of-trust (PGP) mechanisms for
validating host keys on first contact. Unfortunately, the attempts to
standardize this have repeatedly been shot down in the SSH working group,
which is extremely unfortunate. Human factors *are* a real issue in
secure protocol design; secure protocols that just handwave important
issues by telling users to do something appropriate out-of-band, and
that require large numbers of users to do so on a regular basis, have a
serious design flaw, IMHO.
IPsec is a perfectly good suite of protocols. IKE itself is pretty good,
too, modulo its great complexity. The issues I have pointed out in this
thread are, in the first case, due to a fundamental misuse of public-key
cryptography and certificates, and in the second case, due to a very very
poorly designed and nonstandard protocol extension, not due to anything
about IKE itself.
Thor