On 16 Nov 2007, at 08:25, Damien Miller wrote:

> Yes - we are very scared of adding features that lead to more
> pre-authentication attack surface, especially when they delegate to
> complex libraries with patchy security histories.


I'm not convinced that adding key-exchange actually increases the pre-
authentication attack surface. At the end of the day the same
payloads are getting passed through to the same privileged process
(and onwards to the same complex library) as happens when doing
GSSAPI user authentication. The only difference is that one happens
after the key exchange step has been performed, and the other happens
as part of it.

However, I don't want to start telling people what they should and
shouldn't include in software they maintain in their own time, and of
their own free will. My site (School of Informatics at the University
of Edinburgh) obviously finds GSSAPI key exchange hugely useful - and
having support for it included upstream would greatly ease my task of
forward porting the patch with every release. That said, out of all
of the platforms we support, there's only one that we care about that
doesn't ship with GSSAPI key exchange support included in their
packages, so its absence in the upstream distribution isn't actually
a great loss to us.

If you've got Kerberos deployed, and used the key-exchange stuff to
solve the ssh host key management problem, doing anything else for a
site with a large number of machines seems unthinkable. If your focus
is on small deployments, where there's no need to achieve these kind
of economies in order to scale your system management, I guess it's
easy to regard the key management code as overkill.

Simon.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev