Subject: Secure Shell Public Key Channel

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Fri, 17 Nov 2000 07:14:54 -0700

An individual draft for Secure Shell Public Key Channel has
been submitted.  The draft is available from:

  http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-channel-00.txt

Abstract

   SECSH defines an authentication mechanism that is based on public
   keys, but does not define any mechanism for key distribution.
   No common key management solution exists in current implementations.
   This document describes a channel that can be used to configure
   public keys in an implementation-independent fashion, allowing
   client software to take on the burden of this configuration.

   The public key channel provides a server-independent mechanism
   for clients to add public keys, remove public keys, and list
   the current public keys known by the server. Rights to manage
   public keys are specific and limited to the authenticated user.

   A public key may also be associated with a mandatory command.

---

On a several occasions, there has been some interest in trying to
standardize the file format of SSH public keys.  At this time,
I believe this draft provides a better and more comprehensive
solution to the problem that users are having managing SSH
public keys.  We are very interested in receiving feedback on
this draft.

If time permits and there is sufficient interest, we hope there
will be an opportunity to discuss this draft at the upcoming
meeting in San Diego.

Jeff P. Van Dyke
[email-masked]

---

From: "Richard E. Silverman" <[email-masked]>
Date: Mon, 20 Nov 2000 23:12:13 -0500 (EST)

Jeff and Joseph,

I have read the public-key channel draft you posted, and have a few
comments.

1)

The proposal strikes me as a good idea.  I wonder if it shouldn't be
generalized, though.  You're introducing an abstraction allowing clients
to control authentication and authorization (AA) properties for the remote
account.  SSH is extensible, and already supports a number of AA
mechanisms besides public-key.  Each one has a similar problem: the
authorization data is represented in some ad-hoc way that may change from
one server OS or sshd implementation to another (e.g. a Kerberos-5
principal being listed in ~/.k5login).

We could instead have an "AA channel", with requests parameterized by the
authentication type we want to manipulate -- each authentication type
would have its own space of operations, such as the add/remove/list you
propose for public keys.  This then be easily extensible to other
authentication methods should that prove useful, but would not
significantly complicate the protocol or implementation, I think.

2)

   The Secure Shell Public Key Channel has been designed to run on
   top of the SECSH transport layer [SSH-TRANS] and user authentication
   protocols [SSH-AUTH]...

I think the wording here should be changed.  There is a similar comment in
the SSH-CONN draft, and it is confusing.  Neither SSH-CONN nor your
proposed protocol runs "on top of" SSH-AUTH -- they both run directly on
top of SSH-TRANS.  Rather, there is an expectation that before allowing a
client to request either of these services, the server will have
authenticated the client.  This may mean that they will run *after* a
successful run of the SSH-AUTH protocol -- but that is sequencing, not
protocol layering.  Furthermore, it is not required.  A special-purpose
SSH server might allow anyone to engage in SSH-CONN immediately after
setting up an SSH-TRANS connection, providing some restricted, anonymous
service to anyone who knocks.  Or, an implementation might authenticate
the client via some other means outside the SSH protocol, and then proceed
directly with SSH-CONN.  I think allowing for these scenarios is part of
the point of defining SSH-AUTH separately in the first place.

I suggest something like this:

   The Secure Shell Public Key Channel has been designed to run on top of
   the SECSH transport layer [SSH-TRANS].  It is expected that the server
   will require client authentication before allowing the client to use
   the public-key channel, and that this will normally happen via a
   preceding use of the SECSH user authentication protocol [SSH-AUTH] on
   the same SSH-TRANS connection.

3)

I think the feature of adding a forced command for a key should also be
generalized.  Existing SSH servers have many authorization options that
users can associate with the public keys for an account -- e.g. the
"from", "no-pty", "command", etc. options in the authorized_keys file.  A
forced command is just one of these.  Instead of a special-purpose
"publickey-command" request, how about "set attribute" instead, taking
these arguments:

  authentication-type
  authentication-token
  attribute-name
  attribute-value

A publickey-command request would then look like this:

  set-attribute("publickey",<key>,"command","/bin/ls")

But now the same framework could equally well support something like this:

  set-attribute("kerberos-5","res@REALM","from","10.1.2.3")

We would then need requests to list the attributes supported by the
server, delete attributes, and list attribute/value pairs currently
associated with a given (method,token) pair.

-- 
  Richard Silverman
  [email-masked]

---

From: Martin Forssen <[email-masked]>
Date: Tue, 21 Nov 2000 11:20:03 +0100 (MET)

>    top of the SECSH transport layer [SSH-TRANS] and user authentication

Shouldn't this be defined as a subsystem instead of as a new channel
type? A new channel type sounds a bit too low level for me and a
subsystem would make it much easier to write clean implementations.

	/MaF

---

From: [email-masked] (Niels M�ller)
Date: 21 Nov 2000 13:32:03 +0100

> subsystem would make it much easier to write clean implementations.

The choice of making a particular feature a subsystem or a channel
type is a trade-off. A subsystem may be cleaner (unless there's bulk
data transfer involved, in which case one may have to reimplement the
flow-controlled channel mechanism is), but I believe new channel types
are more flexible from a user perspective. It's nice to be able use a
single ssh connection for all operations.

For instance, look at file transfer. With new channel types for up-
and download of files, it would be possible to write an ssh client
where you type some command character, get into file transfer mode,
start a few transfers in the background, and then return to your
interactive shell or whatever the connection was used for earlier. You
can't do that as conveniently with a subsystem like sftp; in
particular not if you're using some userauth mechanism that requires
you to type some password or passphrase for each new connection.

Does anybody have any guidelines for the choice between channels and
subsystems?

/Niels

---

From: Martin Forssen <[email-masked]>
Date: Tue, 21 Nov 2000 14:04:15 +0100 (MET)

> single ssh connection for all operations.

This is not a valid argument. Subsystems are defined as a subtype of the
session channel type and nothing prevents you from using as many
simultaneous sessions as you want in a single connection. Any eventual
limitations lies entirely in the client.

> you to type some password or passphrase for each new connection.

But you can start multiple session channels within one ssh connection.
From the connection draft section 4.

"    4.  Interactive Sessions
    
A session is a remote execution of a program.  The program may be a
shell, an application, a system command, or some built-in subsystem.  It
may or may not have a tty, and may or may not involve X11 forwarding.
Multiple sessions can be active simultaneously."

Specially note the last sentence.

The Appgate client can for example open a number of separate terminal
windows (i.e. shell command channels) simultaneously all sharing one
single ssh connection. The F-secure Mac client can also have multiple
shell windows active simultaneously.

	/MaF

---

From: [email-masked] (Niels M�ller)
Date: 21 Nov 2000 14:20:49 +0100

> limitations lies entirely in the client.

You're absolutely right. I was confusing "subsystems" with
"services". Sorry about that.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 21 Nov 2000 16:07:58 +0100

Mats Andersson <[email-masked]> writes:

> This is only if the client can't handle multiple sessions, remember it's
> still within the same ssh connection, i.e. it's not a problem with the
> protocol (if you don't mean to define session == connection?).

I was confused (as MaF already pointed out). So please forget that.

> On another note, there is also of course the possibility to instead have a
> special authentication type which handles the initial deployment and other
> handling of authorized keys (not sure why this would be better or worse
> though :-).

As the transport level and the key exchange are the most security
critical parts of the protocol, I think it is better not to add any
feature there unless it is really necessary. I.e. mess with the
transport and keyechange *only* if the feature can't be implemented in
any other way.

/Niels

---

From: Mats Andersson <[email-masked]>
Date: Tue, 21 Nov 2000 15:56:33 +0100 (MET)

> you to type some password or passphrase for each new connection.

see above

Cheers,

/Mats

---

From: Mats Andersson <[email-masked]>
Date: Tue, 21 Nov 2000 16:38:30 +0100 (MET)

> I was confused (as MaF already pointed out). So please forget that.

Sorry, I wrote it before seeing his post.

> > special authentication type which handles the initial deployment and
> other > handling of authorized keys (not sure why this would be better
> or worse > though :-).
> 

As I wrote, define a new authentication method. I don't see how this would
be bad? (or have anything to do with transport/KEX?) As I see it, this is
really a form of user authentication (e.g. first authenticated with an OTP
and then have the ability to deploy a key, and/or edit/view authorized
keys if necessary). IMHO it is thus more logical to have this implemented
as an authentication method. Or as MAF points out subsystem for that
matter since the edit/view functionality of course seems more like an
application feature rather than an authentication method :-).

Cheers,

/Mats

---

From: Sami Lehtinen <[email-masked]>
Date: Tue, 21 Nov 2000 18:54:09 +0200 (EET)

Martin Forssen, on November 21. 2000, wrote:
  : The Appgate client can for example open a number of separate terminal
  : windows (i.e. shell command channels) simultaneously all sharing one
  : single ssh connection. The F-secure Mac client can also have multiple
  : shell windows active simultaneously.

... and our Windows client does this too.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Tue, 21 Nov 2000 10:31:45 -0700

> subsystem would make it much easier to write clean implementations.

Can you elaborate on this?  Why do you think it is too low level?

Why do you think making it a subsystem would make it much easier
to write a clean implementation?

In our implementation, making it a channel or subsystem doesn't
make much difference.

We've been considering a number of extensions to SECSH.  And for
most of these, we've been leaning towards using channels because
of the flow control.  I'd be very interested in hearing from
others about the pros and cons of extending SECSH by adding
new channels versus extending SECSH by adding new subsystems.

The only subsystem that I know of that is widely available is
sftp, and with our implementation we could have just as easily
implemented a file transfer protocol as a channel.

With the public key channel as specified, I don't believe flow
control would be a problem.  Therefore, if the consensus is that
it should be a subsystem, we would be willing to rewrite the
draft to reflect this.

Jeff P. Van Dyke
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 21 Nov 2000 22:41:03 +0100

> to write a clean implementation?

After a quick look at the draft, I think I agree with MaF. It seems a
little against the spirit of the channel mechanism to attach meaning
to the boundaries between successive data packets, and it seems to be
a little at odds with its flow control.

For instance, I would expect that for _any_ channel, it would be legal
for an implementation to give the sending party a window size of just
1 octet, receive a SSH_MSG_CHANNEL_DATA packet with 1 octet of data, send
a SSH_MSG_WINDOW_ADJUST message increasing the window size with 1
octet, and so on. That wouldn't work with the proposed protocol.

Hmm. On second thought, for this problem it doesn't really matter if
it is a subsystem or not. The problem is the use of
SSH_MSG_CHANNEL_DATA and the atomicity requirements.

An alternative might be to package the requests as
SSH_MSG_CHANNEL_REQUEST. One possible exception is the list request,
where it would make sense to use some kind of flow control, but I
still think it would be inappropriate to specify where the
SSH_MSG_CHANNEL_DATA boundaries should fall in the data stream.

> In our implementation, making it a channel or subsystem doesn't

How do you deal with the case that you have a transmission window-size
that is non-zero, but smaller than the next data packet you want to
send?

> of the flow control.

Are you saying that subsystems doesn't use flow-control? The spec
isn't very clear on what a "subsystem" is allowed to do, but from my
reading it appears that "subsystem" is just like "exec", with a
different interpretation of the command-line/subsystem name.

It would be nice if a subsystem could somehow grab few more message
types, something like like

  byte   SSH_MSG_CHANNEL_SUBSYSTEM_REQUEST
  uint32 recipient channel
  string subtype (meaning depending on the subsystem)
  ... subsystem and subtype dependant data

  byte   SSH_MSG_CHANNEL_SUBSYSTEM_REPLY
  uint32 recipient channel
  string subtype (meaning depending on the subsystem)
  ... subsystem and subtype dependent data

(The primary difference from SSH_MSG_CHANNEL_REQUEST is that the
subsystem can stuff more data into the reply).

> implemented a file transfer protocol as a channel.

Are there any official specs for sftp yet?

Regards,
/Niels

PS. Sorry if I'm getting a little incoherent here. I haven't read the
specs for any subsystem, even less implemented one. So I don't really
know how they are expected to work.

---

From: Sami Lehtinen <[email-masked]>
Date: Wed, 22 Nov 2000 02:35:10 +0200 (EET)

Niels Möller, on November 21. 2000, wrote:
  : Are there any official specs for sftp yet?

No, and will not be before or during the San Diego IETF (we (Tatu and
I) missed the deadline for the submission of new drafts).

I will, however, be putting it out by other means for the joy of the
working group, in the near future (unless somebody objects to
this).

I submitted the core drafts late yesterday evening EET (that's about 5
hours ago), and judging from the automatic reply I received, it may
take a while for them to be published.

---

From: Mats Andersson <[email-masked]>
Date: Wed, 22 Nov 2000 09:52:50 +0100 (MET)

Question:

If I have two different sessions where I would like to forward X11
channels to two different local displays, how would I do that given the
protocol doesn't give any hints on which session a certain x11
SSH_MSG_CHANNEL_OPEN belongs to.

The only way I can think of is to delay the actual connect to the local
display until the bogus cookie is received and can be mapped to a specific
session (and hence display).

This is kind of pathological (and I guess that nobody does this) but I'm
just curious.

Cheers,

/Mats

---

From: Martin Forssen <[email-masked]>
Date: Wed, 22 Nov 2000 11:35:05 +0100 (MET)

> to write a clean implementation?

Both the ssh2-servers which I have examined more closely implements
subsytems as external processes which means you can add a new
subsystemwithout any modifications to the ssh server code at all. In
contrast new channel types needs numerous modifications to the
server-code.

My feelings when reading the draft (and Tatu kind of confirmed this in
his post) is that subsystems are meant to be higher upp in the protocol
stack and handle application-level stuff. ANd I see publickey management
as definitely an application-level issue.

> new channels versus extending SECSH by adding new subsystems.

As others have already stated, flow-control is not an issue since it
applies to subsystems as well (they are after all built on top of
channels).

	/MaF

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Wed, 22 Nov 2000 07:11:08 -0700

> applies to subsystems as well (they are after all built on top of

A channel can control the flow by sending (or not sending)
window size adjustments.  From draft-ietf-secsh-connect-07.txt:

  3.2.  Data Transfer

  The window size specifies how many bytes the other party can send before
  it must wait for the window to be adjusted.  Both parties use the
  following message to adjust the window.

    byte      SSH_MSG_CHANNEL_WINDOW_ADJUST
    uint32    recipient channel
    uint32    bytes to add

How does a subsystem do this?

As I understand subsystems, the session channel has flow control,
but there is wall between the session channel and the subsystem.
Therefore, the subsystem protocol must re-implement a flow
control mechanism.

Imagine a subsystem that uses one thread to read and one thread
to write to the SSH2 server via a pipe (assuming the subsystem
is an external process).  In this case, the reader and the writer
may need to coordinate to make sure the reader doesn't get too far
ahead of the writer.

Now consider a channel that uses one thread to read and
one thread to write.  Since the writer would be responsible
for sending window adjustments, the reader can't get too far
ahead of the writer.  In a multi-threaded implementation, this
simplifies things.

I think in many cases, the flow control mechanism required in the
subsystem would be "easy" to implement.  My point is that if you
use a channel, you don't have to implement it.  

With the public key channel as specified, I don't believe flow
control would be a problem.  And therefore, there is no real
obstacle to making it a subsystem.

> subsystem without any modifications to the ssh server code at all. In

Since we'd like to see servers implement the public key
channel/subsystem, I think your observation about existing
implementations may be a compelling reason to rewrite
the draft as a subsystem.  By doing so, it wouldn't even be
necessary for the server vendor to implement it - a 3rd party
could implement the public key subsystem.

Jeff P. Van Dyke
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 22 Nov 2000 14:51:39 +0100

> SSH_MSG_CHANNEL_OPEN belongs to.

I don't think that is pathological at all.

> session (and hence display).

There's also the X display number, which seems more appropriate for
identifying different x displays. It is sent with the
SSH_MSG_CHANNEL_REQUEST thet requests forwarding. Both the display
number and the cookie will be sent in the first X request as each X
channel is opened, if I recall the X protocol correctly.

The client will typically replace the cookie before sending the
initial X request to the real X-server. It could look at the display
number as well, even if it seems ugly to delay the open (it's nicer to
open the connection immediately on SSH_MSG_CHANNEL_OPEN, in order to
give the peer a correct SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
SSH_MSG_CHANNEL_OPEN_FAILURE.

A simple change would be to include the display number in the
SSH_MSG_CHANNEL_OPEN message, like

  byte      SSH_MSG_CHANNEL_OPEN
  string    "x11"
  uint32    sender channel
  uint32    initial window size
  uint32    maximum packet size
  string    originator address (e.g. "192.168.7.38")
  uint32    originator port
  uint32    display number

Is this a reasonable change? Making implementations backwards
compatible should be straight-forward (look at the length of the
packet; if the display number is missing, fail unless exactly one
display number have been sent earlier with "x11-req").

As an alternative to sending the display number (which won't
necessarily match the display number used by any real x server
anyway), one could send the channel number of the corresponding
session.

Another question: Say the server sets up an AF_UNIX socket for
communicationg with its proxying X server. What should the fields
"originator address" and "originator port" contain? I believe using an
AF_UNIX socket with paranoid permissions is preferable to using an
ordinary tcp socket and MIT_MAGIC_COOKIE-style authentication.

/Niels

---

From: Martin Forssen <[email-masked]>
Date: Wed, 22 Nov 2000 16:09:41 +0100 (MET)

> Therefore, the subsystem protocol must re-implement a flow

The idea is that the subsystem should not do any flow control by itself.
That is a transport issue and therefore automatically handled by the
lower layers (i.e. the underlying stream channel). The subsystem will
just see two pipes, one to read from and one to write from. And that is
all there is to it.

	/MaF

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2000 06:46:31 -0500

>>>>> "Mats" == Mats Andersson <[email-masked]> writes:
    Mats> This is kind of pathological (and I guess that nobody does this) but I'm
    Mats> just curious.

  I have often used Xnest so that various applications that break with
certain window managers can be run with the window manager they prefer. 

  Being able to forward a connection to my Xnest would be nice.
  So I don't think this is that pathological.

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems   Oh where, oh where has|problem  with[
]     [email-masked]   www.solidum.com   the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Mats Andersson <[email-masked]>
Date: Fri, 24 Nov 2000 10:15:38 +0100 (MET)

Hi,

> channel is opened, if I recall the X protocol correctly.

Well, the draft says it's the "screen number" actually, the X server has
several displays which each one can have several screens. What it (the
draft) fails to describe is exactly what the "screen number" means here.

The draft also ommits describing how the returned SSH_MSG_CHANNEL_OPEN
should be mapped back to a specific request which was my question/problem
(which your suggestion would of course solve IFF the "screen number" in
the request is defined to be the local display to connect back to, which
is fine by me).

This would also solve the problem when one session requests a x11 channel
with "single connection" set to true, and another requests an x11 channel
where it's set to false. All this is of course not very well defined how
the server should handle either...

However, as I said, this can of course be handled with just setting
different cookies to different requests and we will know how to map them
back (but will have to delay the actual local connect until we get the
cookie). But I guess a small change in the protocol would be preferable
here.

> anyway), one could send the channel number of the corresponding

Sounds better to me, mapping it to the channel seems cleaner to me.

Suggestion for the draft:

Introduce a last field in the SSH_MSG_CHANNEL_OPEN type "x11" in which the
client channel number that was the origin of the request is put by the
server. Define ALL the fields in the SSH_MSG_CHANNEL_REQUEST (type "x11")
aswell as the fields in the SSH_MSG_CHANNEL_OPEN (type "x11") (sections
4.3.1 and 4.3.2 of the connection draft). Also define the "screen number"
(or change to "display number"?) how it's used on server, and on client.

Cheers,

/Mats

---

From: [email-masked] (Niels M�ller)
Date: 24 Nov 2000 15:53:04 +0100

> draft) fails to describe is exactly what the "screen number" means here.

Hmm, you're right, we need one identifier to identify the X-server
(display) to connect to, and another one for the screen number. The
screen number must be sent in the "x11-req" SSH_MSG_CHANNEL_REQUEST,
in order for the peer to set the final component of $DISPLAY properly,
but should not otherwise matter much to the client.

Remote processes should be free to use a different screen number when
actually connecting to the X server (unless the client explicitly
wants to forbid that), while they must not be able to connect to any
other display than that being forwarded.

> (or change to "display number"?) how it's used on server, and on client.

I think it's unnecessary to include the channel number, it's better to
use a display-id that is mapped to an x-server by the client. So I'd
propose the following:

:   byte      SSH_MSG_CHANNEL_REQUEST
:   uint32    recipient channel
:   string    "x11-req"
:   boolean   want reply
:   boolean   single connection
:   string    x11 authentication protocol
:   string    x11 authentication cookie
:   uint32    x11 screen number
:   uint32    display-id
: 
: The display id is used by the originator of this message to identify
: a (usually local) X display. It may use several id:s for the same X
: display, in order to enforce the single-connection property when
: requesting X forwarding for several concurrent sessions. 

and

:   byte      SSH_MSG_CHANNEL_OPEN
:   string    "x11"
:   uint32    sender channel
:   uint32    initial window size
:   uint32    maximum packet size
:   string    originator address (e.g. "192.168.7.38")
:   uint32    originator port
:   uint32    display-id
: 
: The display-id MUST be the same as in the corresponding "x11-req"
: message.

An alternative would be to use a string for the display-id (that way,
a client could put its value of $(DISPLAY) there. But I think a
numeric id is slightly better). The handling of the display-id field,
on the client side, is similar to the handling of the address-to-bind
and port-number-to-bind fields in the tcpip-forwarding messages: It is
first looked up in the table of requested forwardings, and if it is
found, that list provides the target for the forwarded connection.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 27 Nov 2000 12:08:48 +0100

Tatu Ylonen <[email-masked]> writes:

> I personally think it would be a mistake to add the display-id.  It
> would only add complexity, with no added value.  It is just an
> incompatible change.

I think something more is needed (although on second thought, I'm not
sure if a "display-id" provides any real benefit over providing the
channel number of the associated channel. If anyone is interested, I
can expand on my thinking here).

One may need it even if there is only a single display. For instance
if you have several sessions and want to allow only one X connect from
each session (hmm, I was sure there was some "only one connection"
flag in the x11-req and tcpip-forward messages, but now it seems I
have dreamt that up). 

> If the client ever needs to perform an association similar to
> display-id, it can be implemented by sending a different fake
> authentication cookie for each thing represented by a display-id,
> and have the client scan its table for the correct fake cookie.

That seems like a kludge: I want to be able to send an accurate
SSH_MSG_CHANNEL_OPEN_FAILURE for attempts to connect to a display I
don't want to forward.

(I don't feel strongly about this, though. I'd support the change if
other people agree it is useful; otherwise I'll be able to hand out
different cookies, or one-time cookies, or something like that).

> Remember that you also need to connect to unix domain sockets.

That reminds me of my previous question: What is the originator
address and originator port supposed to contain if the X client
connected via a unix domain socket?

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 29 Nov 2000 16:05:11 +0100

Tatu Ylonen <[email-masked]> writes:

> If the display is not shared between sessions, then you can already
> implement "one connection only" in either the server or the client.
> (In server you can of course always force separate displays if you are
> configured for "only one connection".)

My point was that implementing it in the client would be easier and
cleaner if there was some id in the x11-req message that was also
included in corresponding CHANNEL_OPEN messages. But perhaps that's
not very important.

> I don't object to specifying some special value for this case (e.g.,
> address "unix-domain", port "").

Hmm. Perhaps it's better to use the empty string? As I have said
before, I think one will sometimes want to send dns names rather than
ip-numbers, so magic strings that happen to be valid dns names are
perhaps a bad idea.

> From an implementation standpoint, however, there are potential
> problems associated with forwarding unix-domain sockets.

Would you like to share your experiences? I haven't really looked into
X forwarding yet, but in general, I believe unix-sockets with paranoid
permissions are more appropriate than tcp sockets.

/Niels