Re: Secure Shell WG: what's left?

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> Seriously, I'm very interested in seeing an agent protocol
> documented, preferably one with a well-defined extension
> mechanism(*).

I agree, that would be nice.

>> Out of curiosity, does it suffer from the same bugs as the existing
>> agent draft (notably, assuming that it's running over IP)?
> I don't believe so.

Then that certainly makes it a stronger contender.

> The existing agent draft contains a lot of stuff about tagging
> forwarded agent connections at each hop, so you can tell where things
> came from.  That might be interesting, but I don't see it being
> deployed any time soon.

I believe my implementation does it correctly according to some version
of the draft (probably -01).  Does that count as "deployed"?

>> I also can't see any reason an implementation couldn't support both,
>> perhaps with a slight tweak to the more recent draft if, as it
>> implies, the old protocol uses the same channel type string as
>> agent-02.
> In most cases the ssh client doesn't implement the agent protocol; it
> just forwards it off to some program running on the same machine.

That may or may not describe my implementation, depending on exactly
what you mean by "the ssh client" and "some program".  In my case, the
client and the agent are implemented in the same executable, but run in
different processes.

> From a practical standpoint, I think the best option is to make the
> protocol backwards-compatible and use the same channel string.
> Otherwise implementations like OpenSSH end up having to export _two_
> ports for talking to the agent, depending on which version of the
> protocol you want it to speak.

Ports?  All the implementations I've used (including my own) use
AF_LOCAL sockets in /tmp, rather than anything with "ports".

That aside, yes, it would mean either two rendezvous points (of
whatever kind) or protocols different enough that the implementation
can tell which version is in use from the first packet - and in the
latter case you might as well use the same strings, as you say.

> I would note that because all the messages are different, it should
> be possible to support both protocols on the same channel, and the
> current draft describes how a client can tell whether the agent
> supports the new protocol.

Yes...but the method is an ugly kludge, because, as I read it, the
messages *aren't* all different; there's a collision between agent-02's
REQUEST_VERSION and 1.x please-list-identities.  If we're going to do a
new agent protocol, I'd like to see that fixed so there's no message
number overlap.

> (*) Note that the current agent draft does _not_ have a well-defined
> extension mechanism, as the mechanism it defines requires sending a
> message code which does not fit in the 8-bit field defined for the
> purpose...

Yes, this definitely needs to be fixed.

How can I best help this happen?  Should I sit down with the 1.x code
and try to glark a spec for its agent forwarding protocol?  It seems
inefficient for me to do that, as compared to someone who already knows
the protocol, but if it'd help I can take a swing at it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B