Re: applying AES-GCM to secure shell: proposed "tweak"

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

On Wed, Apr 15, 2009 at 05:32:19PM -0400, der Mouse wrote:
> >  - negotiation of compression only post-authentication (a very useful
> >    and awesome OpenSSH extension)
> 
> (a) What's so useful about it?  (I don't offhand see any reason why it
> would be better than starting compression at kex time, and I'm
> wondering what I've missed.)

Our implementation (SunSSH) has a different approach to PrivSep than
OpenSSH.  We recognize that doing privsep pre-authentication gets no
real privilege separation[*] for any components other than compression.
So SunSSH's sshd does privsep only post-authentication, which keeps its
montior protocol very very simple.  Therefore we'd like to defer
compression to post-authentication

[*] We noticed that the monitor protocol for supporting pre-auth privsep
    was not materially simpler than the pre-auth parts of SSHv2 (i.e.,
    the monitor protocol was quite complex).  Buffer overflow attacks on
    the crypto are not likely (until the recent SHA-3 submissions I was
    unaware of any such buffer overflows), but buffer overflow
    vulnerabilities against zlib are nothing new.  Therefore privilege
    separation for zlib would be nice, and the simplest way to do it is
    to defer it to post-authentication.  Besides, there's very little
    that can be compressed or is worth compressing between key exchange
    and authentication.  See:

    http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ssh/README.altprivsep


> (b) Got a pointer to the spec?  I'd like to read up on it and see if I
> want to implement it.  (I would _hope_ that OpenSSH would be, well,
> open with their extensions - but I was unable to find any spec for
> keepalive%openssh.com@localhost, so maybe not.)

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL?rev=1.12;content-type=text%2Fplain

Nico
--