Re: Secure Shell WG: what's left?

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Tuesday, August 09, 2005 10:59:41 -0400 der Mouse 
<mouse%Rodents.Montreal.QC.CA@localhost> wrote:

> > > I believe my implementation does it correctly according to some
> > > version of the draft (probably -01).
> > But having implemented it, you know there are problems, like what to
> > do for the links that are not over IP.
>
> Right - though that's not a problem in practice for me, because I don't
> yet support anything else.
>
> > I believe that particular collision is deliberate, to allow a client
> > to tell which version of the protocol is supported.  It's possible
> > the mechanism needs some work, in which case we should do that.
>
> Hmm.  I'd feel more comfortable about it if the previous protocol were
> documented.  But that's part of what we're talking about, so I think
> this point is actually spurious.

The way I see it, we have two choices.  We can either extend the old 
protocol, or define a new one (which may or may not be based on the 
existing agent drafts).  If we choose to extend the old protocol, then of 
course we need to document it.

If we define a new agent protocol, then we only need enough documentation 
about the old one to allow for version negotation and allow implementations 
that want to support both versions to do so -- just as we did with the core 
ssh protocol and sshv1.


> > Before we can do that, I think we need to answer a few questions...
>
> > - Is the tracing of forwarded connections worth keeping?
>
> I'm not sure.  My agent implementation doesn't do anything with
> FORWARDING_NOTICE packets but skip them - but on the other hand, I
> certainly can see a potential desire that the agent not respond to
> "distant" requests.  In my own ssh_config (I'm still using ssh 1.x on
> some machines) I have a lot of stanzas controlling whom I turn on agent
> forwarding to.  It would be really convenient to be able to control
> this in agent configuration, controlling whom the agent is willing to
> act for, rather than in the ssh client configuration.
>
> The agent does need to trust the client to insert the notices, but the
> local ssh client is presumably trusted.

It does seem useful for that, if people are actually going to implement 
such policy.  If no one is going to use it, then it's pointless to define 
it.


> But I will note that in my implementation I found I had to use private
> requests and channel types in order to make agent forwarding work right
> with connection sharing, and that's without any attempt at backward
> compatability.

Hrm; that's interesting.  If the current request and channel type are 
inadequate, maybe we need to define new ones.  It'd still be nice, I think, 
to avoid tying the agent protocol version to the type of channel it runs 
on, if we can avoid it.


> We could do the same thing, but then we're not just adding extensions
> to the old protocol; then we're designing a new protocol with some
> compatability.  (The major difference is that a new agent will break an
> old client, because it will respond in the new-protocol way to an
> old-protocol request.  The reason the draft protocol doesn't have this
> problem is that they are depending on a hole in the spec interacting
> with a lucky property of existing implementations: the old
> list-identities request can, de-facto if not de-jure, exist in multiple
> forms, all of which the old agents accept but only one of which the old
> clients generate.)

I suspect the situation is very similar to that for sshv1 - there are 
implementations of the existing protocol, but no formal specs.  That may 
mean we have to survey the existing implementations and try to do something 
that doesn't break any of them.  That's unfortunate, but sometimes you have 
to do that sort of thing to make progress.  The important thing is that we 
don't repeat any mistakes we might find, like lack of a spec.

FWIW, about a month ago I was reading openssh agent code as part of the 
process of designing an agent extension I was thinking about (for accessing 
Kerberos ccache's via the ssh agent).  I _think_ I found that the openssh 
agent reacts in a sane way to unknown messages.  I _think_ their extensions 
for smartcard support depend on this behavior.


> I see no major difference between adopting the old protocol with some
> extension hooks (such as taking advantage of the loophole agent-02
> does) and designing a new protocol with backward compatability.  It's
> really a question of how much of the old protocol we can steal intact
> and how much we need to invent - a difference of degree rather than
> kind.  It's also something I can't really speak to without a
> description of the old protocol at hand, too.

I think this is a fair analysis of the situation.

-- Jeff