Message-ID: <3FDBB1DE.8070603@myrealbox.com>
Date: Sat, 13 Dec 2003 18:42:06 -0600
From: Jimi Thompson <jimit@...ealbox.com>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Thor Lancelot Simon <tls@....tjls.com>, aadams@...urityfocus.com,
	bugtraq@...urityfocus.com
Subject: Re: SSH vs. IKE trust models (was Re: Insecure IKE Implementations
 Clarification)


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.
>
>
>  
>

Powered by blists - more mailing lists