Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 21 Aug 2003 14:49:01 -0400

Under ``2.1 Opening the Public-Key Subsystem'', it is said that
clients SHOULD reject a request for this subsystem.  I suspect that
that should instead be a MUST.

Under ``2.2 Requests'', is there a good reason to disallow a client
sending more than one request and expecting that the server will
respond to them in order?  (If there is, I think the draft should
probably have a sentence explaining what problem that requirement is
solving; if not, pipelined requests should be allowed.)

Editorial nitpicking:

``3. Public-Key Subsystem Operations'' says that four requests are
defined, including ``command'', but I think ``command'' got absorbed
into the key attributes.

A case-insensitive grep for ``secsh'' in the core drafts doesn't
appear to find any places where the protocol's proper name is
``SECSH''.  I believe that ``the Secure Shell protocol'' and ``the SSH
protocol'' both appear, though.

---

From: "Brent McClure" <[email-masked]>
Date: Mon, 25 Aug 2003 10:26:52 -0600

Joel,

It looks like the version of this document posted to
[email-masked] is out sync with a more recent
version that Jon Bright posted to the working group on 7/25.

There are a number of differences, including the fact that
Jon's 7/25 version includes the often-neglected Security Considerations...

We should probably iron that out.

--Brent

---

From: Jon Bright <[email-masked]>
Date: Mon, 25 Aug 2003 18:27:57 +0200

Hi Brent,

> Jon's 7/25 version includes the often-neglected Security Considerations...

My bad, I posted that to internet-drafts.  I'll look into how I managed 
to post the wrong version and get the right version posted to 
internet-drafts forthwith.

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

---

From: Darren J Moffat <[email-masked]>
Date: Mon, 25 Aug 2003 09:33:40 -0700 (PDT)

> We should probably iron that out.

In addition to this didn't we have consensus that this was a working group
item ?  If so it should be called draft-ietf-secsh-publickey-subsystem-XX.txt

-- 
Darren J Moffat

---

From: Jon Bright <[email-masked]>
Date: Mon, 25 Aug 2003 18:37:27 +0200

Hi Darren,

> item ?  If so it should be called draft-ietf-secsh-publickey-subsystem-XX.txt

I mailed Bill both via the group and privately asking if this was to 
become a WG item - I've not yet had a reply (though I haven't followed 
up, I assume he's a busy man).  The other open question is the naming of 
the subsystem if it becomes a WG item - i.e. should it still be 
@vandyke.com.

Additionally, from the last minutes:

Expected before next IETF:
[...]
	Discussion of whether to accept individual submissions as WG items:
	draft-galb-secsh-publickey-subsystem-01.txt [mcclure]

So, although I'd be happy to submit it under that name, I don't think 
there's yet consensus.  I'll hold off for a day or so on submitting the 
completed version, to see if there's clarification of which name to 
submit it under :-)

---

From: "Brent McClure" <[email-masked]>
Date: Tue, 26 Aug 2003 09:51:02 -0600

----- Original Message ----- 
> that should instead be a MUST.

It seems to me that leaving it SHOULD would be more consistent with
at statement in draft-ietf-secsh-connect-17.txt, Section 4.5 
"Starting a Shell or a Command". With regard to clients receiving
subsystem requests, it just says "The client SHOULD ignore these messages".
It also seems like a client receiving an open request for this subsytem
falls into the category of being something abnormal rather than something
that could expose a risk.

The requests in that document that SHOULD be rejected seem to be
the ones that don't make sense for a client (like receiving a "pty" or 
"session" request). The ones that MUST be rejected seem to be ones
that may be indication of possible foul play (such as unsolicited X11 forwarding).
I think this case is more the former.

> solving; if not, pipelined requests should be allowed.)

Our view was that this was the simplest thing to implement. And, given
that this is a low-bandwidth and intermittently-used protocol, a 
one-request-at-a-time scenario seemed sufficient. Most of the
time a client will get a listing of keys, add a new one or delete one
and that's it. It could be argued that the one-at-a-time requests
requires more state to be maintained than being able to shove a bunch
of requests down a pipe, but if you are checking the results of each
request then even the pipelined implementation is going to require state.
Anyhow that was our take on it.

--Brent