Subject: Secure Shell WG: what's left?

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 08 Aug 2005 20:09:27 -0400

We are decidedly well into the "home stretch".

Here's what's left on our plate:

draft-ietf-secsh-publickeyfile-08: Informational
	In WG Last Call.
	We had an *extended* argument about line termination.
	everything else seems to be OK.  
	Someone want to come up with consensus text?

draft-ietf-secsh-publickey-subsystem-02: standards track.
	Ready for WG Last Call?

draft-ietf-secsh-scp-sftp-ssh-uri-02: standards track.
	Known issue: needs either (a) a trim to remove scp, or (b) a 
	volunteer to write an (informational) SCP spec.  

draft-ietf-secsh-x509-02: standards track
	very new.  needs PKI expert review.

draft-ietf-secsh-filexfer-09
	what can I say but *sigh*.
	the complexity of this draft seems to be increasing,
	due largely to differences in philosophy between posix/unix and
	not-posix/unix filesystems.

draft-ietf-secsh-agent-02    (Expired)
	I'm prepared to write this one off for lack of interest.
	individual submission would be the way to go if someone has the
	energy.

---

From: der Mouse <[email-masked]>
Date: Mon, 8 Aug 2005 21:40:00 -0400 (EDT)

> 	I'm prepared to write this one off for lack of interest.

...??  Am I really the only implementor who bothers to do agent
forwarding?!

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Damien Miller <[email-masked]>
Date: Tue, 9 Aug 2005 16:05:35 +1000 (EST)

> ...??  Am I really the only implementor who bothers to do agent

Of course not. Other implementors (inc. OpenSSH and PuTTY) just run a 
protocol very similar to that used by ssh-1.2.x over a channel. It has 
been thus in OpenSSH since 1999/2000 IIRC.

It makes more sense to just to document this, given its wide deployment
and obvious utility. Even if we were to ship a new agent protocol based on
the aforementioned draft in OpenSSH tomorrow, it would be several years
before is was as widely used as the current one.

-d

---

From: der Mouse <[email-masked]>
Date: Tue, 9 Aug 2005 02:17:56 -0400 (EDT)

> Of course not.  Other implementors (inc. OpenSSH and PuTTY) just run
> a protocol very similar to that used by ssh-1.2.x over a channel.

I see.  I guess I tend not to consider undocumented protocols as worth
considering.  Perhaps it's just me, but I've never been much good at
implementing undocumented protocols.

> It makes more sense to just to document this,

If it's sound, that may be the most sensible thing to do.

Out of curiosity, does it suffer from the same bugs as the existing
agent draft (notably, assuming that it's running over IP)?

> Even if we were to ship a new agent protocol based on the
> aforementioned draft in OpenSSH tomorrow, it would be several years

Are we in any hurry?

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.  (I
already have to use private versions of the requests to make agent
forwarding work with connection sharing....)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 09 Aug 2005 12:27:05 +0200

> implementing undocumented protocols.

But figuring out what the protocol is supposed to be is half the fun!
Seriously, I'm very interested in seeing an agent protocol documented, 
preferably one with a well-defined extension mechanism(*).

> agent draft (notably, assuming that it's running over IP)?

I don't believe so.  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.

> forwarding work with connection sharing....)

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.  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.

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.

(*) 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...

-- Jeff

---

From: der Mouse <[email-masked]>
Date: Tue, 9 Aug 2005 09:03:30 -0400 (EDT)

> 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.

> 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"?

>> 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.

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 09 Aug 2005 16:08:17 +0200

> of the draft (probably -01).  Does that count as "deployed"?

It does if anyone's running your code, I guess.  But having implemented it, 
you know there are problems, like what to do for the links that are not 
over IP.

> client and the agent are implemented in the same executable, but run in

In both cases I actually mean running processes.  So yes, I think that 
describes your implementation.

> AF_LOCAL sockets in /tmp, rather than anything with "ports".

Sorry; my error.

> new agent protocol, I'd like to see that fixed so there's no message

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.

Ultimately, what we're doing is providing connectivity between an ssh 
client and an agent, both of which implement unknown versions of the 
protocol.  It seems to me that if we can arrange to run either version of 
the protocol over the same channel, we've made things a lot simpler and 
more likely to interoperate.

> the protocol, but if it'd help I can take a swing at it.

As I understand it, there isn't really an agent forwarding protocol, aside 
from the messages defined in the ssh spec for that purpose.  They basically 
just channel the same protocol that is spoken between ssh client and agent, 
with no changes.  It seems fairly straightforward to discover the basic 
form of the protocol from the code; it's essentially the same structure as 
what's defined in the agent draft, but the message numbers and contents are 
different.

I think it's premature to write up a spec based on the old protocol, 
unless/until we decide we want to document and extend that and abandon 
what's in the agent draft.  Before we can do that, I think we need to 
answer a few questions...

- Is the tracing of forwarded connections worth keeping?
- Are the messages used by the old protocol too limited, such that
  new messages need to be defined in order to do everything we need?
- Is there some way we can add extensions to the old protocol in a
  sane fashion, so we don't crash the agent or desync the protocol
  if one side doesn't understand an extension?

Some of that is a matter of opinion; some requires reading the old 
protocol.  I don't have time this week to analyze the ssh agent protocol, 
but I can probably spend some time on it in the near future.

-- Jeff

---

From: Jon Bright <[email-masked]>
Date: Tue, 09 Aug 2005 16:21:13 +0200

Jeffrey Hutzelman wrote:
> It does if anyone's running your code, I guess.  But having implemented 
> it, you know there are problems, like what to do for the links that are 
> not over IP.

FWIW, we implement (client-side) both protocols.  The agent in both 
cases is in-process.

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: der Mouse <[email-masked]>
Date: Tue, 9 Aug 2005 10:59:41 -0400 (EDT)

>> 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.

>> 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?
> As I understand it, there isn't really an agent forwarding protocol,
> aside from the messages defined in the ssh spec for that purpose.
> They basically just channel the same protocol that is spoken between
> ssh client and agent, with no changes.

Ah, very much like agent-02 but without FORWARDING_NOTICE?  Then what
we need is to document that fact, and write up something for the
client<->agent protocol (which I believe we should do if we try to
retain the backward-compatability feature).

> unless/until we decide we want to document and extend that and
> abandon what's in the agent draft.

Agreed - except that, as I remarked above, if we try to retain
compatability, I think a document describing the old protocol should
exist somewhere.

> 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.

>   new messages need to be defined in order to do everything we need?

As you note, this is approximately impossible to answer without knowing
the old protocl - which for me, at least, means having some kind of
description of 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.

>   sane fashion, so we don't crash the agent or desync the protocol if
>   one side doesn't understand an extension?

Again, I couldn't say without seeing a spec for the old protocol - and,
if it contains the lacunae I expect it to, some kind of description for
existing implementations as well.

But if the existing protocol and implementations are not designed with
any extension mechanism in mind, I don't think there is anything we can
do here.  If agents are not designed to support extensions, anything
not conforming to their protocol will break them, so clients can't send
anything not conforming; and if clients are not designed to support
extensions, the agent cannot return anything beyond the old behaviour
when responding to old requests, or it risks breaking old clients.
This locks both sides into sticking to the old protocol.

The only reason the existing agent drafts can do old-version sensing at
all is that they aren't using the old protocol - there is a message,
conforming to the old protocol, to which they assign a different
meaning from what the old protocol does.

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 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.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 09 Aug 2005 18:52:15 -0600

> 	not-posix/unix filesystems.

The good news is, I think we are done increasing the
complexity :-)

It is in need of some serious implementing, and massive
copy edit, a sledgehammer of a spell checker, but I think
we are getting closer on this draft too.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 09 Aug 2005 18:57:52 -0600

> 	very new.  needs PKI expert review.

This is very accurate reflection of this draft's
status.

Out of curiosity, is anybody implementing / planning
to implement this draft in the near future?

Anybody have any suggestions on how to catch
a PKI expert?

I'll send a plate of homemade chocolate chip cookies :-)

A bag of MMs?  Doritos?

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 09 Aug 2005 19:04:27 -0600

> draft-ietf-secsh-publickey-subsystem-02: standards track.

I think so... I've kinda of lost track of this one.

Jon, what do you think, are we ready?

I think we have several implementations of version 1
of this protocol-- I'm not sure how many we have of
the current version.

Does anyone know of any open issues for this draft?

Thanks,

Joseph

---

From: Jon Bright <[email-masked]>
Date: Wed, 10 Aug 2005 08:10:04 +0200

> Jon, what do you think, are we ready?

As far as I know, we're ready - but it could be I've forgotten someone's 
issue.

> of this protocol-- I'm not sure how many we have of

I've been meaning to get round to implementing it, but haven't yet.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 10 Aug 2005 12:23:23 +0200

> 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.

> 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.

> with connection sharing, and that's without any attempt at backward

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.

> forms, all of which the old agents accept but only one of which the old

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.

> description of the old protocol at hand, too.

I think this is a fair analysis of the situation.

-- Jeff

---

From: Darren Tucker <[email-masked]>
Date: Wed, 10 Aug 2005 20:00:52 +1000

> ...??  Am I really the only implementor who bothers to do agent

I note that the draft contains the following unspecified IPR claim:

[quote]
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this document.
For more information consult the online list of claimed rights.
[/quote]

however I can find no reference to the specifics.  Plugging the draft
name into https://datatracker.ietf.org/public/ipr_search.cgi returns:

Search result on draft-ietf-secsh-agent, "Secure Shell Authentication
Agent Protocol"
No IPR disclosures related to draft-ietf-secsh-agent have been
submitted

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 10 Aug 2005 12:38:35 +0200

> Anybody have any suggestions on how to catch

I bet Bill could ask our friendly neighborhood AD to provide one.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 10 Aug 2005 12:48:42 +0200

> For more information consult the online list of claimed rights.

At the time that draft was written, the text you quoted was the standard 
boilerplate to be used when an IPR claim had been received that was alleged 
or believed to apply to that document.  Since then, I believe the 
boilerplate has been changed such that it doesn't say whether there is a 
specific claim related to this document, consistent with the IETF's policy 
of not taking positions wrt IPR claims.

> No IPR disclosures related to draft-ietf-secsh-agent have been

I did rather more searches than that, and I couldn't come up with anything, 
either.

-- Jeff

---

From: der Mouse <[email-masked]>
Date: Wed, 10 Aug 2005 12:09:26 -0400 (EDT)

>> 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.
> inadequate, maybe we need to define new ones.

My request and channel type are the same as the ones agent-02 4.1 and
4.2, except that each one has a uint32 appended to it (and they have
private names, of course).  This uint32 is an opaque cookie (opaque to
the server side, that is) that allows the client to tell which request,
and therefore which session channel, a given agent channel open attempt
corresponds to: an agent connection open packet includes the cookie
from the matching agent forwarding request packet.

Otherwise, if you have two sessions on a shared channel, both of which
have requested auth agent forwarding, the connection-sharing
multiplexer on the client side can't tell which session, and therefore
which of the multiplexer's clients, a given agent connection goes with.
(It matters if the two clients are talking with different agents.)

This does lose one capability of the stock protocol, that being agent
connection opens without corresponding agent forwarding requests.  I
don't consider this a significant loss, especially since I agree with
agent-02 that "Implementations MUST reject [auth-agent channel open]
messages unless they have previously requested agent forwarding".

I had to do similar things for X forwarding too, though in that case I
consider x11-req (as in connect-25 6.3.1) and x11 (connect-25 6.3.2)
broken enough that I don't even try to be compatible with them.  (For
agent forwarding, my code falls back to using the agent-02 mechanisms
if the other end doesn't use my fixed versions, and simply doesn't work
through connection sharing then.)

I've been told modern openssh does connection sharing - when I was at
BSDCan in May another person there showed me a manpage including an
option for it.  Does anyone here know what they do about this issue,
how they deal with the "which session does this agent channel open go
with" question?  If there's some way to do it with the stock request
and channel type, I'd very much like to know it - but I sure can't see
one; I think there simply isn't enough information.

> 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.

By "channel" do you mean the thing connect-25 speaks of as a channel,
or do you mean it in a more generic sense?

Either way, I don't see any such dependency in either agent-02 or my
mutated version of it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 10 Aug 2005 19:29:29 +0200

> I've been told modern openssh does connection sharing - when I was at

It claims to have such switches.  I've not tried using it.  Maybe I will, 
just to see what happens.  I certainly haven't read the code with respect 
to this behavior, but maybe I will.

> or do you mean it in a more generic sense?

I meant in the ssh sense.

> Either way, I don't see any such dependency in either agent-02 or my

Good.

Off to dinner now.  I'll look at this more later...

-- Jeff

---

From: Damien Miller <[email-masked]>
Date: Fri, 12 Aug 2005 15:12:02 +1000 (EST)

On Wed, 10 Aug 2005, der Mouse wrote:

> option for it.

Yes, for over a year now. Though the multiplexed X11 and agent support is 
more recent (CVS only).

> Does anyone here know what they do about this issue,

Correct, connection multiplexing in OpenSSH will share a single agent 
and/or X11 listener between all sessions forwarded over a single TCP 
connection.

Apart from the lack of support[*] for forwarding multiple X or agent 
sockets in the protocol, I was concerned about users coming to depend on 
connection sharing to enforce sufficient separation between sessions with
different privilege. In particular, the risk of timing attacks, etc.

-d

* it is entirely possible to forward multiple X11 sessions using the
   protocol as specified. You can use the fake X11 auth cookie to as a
   key, but of course it gets complicated if they collide and you need
   to make sure that they are long enough so as to be practically
   unguessable.

---

From: der Mouse <[email-masked]>
Date: Fri, 12 Aug 2005 01:23:16 -0400 (EDT)

> sockets in the protocol, I was concerned about users coming to depend
> on connection sharing to enforce sufficient separation between
> sessions with different privilege.  In particular, the risk of timing
> attacks, etc.

As reasonable a concern as that is in general, I have trouble getting
worried about it when the two conceptual connections are perforce
authenticated as not only the same user, but with the same
authentication method and data.

I have even more trouble getting worried about it with respect to agent
and X forwarding when waving off the same issues as they apply to
ordinary data flow (necessarily; there is no choice about this when
doing connection sharing, unless you're prepared to do some kind of
traffic shaping on the sub-connections, which is Hard given the
ignorance the ssh code generally has of the underlying network
characteristics).

Perhaps this just reflects a difference in our target audiences, or
more precisely in the threat models that are lurking in our minds when
we make choices like these.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 12 Aug 2005 19:46:10 -0400

> of not taking positions wrt IPR claims.

I believe the "there are IPR claims" notice was added due to the
trademark issue.

> > No IPR disclosures related to draft-ietf-secsh-agent have been

To my knowledge, no IPR disclosures related to the trademark were ever
filed.  The IETF IPR disclosure process has subsequently been made
patent-specific.

> I did rather more searches than that, and I couldn't come up with anything, 

As of shortly before the core drafts were approved, the ietf process for
trademark references was fixed to permit documents to reference the 
registration authority for a claimed trademark.  This is generally
necessary only when a listed author/contributor is the trademark
registrant or is bound by an agreement with the trademark registrant to
identify that a word is trademarked.

					- Bill