Subject: WG Last Call for secsh core drafts.

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 20 Jan 2001 16:46:09 -0500

A Working Group Last Call begins today and will end in two weeks for
the following four drafts:

	draft-ietf-secsh-architecture-07.txt
	draft-ietf-secsh-transport-09.txt
	draft-ietf-secsh-userauth-09.txt
	draft-ietf-secsh-connect-09.txt

I believe that these documents likely represent the current consensus
of the working group and should be submitted to the IESG for
consideration for publication as a Proposed Standard.

Comments regarding the content of these documents should be sent to
the working group mailing list, <[email-masked]>.  If you believe
a change to a document is necessary, it would be very helpful if you
include revised wording along with your comment.

This Last Call period extends until February 3rd, 2001.

					- Bill

---

From: [email-masked] (Niels M�ller)
Date: 23 Jan 2001 22:06:49 +0100

The encoding rules for ssh-rsa signatures (in the transport draft)

: The resulting signature is encoded as follows:
: 
:   string    "ssh-rsa"
:   string    rsa_signature_blob
: 
: rsa_signature_blob is encoded as a string containing s (which is an
: integer, without lengths or padding, unsigned and in network byte
: order).

is not consistent with the architecture draft,

:     mpint
: 	[...]
: 
: 	By convention, a number that is used in modular computations in
: 	Z_n SHOULD be represented in the range 0 <= x < n.

The value s is definitely such a number. Why is it not encoded as an
mpint? The differences in the actual encoding rules are small (the
differences is when leading zero digits are allowed or required).
Using two almost equivalent encodings for numbers only adds to
confusion and complexity.

I also believe that any argument for not using mpint in the RSA case
would apply equally well to most other the places in the protocol
where mpints are used.

Regards,
/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 Jan 2001 21:32:28 -0500

> differences is when leading zero digits are allowed or required).

My evaluation of this is that this isn't an editorial change, since
"mpint" is a signed integer.

For modulus sizes which are a multiple of 8 bits, a sender using the
"string" encoding will send a value with the most significant bit set
about half the time, which an "mpint" decoder will interpret as a
negative value.

So, do we want to leave the draft alone, or should we include include
an implementation note that says that mpints received as an
rsa_signature_blob should always be treated as positive numbers?

Any views from the implementors?  Is consistency important enough to
warrant breaking interoperability?

How big of an installed base does this signature type have?  Do we
need to pick a new name?

> confusion and complexity.

Understood, though one can argue consistency with the dss signature
blob (which is also sent as a string).

					- Bill

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Wed, 24 Jan 2001 20:25:18 -0700

In section 4.6 of the connection draft,

   http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-09.txt

I was pleased to see the following new text:

  As the user's shell is usually used to execute the
  subsystem, it is advisable for the subsystem protocol
  to have a "magic cookie" at the beginning of the protocol
  transaction to distinguish from arbitrary output from
  shell initialization scripts etc. This spurious output
  from the shell may be filtered out either at the server
  or at the client.

Are there plans to update the sftp draft

   http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt

to include such a magic cookie?

Jeff P. Van Dyke
[email-masked]

---

From: Markus Friedl <[email-masked]>
Date: Thu, 25 Jan 2001 09:15:36 +0100

>   from the shell may be filtered out either at the server

i really think that this paragraph should be deleted from the drafts,
since the subsystem protocols (e.g. secsh-filexfer) are not the place
where misconfigurations and broken shell accounts should be fixed.

> to include such a magic cookie?

oh please, do not. the filetransfer protocol is not a place where you
can fix every possible system configuration error. i don't like to see
the secsh protocol suite move towards a drop-in box for features that
might be useful for this and that obscure situation. we should try
to avoid any kind of bloat.

-markus

---

From: Damien Miller <[email-masked]>
Date: Thu, 25 Jan 2001 20:04:37 +1100 (EST)

> to avoid any kind of bloat.

Agreed.

Why not skip the shell initialisation altogether for subsystems?

-d

-- 
| ``We've all heard that a million monkeys banging on | Damien Miller -
| a million typewriters will eventually reproduce the | <[email-masked]>
| works of Shakespeare. Now, thanks to the Internet, / 
| we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org

---

From: [email-masked] (Niels M�ller)
Date: 25 Jan 2001 11:20:24 +0100

> > The encoding rules for ssh-rsa signatures (in the transport draft)
...

> "mpint" is a signed integer.

Exactly, it is a change to the protocol although a small one.

> rsa_signature_blob should always be treated as positive numbers?

I think it would be good to make it very vlear that the encoding used
is not compatible with mpint.

> blob (which is also sent as a string).

I used to argue that the dss encoding was wrong as well (iirc, an
earlier draft, specified it as

  mpint r
  mpint s

and that was later changed to

  string dss-signature-blob

with no motivation provided for the change. My guess is that it was
done to match the ssh2 implementation).

Actually, using unsigned numbers rather than mpint turned out to make
the dss code in implementation slightly simpler.

I belive we should either stick to using mpint, for consistency. Or
conclude that signed mpints are unneeded and too complicated, add an
mpuint type, use mpuint for the rsa signature values, and recommend
that mpuint rather than mpint be used for representing values in Z_n.

The latter alternative is an editorial change (I could write it up if
desired), and it makes the inconsistency more visible.

/Niels

---

From: Mats Andersson <[email-masked]>
Date: Thu, 25 Jan 2001 12:25:08 +0100 (MET)

> Why not skip the shell initialisation altogether for subsystems?

Agreed^2

We alreday have "exec" for having a command in a shell... Subsystem seems
to implicate something cleaner IMHO.

Cheers,

/Mats

---

From: Markus Friedl <[email-masked]>
Date: Thu, 25 Jan 2001 12:22:46 +0100

i think this is a implementation or even a site policy.
perhaps the site does accounting by login shells (e.g. /bin/false).

but, after all, i think all this does not belong to the protocol.

-markus

---

From: [email-masked] (Niels M�ller)
Date: 25 Jan 2001 14:26:39 +0100

> where misconfigurations and broken shell accounts should be fixed.

I agree completey.

> > to include such a magic cookie?

BTW, if one *really* wants to kludge around this particular system
configuration error, one doesn't need any changes to the protocols.
The server can exec the sftp-subsystem, look for the first
server->client message

  00 00 00 05  length
  02           SSH_FXP_VERSION
  00 00 00 03  version number

and throw away any garbage sent by the subsystem before that. I
haven't yet seen any broken shell initialization scripts that send NUL
bytes to stdout, so I think that's all magic you could possibly need.

And I'm even more against requiring the *client* to to kludge around
configuration errors on the server than requiring the server to do the
same.

/Niels

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Thu, 25 Jan 2001 06:56:06 -0700

> where misconfigurations and broken shell accounts should be fixed.

I believe the new paragraph was added after the discussion
regarding subsystems during the Working Group meeting in
San Diego.

First, some background for those who weren't in San Diego.

  Joseph Galbraith and I wrote a draft for a new channel for
  managing public keys.

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

  The consesus on the list and at the working group meeting was
  the draft needs to be rewritten as a subsystem.

  One of the reasons we had chosen to use a channel rather than a
  subsystem was because we discovered with some current server
  implementations, a user can have something in their .cshrc
  that will break the use of a subsystem.  Most recently, one
  of our customers had an echo statement that sent an XTerm 
  escape sequence.  Because nothing visible was being echoed when
  the customer logged into the his account, this problem was
  a bit difficult to track down.

  I would like to see extensions for transferring files, managing
  public keys, etc. that can't be broken by a user making a simple
  mistake  with his .cshrc.  I believe the extensions must be more
  robust than that.

I think skipping shell initialization is a good alternative.
In my opinion, it is probably a better alternative than the
magic cookie.

However, the consesus at the meeting seemed to be that this
was not acceptable.  As I recall, Bill Sommerfeld indicated
that some subsystems require the shell initialization.  Bill?

A third alternative would be to require shell initialiation,
but require the server to discard all output from the shell
initialization prior to starting the subsystem.  This was
discussed during the meeting, but I'm not sure how practical
this solution is.

I believe the draft requires some language to address this
problem.  I would find it very unfortunate if we simply
deleted the paragraph and didn't address this issue in the draft.

Jeff P. Van Dyke
[email-masked]

---

From: Markus Friedl <[email-masked]>
Date: Thu, 25 Jan 2001 16:58:44 +0100

> deleted the paragraph and didn't address this issue in the draft.

i think the best (and only) thing the draft could do is to have an
advise for imlementors that says: be aware of broken .cshrc or other
profile scripts can confuse subsystems if the login shell is involved.

broken .cshrc scripts confuse rsh or rsync, too. it's not a secsh
specific problem.

-markus

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 25 Jan 2001 18:05:25 +0200 (EET)

> > Why not skip the shell initialisation altogether for subsystems?

The reason for shell initialization for subsystems was related to the sftp
umask issue.  I have a slight preference for executing
subsystems directly (not reading users .cshrc, and not setting
user's default umask), whereas at least Sami Lehtinen preferred to have
subsystems run through the user's shell (which means umask can default to
user's umask).

So we must basically decide on the subsystem execution method and the
user's default umask at the same time.

    Tatu

---

From: "Joseph Galbraith" <[email-masked]>
Date: Fri, 26 Jan 2001 08:41:13 -0700

> broken .cshrc scripts confuse rsh or rsync, too. it's not a secsh

I'm not fond of this behavior in rsh or rsync either.  My
not so humble opinion is that they are broken in this regard.
I would hope that in the years since rsh was done, we've learned
enough not to make the same mistake again.

This isn't a completely obscure problem.  We've been shipping SFTP
for less than three months, and we have seen numerous reports from
customers regarding this problem.

Joseph

---

From: "Joseph Galbraith" <[email-masked]>
Date: Fri, 26 Jan 2001 08:37:53 -0700

> subsystems run through the user's shell (which means umask can default to

I think we should change the draft to specify that subsystems are
executed directly (not reading users .cshrc, and not setting
user's default umask).

> user's default umask at the same time.

To address the SFTP UMASK problem, I would suggest adding a mechanism
for setting UMASK to the SFTP draft.

- Joseph

---

From: Markus Friedl <[email-masked]>
Date: Fri, 26 Jan 2001 19:14:27 +0100

> executed directly (not reading users .cshrc, and not setting

no, the protocol should not specify this. an implementation
advice could be added, but shell vs. no-shell is a site
or implementaion policy.

the protocol should not care at all.

-m

---

From: Markus Friedl <[email-masked]>
Date: Fri, 26 Jan 2001 19:24:25 +0100

> enough not to make the same mistake again.

no, it's not a mistake of rcp or rsync or cvs or whatever
runs over rsh and ssh.

if you want to have .cshrc print messages for every login,
then i can use stderr for these kind of things.

-markus

---

From: Darren J Moffat <[email-masked]>
Date: Fri, 26 Jan 2001 11:42:02 -0800 (PST)

-- 
--
Darren J Moffat

---

From: Darren J Moffat <[email-masked]>
Date: Fri, 26 Jan 2001 11:48:21 -0800 (PST)

> advice could be added, but shell vs. no-shell is a site

I support this view point as well.  umask is a UNIX concept (which has
its own problems on some systems, eg default ACLs on Solaris) and is
no justification for requiring the users shell be run before subsystems.

Running the users shell could potentaill introduce security problems
on some systems, unless you clean the environment before running the
subsystem, but if you are going to do that why run the users shell at all.

> the protocol should not care at all.

I would go stronger than that and say that the protocol MUST not care.

Many systems have alternate mechanisms of setting up the users umask
without requiring the users login shell to be run.  Implementations are
should be advised, but not required, to do the appropriate thing using
what ever is appropriate for the host platform.

--
Darren J Moffat

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 26 Jan 2001 20:35:02 -0500

> Exactly, it is a change to the protocol although a small one.

My viewpoint here (admittedly biased towards the the pragmatic) is
that this is at worst merely an aesthetic flaw.  in the presence of
folks with running code and in the absence of wg consensus that a wire
protocol change makes sense, we should attempt to keep the wire
protocol compatible even at the expense of some aesthetic
inconsistency.

> is not compatible with mpint.

Yes, this makes sense.

> the dss code in implementation slightly simpler.

Interesting.

> desired), and it makes the inconsistency more visible.

Yes, please, so we have a concrete proposal to review..

Any comments from the rest of the WG?  On an issue which may involve a
wire protocol change, I'm unwilling to assume that silence equals
agreement..

					- Bill

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Fri, 26 Jan 2001 20:28:11 -0700

> the protocol should not care at all.

I think a shell vs. no-shell for subsystems is more than 
just a site or implementation policy.

If subsystem is going to be *the* main way toextend SECSH, I
believe this mechanism must be robust.  Allowing the server
to start the subsystem in a way where the channel isn't
clean and where stdout or stderr coming from a source
other than a client is a mistake.

I would find the following acceptable:

  1) remove the text about magic cookies

  2) add text indicating there must be a way to configure
     the starting of a subsystem where the stream is clean

  3) add implementation advice that servers may wish to
     provide a mechanism for starting subsystems with
     a shell or user's enviroment

With this change, it would be possible to configure a 
UNIX SSH server to invoke a public key subsystem so
the .cshrc would not be used.  And, it would allow the
same system to configure sftp such that the .cshrc
would be used and the default umask would be set.

By making this change, when the .cshrc is used is a
server configuration issue.  But more importantly,
it guarantees a robust mechanism for extending SECSH.

For those who still think we should simply delete the
new language about magic cookies, would they be opposed
to extending SECSH by adding new channels as a more
robust way of extending SECSH?

Jeff P. Van Dyke
[email-masked]

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Fri, 26 Jan 2001 20:30:28 -0700

> wire protocol change, I'm unwilling to assume that silence equals

I would agree this is mostly an aesthetic issue.

I would prefer to see no more than an editorial change
for this issue.  I would find it equally acceptable to
leave it as is.

Jeff P. Van Dyke
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 27 Jan 2001 08:52:42 +0100

> executed directly (not reading users .cshrc, and not setting

To me, that seems very much like an implementation detail. It's Unix
tradition that daemons never start any user processes except by
invoking the user's login shell, and many systems have restricted
accounts where the restrictions are implemented by a special login
shell in the passwd-database. (I'm not sure about how user CGI scripts
are usually started, though).

But a secsh implementation is still free to start subsystems in any
way it likes. If you want to start some or all subsystems by plain
exec(), not involving the user's login shell, please do (and I would
like to hear about any problems that causes).

> for setting UMASK to the SFTP draft.

I don't see any need for setting the umask in the protocol. If a
client requests a file to be created, without specifying attributes,
then the user's umask (if available) can be used for the defaults. OR
the server provides some default permissions in some other way. As
long as the default is reasonable (i.e. files are not created world
writable, that's fine.

When a client wants more control than that, the right way is for the
client to specify the exact permission flags it wants, not to add the
very unix-specific notion of umask to the protocol.

/Niels

---

From: Tatu Ylonen <[email-masked]>
Date: Sat, 27 Jan 2001 12:34:16 +0200 (EET)

I would prefer not to change the wire protocol.

    Tatu

---

From: Markus Friedl <[email-masked]>
Date: Sat, 27 Jan 2001 16:05:05 +0100

> just a site or implementation policy.

for example, many sites use /bin/false as a login shell for disabled
accounts (propaply much more than users with /bin/csh and a broken
.cshrc).  if you decide that the SECSH protocol says that all
subsystems _must_ be executed directly, without the login-shell,
then these users are allowed to use SFTP.

> other than a client is a mistake.

you probably mean 'subsystem process' instead of client.

but even the .cshrc problems can be fixed without
changing the protocols. when a ssh-server executes a subsystem,
it can wait for some magic cookie. but this is an implementation
detail and there is no need to add these cookies to the
protocols themselve.

>   1) remove the text about magic cookies

i agree.

>      the starting of a subsystem where the stream is clean

s/must/should/

>      a shell or user's enviroment

this sounds reasonable.

> would be used and the default umask would be set.

so after all, it's a site policy.
i completely agree with this.

> robust way of extending SECSH?

i strongly support the deletion of the paragraph
about 'magic cookies, an implementation advices
is more than enough.

-markus

---

From: Sami Lehtinen <[email-masked]>
Date: Wed, 31 Jan 2001 13:23:44 +0200

Been out of the loop for a few days (no net at my new apartment),
sorry.

Tatu Ylonen, on January 25. 2001, wrote:
  : > On Thu, 25 Jan 2001, Damien Miller wrote:
  : > > Why not skip the shell initialisation altogether for subsystems?
  : 
  : The reason for shell initialization for subsystems was related to the sftp
  : umask issue.  I have a slight preference for executing
  : subsystems directly (not reading users .cshrc, and not setting
  : user's default umask), whereas at least Sami Lehtinen preferred to have
  : subsystems run through the user's shell (which means umask can default to
  : user's umask).

My preference for running it with the user's shell is because a) it
has worked reasonably well b) sysadmin's use login shell's as a
control mechanism c) with filexfer, the shell startup scripts are
where a user sets their umasks (without this, the umask would have to
be set in the daemon (system-wide setting)).

  : So we must basically decide on the subsystem execution method and the
  : user's default umask at the same time.

Correct.

Commenting on the "magic cookie" paragraph: as Neils correctly pointed
out, the magic cookie would be the SSH_FXP_VERSION packet (or
SSH_FXP_INIT, depending on which side does the filtering). So no
special "SSH_FXP_MAGIC" packet would be added. The section in the
draft-ietf-secsh-connect is just an implementation hint.

-- 
[[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/]