Re: New Proposal for Section 11.1.4 Man-in-the-middle

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

Ah, yes, that is good.

Thank you,

Nico

On Fri, May 16, 2003 at 10:37:12AM -0700, Chris Lonvick wrote:
> Hi Simon and Nico,
> 
> I believe that the point you're trying to make would come under the
> Authentication Protocol section rather than being left in the Transport
> section on MITM.  That section starts with the following:
> ===
> 11.3 Authentication Protocol
> 
>    The purpose of this protocol is to perform client user
>    authentication.  It assumed that this runs over a secure transport
>    layer protocol, which has already authenticated the server machine,
>    established an encrypted communications channel, and computed a
>    unique session identifier for this session.
> ===
> Is that sufficient for your concerns or should this section also contain a
> warning about trying to run _any_ authentication mechanism over an SSH
> session that has not already been authenticated (at the device level)?
> 
> Thanks,
> Chris
> 
> 
> On Thu, 15 May 2003, Nicolas Williams wrote:
> 
> > Than you Simon, your comment makes the point I tried to make the other
> > day, but more clearly and eloquently than my poor attempt.
> >
> > Nico
> >
> > On Thu, May 15, 2003 at 03:27:41PM +0100, Simon Tatham wrote:
> > > Chris Lonvick  <clonvick%cisco.com@localhost> wrote:
> > > >    2. Use an authentication method that is not vulnerable to
> > > >       man-in-the-middle attacks.  For example, public-key authentication
> > > >       is not vulnerable to man-in-the-middle attack as long as the
> > > >       public-key of the server has been securely distributed to the
> > > >       clients before the first SSH connection is made.
> > >
> > > Surely the other way round?
> > >
> > > If the server's key has already been securely distributed to the
> > > client, then _no_ authentication method is vulnerable to MITM -
> > > that's precisely what the server's host key is for! I don't see how
> > > public-key authentication is any better than other methods in this
> > > respect.
> > >
> > > If the _user's_ public key has been securely distributed to the
> > > _server_ before the first SSH connection is made, then public-key
> > > authentication might be able to verify the server's host key which
> > > was previously unknown.
> > >
> > > However, this is conditional on the user being sure they really have
> > > connected to the right server! I grant that an MITM seeing a
> > > public-key authentication request wouldn't be able to use it to gain
> > > access to the real server; but they could simply return Yes, and
> > > _pretend_ to be the real server for as long as they could get away
> > > with it in the absence of a genuine login there, in the hope that
> > > the user might try to (for example) connect through to some other
> > > system and type a password in. The user would have to verify the
> > > connection by requesting some other piece of information from the
> > > server which they already knew but which the MITM would be unlikely
> > > to guess right.
> > >
> > > Cheers,
> > > Simon
> > > --
> > > Simon Tatham         "The distinction between the enlightened and the
> > > <anakin%pobox.com@localhost>    terminally confused is only apparent to the latter."
> > >
> >
> 
> 
>