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

[Jimi Thompson <jimit () myrealbox com>]

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