protocol support for privilege seperation

[Wei Dai <weidai%eskimo.com@localhost>]

It's a good idea for an SSH server to drop down to normal user privileges 
after authentication is complete, and only make requests to a privileged 
monitor for things like key re-exchanges. Unfortunately, without changes 
to the SSH protocol as currently defined, there seems to be no way to do 
this without allowing the non-privileged process to perform 
man-in-the-middle attacks if it was compromised.

The attack is as follows. Assume an attacker is able to corrupt a 
non-privileged SSH process and cause it to execute arbitrary code. He 
impersonates the server at the TCP/IP layer and waits for someone to log 
in. When a connection comes in, he starts a key re-exchange as the 
couterparty to the SSH process that he controls, using the SSH_MSG_KEXINIT 
packet he received from the remote party and forwarding responses back and 
forth until the key exchange is complete. At this point, even if the 
Diffie-Hellman key generation and agreement were done in the privileged 
monitor, the monitor must either pass the shared secret back to the 
non-privileged process, or act as an encryption/MAC oracle for it. Either 
way, the attacker can now send arbitrary messages to the remote party that 
it will think came from the server.

The problems seems to be that the privileged monitor has no way to tell 
whether a SSH_MSG_KEXINIT packet is for the initial key exchange, or for a 
re-exchange. I propose making use of the reserved field of 
SSH_MSG_KEXINIT, something like:

byte      SSH_MSG_KEXINIT
...
boolean   first_kex_packet_follows
boolean   is_initial_exchange
byte[3]   0 (reserved)

The privileged monitor would refuse to sign any exchange hash where
is_initial_exchange is true if it's not an initial exchange. I think that
would allow implementors to take full advantage of privilege seperation
and avoid this attack. If current implementations are programmed to ignore
the reserved field (rather than treat a non-zero value as an error), this
should cause no compatibility problems. Specificly, an old client that
does not make use of is_initial_exchange would be vulnerable to this
attack, but it would still work.

Comments?