Subject: Re: X forwarding: suggestions

From: Jeffrey Altman <[email-masked]>
Date: Tue, 23 Jan 2001 8:15:11 EST

> Suggestion 2: make the server do it!
> ------------------------------------
> 
> Better still, it seems to me, why not make the SSH _server_ invent
> the remote auth data and verify it?
> 
> This doesn't allow any new attacks by somebody subverting the SSH
> server and causing it to accept unauthenticated connections, because
> the SSH server already has access to the fake auth data, so anyone
> who subverts it can _already_ pull off this attack. So it places no
> additional trust in the SSH server to let it authenticate incoming
> X connections.
> 
> The advantage would be that the server can perform
> XDM-AUTHORIZATION-1 or other complex authentications very easily,
> because it obviously does have access to the source IP/port of the
> incoming connection - or to the equivalent if the connection should
> come in on a Unix domain socket. It seems silly to forward all the
> details back to the client and make the client do it, when there's
> no reason for the server not to just do it itself.
> 
> The server would them strip out the auth strings from the X
> connection before forwarding it back to the client; and the client
> could insert the real auth strings to allow the connection to be
> accepted by the real X server. So each end deals only with what's
> important at that end.

This is almost what Telnet Forward-X does.  The only difference is
that the Telnet Client replaces the stripped Xauth data with the data
necessary to authenticate to the local X server.  This allows daisy
chained connections to be protected.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.