[32857] in bugtraq
Re: SSH vs. IKE trust models (was Re: Insecure IKE Implementations
daemon@ATHENA.MIT.EDU (Jimi Thompson)
Mon Dec 15 17:28:25 2003
Message-ID: <3FDBB1DE.8070603@myrealbox.com>
Date: Sat, 13 Dec 2003 18:42:06 -0600
From: Jimi Thompson <jimit@myrealbox.com>
MIME-Version: 1.0
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Thor Lancelot Simon <tls@rek.tjls.com>, aadams@securityfocus.com,
bugtraq@securityfocus.com
In-Reply-To: <20031213113304.GA3496@deneb.enyo.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The new PKI-X standard will address some of these issues, but not all of
them. Our current work around is to give users the right "keys" on a
thumb drive along with a script that "imports" them. All they have to
do is remember to plug it in & double click.
Since they can't authenticate without their key, this works rather well
once we get them trained.
Jimi
Florian Weimer wrote:
>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.
>
>
>
>
