IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: IESG feedback on core drafts.



Joseph Galbraith <galb-list%vandyke.com@localhost> wrote:
> Here is my proposed revision:
[...]
> 11.4 Man-in-the-middle
[...]
>    This vulnerability to man-in-the-middle attacks can
>    be mitigated in several fashions:
[...]
>    2. Use an authentication method that is not vulnerable
>       to man-in-the-middle.  For example, public-key
>       authentication is not vulnerable to man-in-the-middle
>       attack, because the signature is made across data
>       that is session specific.

It might be worth mentioning explicitly that this is assuming the
solution of a similar key-distribution problem to the one which lays
SSH open to MITM in the first place!

Sure, if you've _already_ copied your public key to the server in a
secure manner, then PK auth is a good way to defeat MITMs. But if
you have _already_ had access to the server in a secure manner in
order to do this, why didn't you just note down the host key
fingerprint while you were there?

Conversely, PK auth doesn't solve your problem if you've never made
a secure connection to the server before, because your very first
connection is vulnerable to MITM and so you can't guarantee that
it's a safe channel through which to copy your public key to the
server - a hypothetical MITM could rewrite the key on the way past
and end up giving the server a public key of his own instead of
yours.

(Of course, this is not an issue if your problem is that you're
connecting to a server you've used before from a new client machine
which doesn't contain your existing host key database. But it isn't
a cure-all, so in a section whose job is to state this sort of thing
explicitly, perhaps it would be a good thing to mention.)

Cheers,
Simon
-- 
Simon Tatham         "That all men should be brothers is a
<anakin%pobox.com@localhost>    dream of people who have no brothers."



Home | Main Index | Thread Index | Old Index