From owner-ietf-ssh@clinet.fi  Fri Nov  7 10:31:45 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id KAA22556;
	Fri, 7 Nov 1997 10:31:45 +0200 (EET)
Received: from hauki.clinet.fi (majordom@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id KAA08732;
	Fri, 7 Nov 1997 10:31:44 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id KAA22695
	for ietf-ssh-outgoing; Fri, 7 Nov 1997 10:24:43 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ssh.fi (ssh.fi [194.100.44.97])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id KAA22682
	for <ietf-ssh@clinet.fi>; Fri, 7 Nov 1997 10:24:38 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id KAA08704
	for <ietf-ssh@clinet.fi>; Fri, 7 Nov 1997 10:24:37 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with SMTP id KAA22456
	for <ietf-ssh@clinet.fi>; Fri, 7 Nov 1997 10:24:35 +0200 (EET)
Date: Fri, 7 Nov 1997 10:24:35 +0200 (EET)
From: Markku-Juhani Saarinen <mjos@ssh.fi>
To: ietf-ssh@clinet.fi
Subject: New secsh drafts (03) are out.
Message-ID: <Pine.NEB.3.95q.971107101321.15257G-100000@pilari.ssh.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3456
Lines: 123


New secsh drafts have been submitted and will probably be available from
ftp.ietf.org and other official sites on monday. They are already
available from http://www.ssh.fi/drafts.

  draft-ietf-secsh-architecture-01.txt    
  draft-ietf-secsh-transport-03.txt
  draft-ietf-secsh-connect-03.txt        
  draft-ietf-secsh-userauth-03.txt

All of these are dated 7 November 1997.


The encoding of terminal modes remains unchanged. We like it this
way as it is flexible and reasonably easy to implement.

We also came to the conclusion that the (cipher) options that are left in
are easy enough to implement. Finding a second implementation that also
supports these options won't be a problem. The documentation is easier to
read this way.


Summary of changes (corrected typos, minor errors, or rephrasing not 
included):

architecture.txt
----------------

page 6, line 349: [user names] 

  "displayed in logs, reports, etc.  They SHOULD be encoded using ISO 10646"
 changed to
  "displayed in logs, reports, etc.  They MUST be encoded using ISO 10646"

 (there must be an unique encoding for user names)


page 8, line 422.. [encoding]

  Added examples of mpints:
  
     "For example, the value 694531781388612263 (0x9a378f9b2e332a7) is
      represented as 00 00 00 08 09 a3 78 f9 b2 e3 32 a7."
  
  changed to 

     "Examples:
  
         value (hex)        representation (hex)
         ---------------------------------------------------------------
         0                  00 00 00 00
         9a378f9b2e332a7    00 00 00 08 09 a3 78 f9 b2 e3 32 a7
         80                 00 00 00 02 00 80
         -1234              00 00 00 02 ed cc
         -deadbeef          00 00 00 05 ff 21 52 41 11                   "


page 8:

  Added a subsection on encoding of network addresses:

  "4.1.  Encoding of Network Addresses
  
   Network addresses are encoded as strings. DNS names MUST NOT be used, as
   DNS is an insecure protocol.
  
   If an address contains a colon (':', ascii 58), it is interpreted as an
   IPv6 address. The encoding of IPv6 addresses is described in RFC-1884.
   IPv4 addresses are expressed in the standard dot-separated decimal
   format (e.g. 127.0.0.1)."
  

transport.txt
-------------

page 10 [KEXINIT format]:

       .."   string    compression_algorithms_server_to_client
    (new)    string    languages_client_to_server
    (new)    string    languages_server_to_client
             boolean   first_kex_packet_follows   "

page 12:

   Added an explanation of these new fields:

   "languages
        This is a comma-separated list of language tags in order of
        preference [RFC-1766]. Both parties MAY ignore this list.  If
        there are no language preferences, this list SHOULD be empty."


userauth.txt
------------

page 10, line 551 [security considerations]:

  New:

  "The server may go into a "sleep" period after repeated unsuccesful
   authentications to make key search harder."


connect.txt
-----------

page 7, line 375 [window dimensions]:

  Specified what is meant by "pixels":

  .." Zero dimension parameters MUST be ignored. The
      character/row dimensions override the pixel dimensions (when nonzero).
      Pixel dimensions refer to the drawable area of the window."
  
  
page 11, line 627 [exit status]:

  "A zero exit_status usually means that the command terminated successfully."

- mj

Markku-Juhani O. Saarinen <mjos@ssh.fi>, SSH Communications Security Ltd

From owner-ietf-ssh@clinet.fi  Fri Nov  7 19:48:28 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id TAA26624;
	Fri, 7 Nov 1997 19:48:27 +0200 (EET)
Received: from hauki.clinet.fi (majordom@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id TAA11093;
	Fri, 7 Nov 1997 19:48:26 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id TAA13152
	for ietf-ssh-outgoing; Fri, 7 Nov 1997 19:45:10 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id TAA13144
	for <ietf-ssh@clinet.fi>; Fri, 7 Nov 1997 19:45:04 +0200 (EET)
Received: from borg.eos.home.net ([24.0.16.111]) by poptart.corp.home.net
          (Netscape Mail Server v2.02) with ESMTP id AAA26405
          for <ietf-ssh@clinet.fi>; Fri, 7 Nov 1997 09:44:21 -0800
Received: (from rja@localhost)
	by borg.eos.home.net (8.8.5/8.8.5) id JAA10866
	for ietf-ssh@clinet.fi; Fri, 7 Nov 1997 09:44:52 -0800 (PST)
From: rja@corp.home.net (Ran Atkinson)
Message-Id: <971107094451.ZM10864@borg.eos.home.net>
Date: Fri, 7 Nov 1997 09:44:51 -0800
In-Reply-To: Markku-Juhani Saarinen <mjos@ssh.fi>
        "New secsh drafts (03) are out." (Nov  7, 10:24)
References: <Pine.NEB.3.95q.971107101321.15257G-100000@pilari.ssh.fi>
X-Mailer: Z-Mail (4.0.1 13Jan97)
To: ietf-ssh@clinet.fi
Subject: Comments on the new secsh drafts (03)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 603
Lines: 18

On Nov 7 10:24, Markku-Juhani Saarinen wrote:

%  "4.1.  Encoding of Network Addresses
%
%   Network addresses are encoded as strings. DNS names MUST NOT be used,
%   as DNS is an insecure protocol.

Your assertion is false.  Please go read RFC-2065 and RFC-2137.

IMHO, the specification needs to say that DNS names MUST be supported
for network address encodings but DNS-format network address
encodings SHOULD NOT be trusted when Secure DNS is not in use.

Also, the definition of "pixel" remains not very useful for creating
an interoperable system on an OS other than UNIX, IMHO.

Ran
rja@home.net
From owner-ietf-ssh@clinet.fi  Mon Nov 10 21:12:58 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id VAA01679;
	Mon, 10 Nov 1997 21:12:58 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id VAA24311;
	Mon, 10 Nov 1997 21:12:56 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id RAA29809
	for ietf-ssh-outgoing; Mon, 10 Nov 1997 17:14:41 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (ietf.org [132.151.1.19])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id RAA29777
	for <ietf-ssh@clinet.fi>; Mon, 10 Nov 1997 17:14:29 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA12958;
	Mon, 10 Nov 1997 10:14:15 -0500 (EST)
Message-Id: <199711101514.KAA12958@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-architecture-01.txt
Date: Mon, 10 Nov 1997 10:14:14 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3064
Lines: 95

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Protocol Architecture
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen
	Filename	: draft-ietf-secsh-architecture-01.txt
	Pages		: 11
	Date		: 07-Nov-97
	
SSH is a protocol for secure remote login and other secure network
services over an insecure network.
 
This document describes the architecture of the SSH protocol, and the
notation and terminology used in SSH protocol documents. It also discusses
the SSH algorithm naming system that allows local extensions.
 
The SSH protocol consists of three major components: Transport layer
protocol provides server authentication, confidentiality, and integrity
with perfect forward secrecy. User authentication protocol authenticates
the client to the server. Connection protocol multiplexes the encrypted
tunnel into several logical channels. Details of these protocols are
described in separate documents.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-architecture-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-architecture-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-architecture-01.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971107135530.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-architecture-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-architecture-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971107135530.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ietf-ssh@clinet.fi  Mon Nov 10 20:49:10 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id UAA01359;
	Mon, 10 Nov 1997 20:49:09 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id UAA24233;
	Mon, 10 Nov 1997 20:49:08 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id RAA00276
	for ietf-ssh-outgoing; Mon, 10 Nov 1997 17:17:05 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (ietf.org [132.151.1.19])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id RAA00254
	for <ietf-ssh@clinet.fi>; Mon, 10 Nov 1997 17:16:57 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA13028;
	Mon, 10 Nov 1997 10:16:50 -0500 (EST)
Message-Id: <199711101516.KAA13028@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-connect-03.txt
Date: Mon, 10 Nov 1997 10:16:50 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2813
Lines: 92

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Connection Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen
	Filename	: draft-ietf-secsh-connect-03.txt
	Pages		: 17
	Date		: 07-Nov-97
	
SSH is a protocol for secure remote login and other secure network
services over an insecure network.
 
This document describes the SSH connection protocol. It provides
interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. All of these
channels are multiplexed into a single encrypted tunnel.
 
The SSH Connection Protocol has been designed to run on top of
the SSH transport layer and user authentication protocols.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-connect-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-connect-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-connect-03.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971107135811.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-connect-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-connect-03.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971107135811.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ietf-ssh@clinet.fi  Mon Nov 10 21:09:34 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id VAA01649;
	Mon, 10 Nov 1997 21:09:34 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id VAA24292;
	Mon, 10 Nov 1997 21:09:33 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id RAA01339
	for ietf-ssh-outgoing; Mon, 10 Nov 1997 17:26:05 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (ietf.org [132.151.1.19])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id RAA01309
	for <ietf-ssh@clinet.fi>; Mon, 10 Nov 1997 17:25:44 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA13174;
	Mon, 10 Nov 1997 10:24:26 -0500 (EST)
Message-Id: <199711101524.KAA13174@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-transport-03.txt
Date: Mon, 10 Nov 1997 10:24:25 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3055
Lines: 98

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Transport Layer Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen
	Filename	: draft-ietf-secsh-transport-03.txt
	Pages		: 20
	Date		: 07-Nov-97
	
SSH is a protocol for secure remote login and other secure network
services over an insecure network.
 
This document describes the SSH transport layer protocol which
typically runs on top of TCP/IP. The protocol can be used as a basis
for a number of secure network services. It provides strong
encryption, server authentication, and integrity protection. It may
also provide compression.
 
Key exchange method, public key algorithm, symmetric encryption
algorithm, message authentication algorithm, and hash algorithm are
all negotiated.
 
This document also describes the Diffie-Hellman key exchange method
and the minimal set of algorithms that are needed to implement the
SSH transport layer protocol.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-transport-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-transport-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-transport-03.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971107140201.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-transport-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-transport-03.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971107140201.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ietf-ssh@clinet.fi  Mon Nov 10 20:39:52 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id UAA01269;
	Mon, 10 Nov 1997 20:39:52 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id UAA24219;
	Mon, 10 Nov 1997 20:39:51 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id RAA01362
	for ietf-ssh-outgoing; Mon, 10 Nov 1997 17:26:22 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (ietf.org [132.151.1.19])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id RAA01346
	for <ietf-ssh@clinet.fi>; Mon, 10 Nov 1997 17:26:09 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA13206;
	Mon, 10 Nov 1997 10:25:48 -0500 (EST)
Message-Id: <199711101525.KAA13206@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-userauth-03.txt
Date: Mon, 10 Nov 1997 10:25:48 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2808
Lines: 92

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Authentication Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen
	Filename	: draft-ietf-secsh-userauth-03.txt
	Pages		: 11
	Date		: 07-Nov-97
	
SSH is a protocol for secure remote login and other secure network
services over an insecure network.
 
This document describes the SSH authentication protocol framework and
public key, password, and host-based client authentication methods.
Additional authentication methods are deferred to separate documents.
 
The SSH authentication protocol runs on top the SSH transport layer
protocol and provides a single authenticated tunnel for the SSH
connection protocol.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-userauth-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-userauth-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-userauth-03.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971107140431.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-userauth-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-userauth-03.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971107140431.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ietf-ssh@clinet.fi  Tue Nov 11 12:10:15 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id MAA10494;
	Tue, 11 Nov 1997 12:10:10 +0200 (EET)
Received: from hauki.clinet.fi (majordom@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id MAA26880;
	Tue, 11 Nov 1997 12:10:09 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id MAA16334
	for ietf-ssh-outgoing; Tue, 11 Nov 1997 12:05:58 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.7])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id MAA16316
	for <ietf-ssh@clinet.fi>; Tue, 11 Nov 1997 12:05:50 +0200 (EET)
Received: from shadows.cs.hut.fi (shadows [130.233.192.99]) by hutcs.cs.hut.fi (8.8.5/8.7.3) with ESMTP id MAA26921; Tue, 11 Nov 1997 12:05:48 +0200 (EET)
Received: (from kivinen@localhost) by shadows.cs.hut.fi (8.7.6/8.7.3) id MAA00069; Tue, 11 Nov 1997 12:06:47 +0200 (EET)
Date: Tue, 11 Nov 1997 12:06:47 +0200 (EET)
Message-Id: <199711111006.MAA00069@shadows.cs.hut.fi>
From: Tero Kivinen <kivinen@niksula.hut.fi>
To: rja@corp.home.net (Ran Atkinson)
Cc: ietf-ssh@clinet.fi
Subject: Comments on the new secsh drafts (03)
In-Reply-To: <971107094451.ZM10864@borg.eos.home.net>
References: <Pine.NEB.3.95q.971107101321.15257G-100000@pilari.ssh.fi>
	<mjos@ssh.fi>
	<971107094451.ZM10864@borg.eos.home.net>
Organization: Helsinki University of Technology
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-Edit-Time: 23 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2232
Lines: 46

Ran Atkinson writes:
> On Nov 7 10:24, Markku-Juhani Saarinen wrote:
> %  "4.1.  Encoding of Network Addresses
> %   Network addresses are encoded as strings. DNS names MUST NOT be used,
> %   as DNS is an insecure protocol.
> Your assertion is false.  Please go read RFC-2065 and RFC-2137.
> IMHO, the specification needs to say that DNS names MUST be supported
> for network address encodings but DNS-format network address
> encodings SHOULD NOT be trusted when Secure DNS is not in use.

The other end who is receiving the ip-addresses cannot know whether
the secure dns was used in the other end to do the reverse-ip lookup
or not.

It cannot also trust that the other end really used the same kind of
trust paramters it wanted when doing the lookup even if the other end
used secure dns to do the lookup (for example the other end might be
trusting the local dns server that will be doing secure dns lookup for
it and provide the result to client by unsecure dns on "secure"
network (only dnssec server, but local resolver is normal dns)).

All the ip-number information send to other end is from the incoming
tcp/ip connection (getpeername), and I think it is essential to send
it forward without any (unsecure) transformations on the information.

The receiving end will know how the given values are used. It might
for example be doing direct ip-number comparison (match only
127.0.0.1) and the reverse dns lookup done on the other end would just
make things much more complicated (reverse ip lookup for 127.0.0.1,
might return localhost, localhost.ssh.fi etc). 

I think it is up the receiving end to do the reverse lookup if needed
when it is doing its policy decisions, thus we must send the ip
numbers. 

> Also, the definition of "pixel" remains not very useful for creating
> an interoperable system on an OS other than UNIX, IMHO.

I think most of the systems don't use the pixels values at all, but it
just happens to be in the winsize structure and you can always set it
to 0 if you don't know or doesn't have proper value.

Rlogin is forwarding also that information to other end. 
-- 
kivinen@iki.fi		              	     Work : +358-9-451 4032
Magnus Enckellin kuja 9 K 19, 02610, Espoo   Home : +358-9-502 1573
From owner-ietf-ssh@clinet.fi  Wed Nov 12 20:31:55 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.8/8.8.8/EPIPE-1.10) with ESMTP id UAA28492;
	Wed, 12 Nov 1997 20:31:55 +0200 (EET)
Received: from hauki.clinet.fi (majordom@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.8/8.8.8/EPIPE-1.12) with ESMTP id UAA02957;
	Wed, 12 Nov 1997 20:31:53 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id UAA20579
	for ietf-ssh-outgoing; Wed, 12 Nov 1997 20:18:37 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ssh.fi (ssh.fi [194.100.44.97])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id UAA20561
	for <ietf-ssh@clinet.fi>; Wed, 12 Nov 1997 20:18:30 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by ssh.fi (8.8.8/8.8.8/EPIPE-1.12) with ESMTP id UAA02918;
	Wed, 12 Nov 1997 20:13:28 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.8/8.8.8/EPIPE-1.10) id UAA28341;
	Wed, 12 Nov 1997 20:13:25 +0200 (EET)
Date: Wed, 12 Nov 1997 20:13:25 +0200 (EET)
Message-Id: <199711121813.UAA28341@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Tero Kivinen <kivinen@niksula.hut.fi>
Cc: rja@corp.home.net (Ran Atkinson), ietf-ssh@clinet.fi
Subject: Comments on the new secsh drafts (03)
In-Reply-To: <199711111006.MAA00069@shadows.cs.hut.fi>
References: <Pine.NEB.3.95q.971107101321.15257G-100000@pilari.ssh.fi>
	<mjos@ssh.fi>
	<971107094451.ZM10864@borg.eos.home.net>
	<199711111006.MAA00069@shadows.cs.hut.fi>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1378
Lines: 29

> > On Nov 7 10:24, Markku-Juhani Saarinen wrote:
> > %  "4.1.  Encoding of Network Addresses
> > %   Network addresses are encoded as strings. DNS names MUST NOT be used,
> > %   as DNS is an insecure protocol.
> > Your assertion is false.  Please go read RFC-2065 and RFC-2137.
> > IMHO, the specification needs to say that DNS names MUST be supported
> > for network address encodings but DNS-format network address
> > encodings SHOULD NOT be trusted when Secure DNS is not in use.
> 
> The other end who is receiving the ip-addresses cannot know whether
> the secure dns was used in the other end to do the reverse-ip lookup
> or not.

Please note that some people might want to forward an external port to
inside a protected network.  In this case, the internal domain name
might not be visible outside the internal network, and the external
machine cannot resolve the name to an ip address.  If this scenario is
to be supported, it must support passing domain names.

When giving the address of the client that connected to a forwarded
port, IP address only sounds fine; it reduces complexity and doesn't
open room for new security problems (as far as I can see).

    Tatu

-- 
SSH Communications Security	      http://www.ssh.fi/
F-Secure Internet Security Solutions  http://www.datafellows.com/f-secure/
Free Unix SSH                         http://www.cs.hut.fi/ssh/
From owner-ietf-ssh@clinet.fi  Thu Nov 13 17:05:17 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.8/8.8.8/EPIPE-1.10) with ESMTP id RAA09574;
	Thu, 13 Nov 1997 17:05:10 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.8/8.8.8/EPIPE-1.12) with ESMTP id RAA06293;
	Thu, 13 Nov 1997 17:05:09 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id MAA27966
	for ietf-ssh-outgoing; Thu, 13 Nov 1997 12:50:03 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.7])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id MAA27953
	for <ietf-ssh@clinet.fi>; Thu, 13 Nov 1997 12:49:57 +0200 (EET)
Received: from shadows.cs.hut.fi (shadows [130.233.192.99]) by hutcs.cs.hut.fi (8.8.5/8.7.3) with ESMTP id MAA16830; Thu, 13 Nov 1997 12:49:49 +0200 (EET)
Received: (from kivinen@localhost) by shadows.cs.hut.fi (8.7.6/8.7.3) id MAA07870; Thu, 13 Nov 1997 12:50:50 +0200 (EET)
Date: Thu, 13 Nov 1997 12:50:50 +0200 (EET)
Message-Id: <199711131050.MAA07870@shadows.cs.hut.fi>
From: Tero Kivinen <kivinen@niksula.hut.fi>
To: Tatu Ylonen <ylo@ssh.fi>
Cc: rja@corp.home.net (Ran Atkinson), ietf-ssh@clinet.fi
Subject: Comments on the new secsh drafts (03)
In-Reply-To: <199711121813.UAA28341@pilari.ssh.fi>
References: <Pine.NEB.3.95q.971107101321.15257G-100000@pilari.ssh.fi>
	<mjos@ssh.fi>
	<971107094451.ZM10864@borg.eos.home.net>
	<199711111006.MAA00069@shadows.cs.hut.fi>
	<199711121813.UAA28341@pilari.ssh.fi>
Organization: Helsinki University of Technology
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-Edit-Time: 6 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 904
Lines: 19

Tatu Ylonen writes:
> Please note that some people might want to forward an external port to
> inside a protected network.  In this case, the internal domain name
> might not be visible outside the internal network, and the external
> machine cannot resolve the name to an ip address.  If this scenario is
> to be supported, it must support passing domain names.

No, we are not talking about the `host to connect', that can already
be either ip-number or dns name. 

> When giving the address of the client that connected to a forwarded
> port, IP address only sounds fine; it reduces complexity and doesn't
> open room for new security problems (as far as I can see).

We have only been talking about the `originator IP address' field,
where only ip-address is allowed. 
-- 
kivinen@iki.fi		              	     Work : +358-9-451 4032
Magnus Enckellin kuja 9 K 19, 02610, Espoo   Home : +358-9-502 1573
From owner-ietf-ssh@clinet.fi  Thu Nov 13 17:55:44 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.8/8.8.8/EPIPE-1.10) with ESMTP id RAA09947;
	Thu, 13 Nov 1997 17:55:43 +0200 (EET)
Received: from hauki.clinet.fi (majordom@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.8/8.8.8/EPIPE-1.12) with ESMTP id RAA06478;
	Thu, 13 Nov 1997 17:55:42 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id RAA02232
	for ietf-ssh-outgoing; Thu, 13 Nov 1997 17:52:05 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ssh.fi (ssh.fi [194.100.44.97])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id RAA02219
	for <ietf-ssh@clinet.fi>; Thu, 13 Nov 1997 17:51:59 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by ssh.fi (8.8.8/8.8.8/EPIPE-1.12) with ESMTP id RAA06454
	for <ietf-ssh@clinet.fi>; Thu, 13 Nov 1997 17:51:58 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by pilari.ssh.fi (8.8.8/8.8.8/EPIPE-1.10) with SMTP id RAA09919
	for <ietf-ssh@clinet.fi>; Thu, 13 Nov 1997 17:51:56 +0200 (EET)
Date: Thu, 13 Nov 1997 17:51:56 +0200 (EET)
From: Markku-Juhani Saarinen <mjos@ssh.fi>
To: ietf-ssh@clinet.fi
Subject: Re: Comments on the new secsh drafts (03)
In-Reply-To: <199711131050.MAA07870@shadows.cs.hut.fi>
Message-ID: <Pine.NEB.3.95q.971113174918.9909A-100000@pilari.ssh.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1583
Lines: 42


I'll try to clarify this.

We take "network address" and "host name" to mean different things.
  
1) network address = IPv4 or IPv6 network address (e.g. 193.166.88.113)
2) host name       = a fully qualified domain name (e.g. kalahari.s2.org)

The section 4.1. (Encoding of Network Addresses) in the architecture
document tries to emphasize this distinction. 

In pg. 13 of connection protocol document:

 "`Host to connect' and `port to connect' specify the TCP/IP host and port
  where the recipient should connect the channel.  `Host to connect' may
  be either a domain name or a numeric IP address."

.. so we can connect hosts using a host name.

- mj

Markku-Juhani O. Saarinen <mjos@ssh.fi>, SSH Communications Security Ltd

On Thu, 13 Nov 1997, Tero Kivinen wrote:

> Tatu Ylonen writes:
> > Please note that some people might want to forward an external port to
> > inside a protected network.  In this case, the internal domain name
> > might not be visible outside the internal network, and the external
> > machine cannot resolve the name to an ip address.  If this scenario is
> > to be supported, it must support passing domain names.
> 
> No, we are not talking about the `host to connect', that can already
> be either ip-number or dns name. 
> 
> > When giving the address of the client that connected to a forwarded
> > port, IP address only sounds fine; it reduces complexity and doesn't
> > open room for new security problems (as far as I can see).
> 
> We have only been talking about the `originator IP address' field,
> where only ip-address is allowed. 

From owner-ietf-ssh@clinet.fi  Thu Nov 13 21:12:05 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.8/8.8.8/EPIPE-1.10) with ESMTP id VAA12989;
	Thu, 13 Nov 1997 21:12:05 +0200 (EET)
Received: from hauki.clinet.fi (majordom@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.8/8.8.8/EPIPE-1.12) with ESMTP id VAA07297;
	Thu, 13 Nov 1997 21:12:04 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id VAA22502
	for ietf-ssh-outgoing; Thu, 13 Nov 1997 21:03:30 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id VAA22460
	for <ietf-ssh@clinet.fi>; Thu, 13 Nov 1997 21:02:57 +0200 (EET)
Received: from eleanor.innosoft.com ("port 57257"@ELEANOR.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-10 #8694)
 with SMTP id <01IPYJ03T8HM9LUYDI@INNOSOFT.COM> for ietf-ssh@clinet.fi; Thu,
 13 Nov 1997 11:02:16 PST
Date: Thu, 13 Nov 1997 11:04:28 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: New secsh drafts (03) are out.
In-reply-to: <Pine.NEB.3.95q.971107101321.15257G-100000@pilari.ssh.fi>
To: Markku-Juhani Saarinen <mjos@ssh.fi>
Cc: ietf-ssh@clinet.fi
Message-id: <Pine.SOL.3.95.971113095333.12479E-100000@eleanor.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 7226
Lines: 193

On Fri, 7 Nov 1997, Markku-Juhani Saarinen wrote:
>          value (hex)        representation (hex)
>          ---------------------------------------------------------------
>          0                  00 00 00 00
>          9a378f9b2e332a7    00 00 00 08 09 a3 78 f9 b2 e3 32 a7
>          80                 00 00 00 02 00 80
>          -1234              00 00 00 02 ed cc
>          -deadbeef          00 00 00 05 ff 21 52 41 11                   "

Good examples!  Thanks.

The only remaining issue I have with the architecture document is that it
should describe the port/X11 forwarding model (or that should be described
in the connection spec -- I don't care where).

>    Network addresses are encoded as strings. DNS names MUST NOT be used, as
>    DNS is an insecure protocol.

I concur with opinions that DNS names need to be permitted.

Otherwise I like the connect spec.

The only issue I have with the userauth spec is it would be nice if it
used the RFC 2222 authentication framework so that authentication
mechanisms only have to be designed once to be usable in many protocols.
The basic effect of this on the userauth spec would be to simply wrap most
of the SSH_MSG_USERAUTH_REQUEST packets into a single string (with the
exception of the mechanism name).  The drawback would be adding 4 extra
bytes to the packets and making the spec a bit more complex.  The
advantage would be that the authentication mechanisms defined in the
userauth spec could be used by IMAP, POP3, LDAP, ACAP, SMTP and NNTP.  In
addition, it would be able to use the mechanisms defined in RFC 2222
(kerberos v4, S/key, GSSAPI, external) and 2195 (CRAM-MD5) and any future
such mechanisms.  What do you think?

Some detailed suggestions for the connection protocol follow -- these are
specific suggestions on how I would go about generalizing the protocol to
be useful on non-unix systems:

>4.2.  Requesting a Pseudo-Terminal
>
>A pseudo-terminal can be allocated for the session by sending the
>following message.

I'd call this "associating an interactive terminal handler with the
channel (equivalent to a Unix pseudo-terminal)"

>  byte      SSH_MSG_CHANNEL_REQUEST
>  uint32    recipient_channel
>  string    "pty-req"
             ^^^^^^^^^
             "term-handler-req"
>  boolean   want_reply
>  string    TERM environment variable value (e.g., vt100)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
             terminal type name (e.g., vt100)
>  uint32    terminal width, characters (e.g., 80)
>  uint32    terminal height, rows (e.g., 24)
>  uint32    terminal width, pixels (e.g., 480)
>  uint32    terminal height, pixels (e.g., 640)
>  string    encoded terminal modes
> ...
>4.3.1.  Requesting X11 Forwarding
>
>X11 forwarding may be requested for a session by sending

The model for this needs to be described somewhere.  This also needs a
reference to the X11 protocol specification.

>4.5.  Environment Variable Passing
>
>Environment variables may be passed to the shell/command to be started
>later.  Typically, each machine will have a preconfigured set of
>variables that it will allow.  Since uncontrolled setting of environment
>variables can be very dangerous, it is recommended that implementations
>allow setting only variables whose names have been explicitly configured
>to be allowed.

I notice this only allows one variable per packet.  Does the client have
to send multiple variables?  Can you include a list of example environment
variables a client might wish to set?

> This message will request the user's default shell (typically defined in
> /etc/passwd in UNIX systems) to be started at the other end.

This message will request that the user's default interactive command
processor (known as a shell on UNIX systems and specified in /etc/passwd)
be started at the other end.

> This message will request the server to start the execution of the given
> command. The command string may contain a path. Normal precautions MUST
> be taken to prevent the execution of unauthorized commands.

Is this evaluated in the context of the user's default command processor?
I think the answer is yes, but it should be explicit.

>  byte      SSH_MSG_CHANNEL_REQUEST
>  uint32    recipient channel
>  string    "subsystem"
>  boolean   want reply
>  string    subsystem name
>
>This last form executes a predefined subsystem.  It expected that these
>will include a general file transfer mechanism, and possibly other
>features.  Implementations may also allow configuring more such
>mechanisms.

I still don't understand why this is useful.  Couldn't you just add:
  byte      SSH_MSG_CHANNEL_REQUEST
  uint32    recipient channel
  string    "get-file"
  boolean   want reply
  string    file name
When you decide to add a file transfer mechanism?  The "subsystem" seems
like an unnecessary level of indirection.  If you leave it in, there
should be a way to determine available subsystems, just as there should be
a way to determine available SSH_MSG_CHANNEL_REQUEST types (for
extensibility).

>The server SHOULD not halt the execution of the protocol stack when
>starting a shell or a program. All input and output from these SHOULD be
>redirected the the channel or to the encrypted tunnel.
>
>It is RECOMMENDED to request and check the reply for these messages. The
>client SHOULD ignore these messages.

I'd suspect that most implementations would only allow one of these per
channel.  Or does an EOF allow a new one to be started?

>4.10.  Signals
>
>A signal can be delivered to the remote process/service using the
>following message.  Some systems may not implement signals, in which
>case they SHOULD ignore this message.
>
>  byte      SSH_MSG_CHANNEL_REQUEST
>  uint32    recipient channel
>  string    "signal"
>  boolean   FALSE
>  uint32    signal number

You need to list the basic set of signal numbers or reference a definition
(e.g., Posix).  Giving fixed values for TERM (soft abort) and KILL (hard
abort) would be useful for cross-platform interoperability.

>4.11.  Returning Exit Status

I think these can be greatly simplified.

>  byte      SSH_MSG_CHANNEL_REQUEST
>  uint32    recipient_channel
>  string    "exit-status"
>  boolean   FALSE
>  uint32    exit_status
> ...
>  byte      SSH_MSG_CHANNEL_REQUEST
>  uint32    recipient channel
>  string    "exit-signal"
>  boolean   FALSE
>  uint32    signal number
>  boolean   core dumped
>  string    error message (ISO-10646 UTF-8 [[RFC-2044]])
>  string    language tag (as defined in [[RFC-1766]])

I suggest instead:

  byte      SSH_MSG_CHANNEL_REQUEST
  uint32    recipient_channel
  string    "exit"
  boolean   FALSE
  uint32    generic_exit
  uint32    specific_exit_type
  uint32    specific_exit_value
  boolean   core or process image saved
  string    language tag
  string    error message

generic_exit would be:
  0 - successful normal exit
  1 - failure normal exit
  2 - user abort
  3 - system abort
specific_exit_type would be:
  0 - exit_value = unix process result (0 - 255)
  1 - exit_value = unix signal number (0 - ?)

Thus you'd have a single message for exits that's more extensible and also
permits non-unix systems.  The error message would be empty on normal
exit.

		- Chris


