From owner-ietf-ssh@clinet.fi  Tue Oct 14 18:58:43 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 SAA19485;
	Tue, 14 Oct 1997 18:58:43 +0300 (EET DST)
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 SAA09170;
	Tue, 14 Oct 1997 18:58:42 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id RAA08714
	for ietf-ssh-outgoing; Tue, 14 Oct 1997 17:27:28 +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.6/8.8.6) with ESMTP id RAA08706
	for <ietf-ssh@clinet.fi>; Tue, 14 Oct 1997 17:27:23 +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 SAA09022;
	Tue, 14 Oct 1997 18:26:44 +0300 (EET DST)
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 SAA17257;
	Tue, 14 Oct 1997 18:26:42 +0300 (EET DST)
Date: Tue, 14 Oct 1997 18:26:41 +0300 (EET DST)
From: Markku-Juhani Saarinen <mjos@ssh.fi>
To: ietf-ssh@clinet.fi
cc: staff@ssh.fi
Subject: new Secure Shell drafts
Message-ID: <Pine.NEB.3.95q.971014180544.13670F-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: 1455
Lines: 42

Hi, 

  New Secure Shell drafts are now available from http://www.ssh.fi/drafts
  and have been submitted to internet-drafts@ietf.org.

  (These are not full abstracts)

  draft-ietf-secsh-architecture-00.txt  (new !)

    This document describes the architecture of the SSH 2 protocol, and
    the notation and terminology used in SSH 2 protocol documents. 

  draft-ietf-secsh-transport-02.txt

    This document describes the SSH 2 transport layer protocol. The
    protocol can be used as a basis for a number of secure network
    services. It provides strong encryption, server authentication, and
    integrity protection. 

  draft-ietf-secsh-connect-02.txt

    This document describes the SSH 2 client authentication protocol
    framework and some commonly used authentication methods. Additional
    authentication methods are deferred to separate documents. 

  draft-ietf-secsh-userauth-02.txt

    This document describes the SSH 2 connection protocol. It can be used
    to multiplex a number of channels (e.g. interactive sessions,
    forwarded TCP/IP ports, X11 connections, etc) into a single encrypted
    tunnel. It is intended to be ran on top the SSH 2 User Authentication
    Protocol. 

  These documents have changed significantly.

  Any correspondence (of typo / bug report sort) regarding these drafts
  can be directed to me at mjos@ssh.fi. 

- mj 

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

From owner-ietf-ssh@clinet.fi  Wed Oct 15 16:56:50 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 QAA29879;
	Wed, 15 Oct 1997 16:56:47 +0300 (EET DST)
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 QAA12635;
	Wed, 15 Oct 1997 16:56:45 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id PAA10073
	for ietf-ssh-outgoing; Wed, 15 Oct 1997 15:50:39 +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.6/8.8.6) with ESMTP id PAA10003
	for <ietf-ssh@clinet.fi>; Wed, 15 Oct 1997 15:49: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 JAA27825;
	Wed, 15 Oct 1997 09:49:12 -0400 (EDT)
Message-Id: <199710151349.JAA27825@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-00.txt
Date: Wed, 15 Oct 1997 09:49:10 -0400
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3062
Lines: 95

--NextPart

A New 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-00.txt
	Pages		: 11
	Date		: 14-Oct-97
	
SSH is a protocol for secure remote login and other secure network ser-
vices 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-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-architecture-00.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-00.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:	<19971014144626.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Wed Oct 15 16:56: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 QAA29904;
	Wed, 15 Oct 1997 16:56:52 +0300 (EET DST)
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 QAA12643;
	Wed, 15 Oct 1997 16:56:51 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id PAA10055
	for ietf-ssh-outgoing; Wed, 15 Oct 1997 15:50:29 +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.6/8.8.6) with ESMTP id PAA10002
	for <ietf-ssh@clinet.fi>; Wed, 15 Oct 1997 15:49: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 JAA27828;
	Wed, 15 Oct 1997 09:49:12 -0400 (EDT)
Message-Id: <199710151349.JAA27828@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-02.txt
Date: Wed, 15 Oct 1997 09:49:12 -0400
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3052
Lines: 97

--NextPart

A New 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-02.txt
	Pages		: 20
	Date		: 14-Oct-97
	
SSH is a protocol for secure remote login and other secure network ser-
vices 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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-transport-02.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-02.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:	<19971014144821.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Wed Oct 15 16:56:49 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 QAA29877;
	Wed, 15 Oct 1997 16:56:45 +0300 (EET DST)
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 QAA12631;
	Wed, 15 Oct 1997 16:56:44 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id PAA10069
	for ietf-ssh-outgoing; Wed, 15 Oct 1997 15:50:36 +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.6/8.8.6) with ESMTP id PAA10036
	for <ietf-ssh@clinet.fi>; Wed, 15 Oct 1997 15:50: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 JAA27845;
	Wed, 15 Oct 1997 09:49:15 -0400 (EDT)
Message-Id: <199710151349.JAA27845@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-02.txt
Date: Wed, 15 Oct 1997 09:49:14 -0400
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2805
Lines: 91

--NextPart

A New 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-02.txt
	Pages		: 11
	Date		: 14-Oct-97
	
SSH is a protocol for secure remote login and other secure network ser-
vices 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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-userauth-02.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-02.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:	<19971014145407.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Wed Oct 15 16:56:49 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 QAA29881;
	Wed, 15 Oct 1997 16:56:49 +0300 (EET DST)
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 QAA12637;
	Wed, 15 Oct 1997 16:56:47 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id PAA10040
	for ietf-ssh-outgoing; Wed, 15 Oct 1997 15:50:16 +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.6/8.8.6) with ESMTP id PAA09998
	for <ietf-ssh@clinet.fi>; Wed, 15 Oct 1997 15:49:50 +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 JAA27856;
	Wed, 15 Oct 1997 09:49:17 -0400 (EDT)
Message-Id: <199710151349.JAA27856@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-02.txt
Date: Wed, 15 Oct 1997 09:49:16 -0400
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2810
Lines: 91

--NextPart

A New 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-02.txt
	Pages		: 16
	Date		: 14-Oct-97
	
SSH is a protocol for secure remote login and other secure network ser-
vices 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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-connect-02.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-02.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:	<19971014145834.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Mon Oct 27 05:57:03 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 FAA27985;
	Mon, 27 Oct 1997 05:57:02 +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 FAA26101;
	Mon, 27 Oct 1997 05:57:01 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id EAA12119
	for ietf-ssh-outgoing; Mon, 27 Oct 1997 04:17:53 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id EAA12087
	for <ietf-ssh@clinet.fi>; Mon, 27 Oct 1997 04:17:44 +0200 (EET)
Received: from gold-1.transmeta.com (mailhost.transmeta.com [10.1.1.79])
          by neon.transmeta.com (8.8.5/8.8.4) with ESMTP
	  id SAA25471; Sun, 26 Oct 1997 18:05:48 -0800
Received: from blighty.transmeta.com (morgan@blighty.transmeta.com [10.1.27.37])
	by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id SAA16574;
	Sun, 26 Oct 1997 18:09:55 -0800 (PST)
From: Andrew Morgan <morgan@transmeta.com>
Received: (from morgan@localhost) by blighty.transmeta.com (8.8.5/8.7.3) id SAA13266; Sun, 26 Oct 1997 18:09:54 -0800
Message-Id: <199710270209.SAA13266@blighty.transmeta.com>
Subject: beginnings of a real PAM patch
To: ietf-ssh@clinet.fi
Date: Sun, 26 Oct 1997 18:09:54 -0800 (PST)
Cc: pam-list@redhat.com (Linux-PAM)
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM877918194-12976-0_
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 22224
Lines: 704


--ELM877918194-12976-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I'm the guy that's maintaining the Linux-PAM source distribution and
it has been a running sore not having a PAM patch for ssh(d).  There
is a patch in existence that provides some access to PAM for simple
password based authentication (this is distributed with the ssh rpms
on www.replay.com).  I'd like to get things going on a better patch
that better includes support for PAM within the ssh main sources.

I've attached a patch that should apply to recent releases of the ssh
source tree and provides some client and server modifications that
establish a new "PAM" authentication mode.  I'm hoping that someone
with some time and a better understanding of "configure" will help
make the patch work! :^)

It may also give people that know about ssh, but not PAM, a better
idea of what PAM can offer and initiate some discussion of whether PAM
should be adopted as an "official" authentication scheme.

Cheers

Andrew
-- 
The latest Linux-PAM source code is available from:

	http://linux.kernel.org/pub/linux/libs/pam/pre/

--ELM877918194-12976-0_
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: attachment; filename=ssh-1.2.20-pam.patch
Content-Description: /home/morgan/misc/ssh-1.2.20-pam.patch
Content-Transfer-Encoding: 7bit

diff -urN ssh-1.2.20/README.PAM ssh-1.2.20-PAM/README.PAM
--- ssh-1.2.20/README.PAM	Wed Dec 31 16:00:00 1969
+++ ssh-1.2.20-PAM/README.PAM	Sun Sep 28 22:02:36 1997
@@ -0,0 +1,16 @@
+Notes on the integration of PAM authentication into ssh
+
+PAM represents a generic method for authentication and is dynamically
+configurable by the local system administrator.  PAM is the default
+authentication method for both Red Hat Linux and Caldera Open Linux.
+It is also supported by Solaris 2.6 and will likely appear in future
+versions of other UNIXes.
+
+This implementation of PAM requires Linux-PAM 0.59 or better.  It is
+untested against any other implementation of PAM, although it should
+compile against Solaris too.
+
+Your milage may vary...
+
+Andrew G. Morgan <morgan@transmeta.com>
+
diff -urN ssh-1.2.20/acconfig.h ssh-1.2.20-PAM/acconfig.h
--- ssh-1.2.20/acconfig.h	Tue Apr 22 17:40:06 1997
+++ ssh-1.2.20-PAM/acconfig.h	Sun Sep 28 22:42:55 1997
@@ -226,6 +226,9 @@
 /* If defines, this overrides "tty" as the terminal group. */
 #undef TTY_GROUP
 
+/* Define for PAM support */
+#undef HAVE_PAM
+
 /* Define this if you want to support Security Dynammics SecurID
    cards. */
 #undef HAVE_SECURID
diff -urN ssh-1.2.20/configure.in ssh-1.2.20-PAM/configure.in
--- ssh-1.2.20/configure.in	Tue Apr 22 17:40:06 1997
+++ ssh-1.2.20-PAM/configure.in	Sun Sep 28 21:56:46 1997
@@ -661,6 +661,11 @@
 AC_CHECK_SIZEOF(int,4)
 AC_CHECK_SIZEOF(short,2)
 
+if test -f /usr/include/security/pam_appl.h; then
+  AC_DEFINE(HAVE_PAM)
+  LIBS="$LIBS -lpam -ldl"
+fi
+
 if test -z "$no_termios"; then
   AC_CHECK_HEADERS(termios.h)
 fi
diff -urN ssh-1.2.20/log-server.c ssh-1.2.20-PAM/log-server.c
--- ssh-1.2.20/log-server.c	Tue Apr 22 17:40:08 1997
+++ ssh-1.2.20-PAM/log-server.c	Sun Sep 28 21:56:46 1997
@@ -292,6 +292,12 @@
   char buf[1024];
   va_list args;
 
+#ifdef HAVE_PAM
+  if (pamh) {
+      pam_end(pamh, PAM_ABORT);
+      pamh = NULL;
+  }
+#endif /* HAVE_PAM */
   if (log_quiet)
     exit(1);
   va_start(args, fmt);
@@ -311,6 +317,12 @@
   char buf[1024];
   va_list args;
 
+#ifdef HAVE_PAM
+  if (pamh) {
+      pam_end(pamh, PAM_ABORT);
+      pamh = NULL;
+  }
+#endif /* HAVE_PAM */
   if (log_quiet)
     exit(1);
   va_start(args, fmt);
diff -urN ssh-1.2.20/readconf.c ssh-1.2.20-PAM/readconf.c
--- ssh-1.2.20/readconf.c	Tue Apr 22 17:40:11 1997
+++ ssh-1.2.20-PAM/readconf.c	Sun Sep 28 22:17:12 1997
@@ -145,7 +145,8 @@
   oGlobalKnownHostsFile, oUserKnownHostsFile, oConnectionAttempts,
   oBatchMode, oStrictHostKeyChecking, oCompression, oCompressionLevel,
   oKeepAlives, oUsePriviledgedPort, oKerberosAuthentication,
-  oKerberosTgtPassing, oClearAllForwardings, oNumberOfPasswordPrompts
+  oKerberosTgtPassing, oClearAllForwardings, oNumberOfPasswordPrompts,
+  oPAMAuthentication
 } OpCodes;
 
 /* Textual representations of the tokens. */
@@ -188,6 +189,7 @@
   { "kerberostgtpassing", oKerberosTgtPassing },
   { "clearallforwardings", oClearAllForwardings },
   { "numberofpasswordprompts", oNumberOfPasswordPrompts },
+  { "pamauthentication", oPAMAuthentication },
   { NULL, 0 }
 };
 
@@ -301,6 +303,10 @@
       intptr = &options->password_authentication;
       goto parse_flag;
       
+    case oPAMAuthentication:
+      intptr = &options->pam_authentication;
+      goto parse_flag;
+      
     case oRSAAuthentication:
       intptr = &options->rsa_authentication;
       goto parse_flag;
@@ -621,6 +627,7 @@
   options->kerberos_tgt_passing = -1;
   options->tis_authentication = -1;
   options->password_authentication = -1;
+  options->pam_authentication = -1;
   options->rhosts_rsa_authentication = -1;
   options->fallback_to_rsh = -1;
   options->use_rsh = -1;
diff -urN ssh-1.2.20/readconf.h ssh-1.2.20-PAM/readconf.h
--- ssh-1.2.20/readconf.h	Tue Apr 22 17:40:15 1997
+++ ssh-1.2.20-PAM/readconf.h	Sun Sep 28 21:56:46 1997
@@ -73,6 +73,7 @@
   int kerberos_authentication;	/* Try Kerberos authentication. */
   int kerberos_tgt_passing;	/* Try Kerberos tgt passing. */
   int tis_authentication;	/* Try TIS authsrv authentication. */
+    int pam_authentication;     /* Try PAM authentication */
   int password_authentication;	/* Try password authentication. */
   int fallback_to_rsh;		/* Use rsh if cannot connect with ssh. */
   int use_rsh;			/* Always use rsh (don\'t try ssh). */
diff -urN ssh-1.2.20/readpass.c ssh-1.2.20-PAM/readpass.c
--- ssh-1.2.20/readpass.c	Tue Apr 22 17:40:13 1997
+++ ssh-1.2.20-PAM/readpass.c	Sun Sep 28 21:56:46 1997
@@ -73,6 +73,61 @@
   kill(getpid(), sig);
 }
 
+#ifdef HAVE_PAM
+/* Read a prompted string with echo turned _on_ from tty or stdin */
+
+char *read_visible(uid_t uid, const char *prompt, int from_stdin)
+{
+    char buf[1000], *cp;
+    FILE *f;
+
+    if (from_stdin) {
+	f = stdin;
+    } else {
+	f = fopen("/dev/tty", "r");
+	if (f == NULL) {
+	    fatal("No terminal available for input.");
+	}
+    }
+
+    /* this is a quick hack. we should do something a little more
+       like the code in read_passphrase */
+    i = strlen(prompt);
+    i = (i>=sizeof(buf)) ? sizeof(buf)-1:i ;
+    buf[i] = '\0';
+    while (i-->0) {
+	if (isprint(prompt[i]) || isspace(prompt[i]))
+	    buf[i] = prompt[i];
+	else
+	    buf[i] = '?';
+    }
+
+    /* display prompt */
+    fflush(stdout);
+    fprintf(stderr, "%s", buf);
+    fflush(stderr);
+
+    /* read input */
+    if (fgets(buf, sizeof(buf), f) == NULL) {
+	fatal("Aborted.");
+    }
+
+    /* remove trailing newline */
+    if (strchr(buf, '\n'))
+	*strchr(buf, '\n') = 0;
+
+    /* Allocate a copy of the passphrase. */
+    cp = xstrdup(buf);
+
+    /* clean up */
+    memset(buf, 0, sizeof(buf));
+    if (f != stdin)
+	fclose(f);
+
+    return cp;
+}
+#endif /* HAVE_PAM */
+
 /* Reads a passphrase from /dev/tty with echo turned off.  Returns the 
    passphrase (allocated with xmalloc).  Exits if EOF is encountered. 
    The passphrase if read from stdin if from_stdin is true (as is the
diff -urN ssh-1.2.20/servconf.c ssh-1.2.20-PAM/servconf.c
--- ssh-1.2.20/servconf.c	Tue Apr 22 17:40:08 1997
+++ ssh-1.2.20-PAM/servconf.c	Sun Sep 28 22:20:17 1997
@@ -88,6 +88,7 @@
   options->tis_authentication = -1;
   options->allow_tcp_forwarding = -1;
   options->password_authentication = -1;
+  options->pam_authentication = -1;
   options->permit_empty_passwd = -1;
   options->use_login = -1;
   options->silent_deny = -1;
@@ -169,6 +170,8 @@
     options->tis_authentication = 0;
   if (options->password_authentication == -1)
     options->password_authentication = 1;
+  if (options->pam_authentication == -1)
+    options->pam_authentication = 1;
   if (options->permit_empty_passwd == -1)
     options->permit_empty_passwd = 1;
   if (options->use_login == -1)
@@ -194,7 +197,7 @@
   sStrictModes, sEmptyPasswd, sRandomSeedFile, sKeepAlives, sPidFile,
   sForcedPasswd, sUmask, sSilentDeny, sIdleTimeout, sUseLogin,
   sKerberosAuthentication, sKerberosOrLocalPasswd, sKerberosTgtPassing,
-  sAllowTcpForwarding
+  sAllowTcpForwarding, sPAMAuthentication
 } ServerOpCodes;
 
 /* Textual representation of the tokens. */
@@ -239,6 +242,7 @@
   { "kerberosorlocalpasswd", sKerberosOrLocalPasswd },
   { "kerberostgtpassing", sKerberosTgtPassing },
   { "allowtcpforwarding", sAllowTcpForwarding },
+  { "pamauthentication", sPAMAuthentication },
   { NULL, 0 }
 };
 
@@ -498,6 +502,10 @@
 	  goto parse_flag;
 	  
 	case sPasswordAuthentication:
+	  intptr = &options->password_authentication;
+	  goto parse_flag;
+
+	case sPAMAuthentication:
 	  intptr = &options->password_authentication;
 	  goto parse_flag;
 
diff -urN ssh-1.2.20/servconf.h ssh-1.2.20-PAM/servconf.h
--- ssh-1.2.20/servconf.h	Tue Apr 22 17:40:16 1997
+++ ssh-1.2.20-PAM/servconf.h	Sun Sep 28 22:21:15 1997
@@ -78,6 +78,7 @@
   int kerberos_tgt_passing;	/* If true, permit Kerberos tgt passing. */
   int allow_tcp_forwarding;
   int tis_authentication;	/* If true, permit TIS authsrv auth. */
+    int pam_authentication;       /* if true, permit PAM authentication */
   int password_authentication;  /* If true, permit password authentication. */
   int permit_empty_passwd;      /* If false, do not permit empty passwords. */
   int use_login;		/* Use /bin/login if possible */
diff -urN ssh-1.2.20/ssh.h ssh-1.2.20-PAM/ssh.h
--- ssh-1.2.20/ssh.h	Tue Apr 22 17:40:16 1997
+++ ssh-1.2.20-PAM/ssh.h	Sun Sep 28 21:56:46 1997
@@ -302,6 +302,9 @@
 #define SSH_AUTH_RESERVED_7	14
 #define SSH_AUTH_RESERVED_8	15
 
+/* This is for testing now.  I hope this patch becomes "official" - AGM */
+#define SSH_AUTH_PAM            SSH_AUTH_RESERVED_1
+
 /* If you add new methods add them after this using random number between 16-31
    so if someone else adds also new methods you dont use same number. */
 
@@ -379,6 +382,19 @@
    use some random number between 64-127 so if someone else adds something else
    you dont use same numbers */
 
+/* PAM extensions - for interactive server-client authentication */
+
+#define SSH_CMSG_AUTH_PAM_RESERVED              90
+#define SSH_CMSG_AUTH_PAM_START                 91
+#define SSH_CMSG_AUTH_PAM_CONTINUE              92
+#define SSH_CMSG_AUTH_PAM_INPUT                 93
+#define SSH_SMSG_PAM_TEXT_INFO                  94
+#define SSH_SMSG_PAM_ERROR_MSG                  95
+#define SSH_SMSG_PAM_PROMPT_ECHO_ON             96
+#define SSH_SMSG_PAM_PROMPT_ECHO_OFF            97
+#define SSH_SMSG_PAM_BINARY_PROMPT              98
+#define SSH_SMSG_PAM_BINARY_REQUEST             99
+#define SSH_SMSG_PAM_RESERVED                  100
 
 /* define this and debug() will print local hostname */
 #define LOCAL_HOSTNAME_IN_DEBUG 1
@@ -518,6 +534,19 @@
    If this needs to use an auxiliary program to read the passphrase,
    this will run it with the given uid using userfile. */
 char *read_passphrase(uid_t uid, const char *prompt, int from_stdin);
+
+#ifdef HAVE_PAM
+#include <security/pam_appl.h>
+
+/* Reads input from /dev/tty or stdin with echo turned on. Returns the
+   user input (allocated with xmalloc).  Exits (fatal) if EOF is read.
+   If from_stdin is true, the input will be read from stdin instead.
+   If no input file is available, it will terminate the program with
+   fatal.  Note, at this time there is no X-input method */
+char *read_visible(uid_t uid, const char *prompt, int from_stdin);
+
+extern pam_handle_t *pamh;
+#endif /* HAVE_PAM */
 
 /* Reads a yes/no confirmation from /dev/tty.  Exits if EOF or "no" is
    encountered. */
diff -urN ssh-1.2.20/sshconnect.c ssh-1.2.20-PAM/sshconnect.c
--- ssh-1.2.20/sshconnect.c	Tue Apr 22 17:40:11 1997
+++ ssh-1.2.20-PAM/sshconnect.c	Sun Sep 28 21:56:46 1997
@@ -1600,6 +1600,69 @@
     packet_disconnect("Protocol error: got %d in response to SSH_CMSG_USER",
 		      type);
 
+#ifdef HAVE_PAM
+  if ((supported_authentications & (1 << SSH_AUTH_PAM))
+      && options->pam_authentication && !options->batch_mode) {
+      debug("Doing PAM negotiation");
+
+      /* initialize PAM from this end: indicate PAM_USER and PAM_RUSER */
+      packet_start(SSH_CMSG_AUTH_PAM_START);
+      packet_put_string(local_user, strlen(local_user));
+      packet_send();
+      packet_write_wait();
+
+      /* we loop now until the server is satisfied. */
+      while ((type = packet_read())) {
+	  switch (type) {
+	      char *text_info, *input=NULL;
+
+	  case SSH_SMSG_SUCCESS:
+	      return;  /* authentication has been accepted */
+	  case SSH_SMSG_FAILURE:
+	      fatal("Permission denied.");  /* we do not permit any
+					       other method to be
+					       attempted. */
+	  case SSH_SMSG_PAM_TEXT_INFO:
+	  case SSH_SMSG_PAM_ERROR_MSG:
+	      text_info = packet_get_string(NULL);
+	      error(text_info);
+	      xfree(text_info);
+	      /* indicate that it printed */
+	      packet_start(SSH_CMSG_AUTH_PAM_CONTINUE);
+	      break;
+	  case SSH_SMSG_PAM_PROMPT_ECHO_ON:
+	      text_info = packet_get_string(NULL);
+	      input = read_visible(pw->pw_uid, text_info, 0);
+	      xfree(text_info);
+	      /* return prompted-for and echoed text */
+	      packet_start(SSH_CMSG_AUTH_PAM_INPUT);
+	      packet_put_string(input, strlen(input));
+	      memset(input, 0, strlen(input));
+	      xfree(input);
+	      input = NULL;
+	      break;
+	  case SSH_SMSG_PAM_PROMPT_ECHO_OFF:
+	      text_info = packet_get_string(NULL);
+	      input = read_passphrase(pw->pw_uid, text_info, 0);
+	      xfree(text_info);
+	      /* return prompted-for but unechoed text */
+	      packet_start(SSH_CMSG_AUTH_PAM_INPUT);
+	      packet_put_string(input, strlen(input));
+	      memset(input, 0, strlen(input));
+	      xfree(input);
+	      input = NULL;
+	      break;
+	  default:
+	      packet_disconnect("Protocol error: got %d in response"
+				" to PAM auth request", type);
+	  }
+	  /* send response packet */
+	  packet_send();
+	  packet_write_wait();
+      }
+  }
+#endif /* HAVE_PAM */
+
 #ifdef KERBEROS_TGT_PASSING
   /* Try Kerberos tgt passing if the server supports it. */
   if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) &&
diff -urN ssh-1.2.20/sshd.c ssh-1.2.20-PAM/sshd.c
--- ssh-1.2.20/sshd.c	Tue Apr 22 17:40:08 1997
+++ ssh-1.2.20-PAM/sshd.c	Sun Sep 28 21:56:46 1997
@@ -505,6 +505,107 @@
    the private key. */
 RSAPublicKey public_key;
 
+#ifdef HAVE_PAM
+
+/* XXX - we should intercept the timeout alarm.. if the alarm is
+   triggered we need to return PAM_CONV_ERR and then let the
+   do_authentication loop handle the problem.
+
+   XXX - we have currently made no attempt to integrate the pam_*env*
+   calls with the environment usage of this program.  This needs
+   fixing since a number of modules use environment variables! */
+
+/* because of the way the client currently handles PAM requests, we can
+   only use the conversation mechanism during authentication */
+
+static int not_authenticating=1;
+
+static int pam_ssh_conv(int nmsg, const struct pam_message **msg,
+			struct pam_response **resp, void *app_data)
+{
+    struct pam_response *reply;
+    int i, type;
+
+    if (not_authenticating || nmsg < 1 || resp == NULL) {
+	return PAM_CONV_ERR;
+    }
+
+    reply = calloc(nmsg, sizeof(struct pam_response));
+    if (reply == NULL) {
+	return PAM_CONV_ERR;
+    }
+
+    /* loop through all of the messages */
+    for (i=0; i<nmsg; ++i) {
+	switch (msg[i].msg_style) {
+	case PAM_PROMPT_ECHO_OFF:
+	    packet_start(SSH_SMSG_PAM_PROMPT_ECHO_OFF);
+	    break;
+	case PAM_PROMPT_ECHO_ON:
+	    packet_start(SSH_SMSG_PAM_PROMPT_ECHO_ON);
+	    break;
+	case PAM_ERROR_MSG:
+	    packet_start(SSH_SMSG_PAM_ERROR_MSG);
+	    break;
+	case PAM_TEXT_INFO:
+	    packet_start(SSH_SMSG_PAM_TEXT_INFO);
+	    break;
+	default:
+	    goto conversation_failed;
+	}
+
+	packet_put_string(msg[i].msg, strlen(msg[i].msg));
+	packet_send();
+	packet_write_wait();
+	type = packet_read();
+
+	switch (msg[i].msg_style) {
+	case PAM_PROMPT_ECHO_OFF:
+	case PAM_PROMPT_ECHO_ON:
+	    if (type != SSH_CMSG_AUTH_PAM_INPUT) {
+		goto conversation_failed;
+	    }
+	    reply[i].resp = packet_get_string(NULL);
+	    break;
+	case PAM_ERROR_MSG:
+	case PAM_TEXT_INFO:
+	    if (type != SSH_CMSG_AUTH_PAM_CONTINUE) {
+		goto conversation_failed;
+	    }
+	    break;
+	default:
+	    /* how did we get here? */
+	    goto conversation_failed;
+	}
+    }
+
+    *resp = reply;
+
+    return PAM_SUCCESS;
+
+conversation_failed:
+
+    /* clean up before returning */
+    for (i=0; i<nmsg; ++i) {
+	if (reply[i].resp) {
+	    memset(reply[i].resp, 0, strlen(reply[i].resp));
+	    xfree(reply[i].resp);
+	    reply[i].resp = NULL;
+	}
+    }
+    xfree(reply);
+
+    return PAM_CONV_ERR;
+}
+
+/* conversation structure */
+static struct pam_conv ssh_pam_conv = { pam_ssh_conv, NULL };
+
+/* pam handle for current connection */
+pam_handle_t *pamh;
+
+#endif /* HAVE_PAM */
+
 /* Prototypes for various functions defined later in this file. */
 void do_connection(int privileged_port);
 void do_authentication(char *user, int privileged_port, int cipher_type);
@@ -1255,6 +1356,10 @@
 
   /* Declare supported authentication types. */
   auth_mask = 0;
+#ifdef HAVE_PAM
+  if (options.pam_authentication)
+    auth_mask |= 1 << SSH_AUTH_PAM;
+#endif /* HAVE_PAM */
   if (options.rhosts_authentication)
     auth_mask |= 1 << SSH_AUTH_RHOSTS;
   if (options.rhosts_rsa_authentication)
@@ -1749,6 +1854,81 @@
       /* Process the packet. */
       switch (type)
 	{
+#ifdef HAVE_PAM
+	case SSH_CMSG_AUTH_PAM_START:
+	{
+	    int retval, tries;
+	    char *ruser;
+
+	    pamh = NULL;
+	    retval = pam_start("ssh", user, ssh_pam_conv, &pamh);
+	    if (retval != PAM_SUCCESS) {
+		fatal("PAM error.");
+	    }
+
+	    /* we need to fill in as much info about the user as possible */
+	    ruser = packet_get_string(NULL);
+	    retval = pam_set_item(pamh, PAM_RUSER, ruser);
+	    if (retval == PAM_SUCCESS)
+		retval = pam_set_item(pamh, PAM_RHOST,
+				      get_canonical_hostname());
+	    if (retval != PAM_SUCCESS) {
+		fatal("PAM set item error.");
+	    }
+
+	    /* now we attempt to authenticate the user */
+
+	    not_authenticating=0;
+	    do {
+		retval = pam_authenticate(pamh, 0);
+		if (retval == PAM_SUCCESS) {
+		    authenticated = 1;
+		} else {
+		    if (retval == PAM_MAXTRIES || ++password_attempts > 5) {
+			pam_end(pamh, PAM_MAXTRIES);
+			pamh = NULL;
+			packet_disconnect("Too many password authentication"
+					  " attempts from %.100s@%.100s for"
+					  " user %.100s.",
+					  ruser, get_canonical_hostname(),
+					  user);
+		    }
+		}
+	    } while (!authenticated);
+
+	    /* now we test if the user is permitted to log in at this time */
+	    retval = pam_acct_mgmt(pamh, 0);
+	    if (retval != PAM_SUCCESS) {
+		switch (retval) {
+		case PAM_AUTHTOKEN_REQD: /* user's password(s) need renewing */
+		    retval = pam_chauthtok(pamh, PAM_CHANGE_EXPIRED_AUTHTOK);
+		    if (PAM_SUCCESS == retval)
+			break;                    /* password safely updated */
+		default:
+		    packet_start(SSH_SMSG_PAM_ERROR_MSG);
+		    packet_put_string("Sorry, you cannot login at this time."
+				      , 37 /* strlen() */);
+		    packet_send();
+		    packet_write_wait();
+		    pam_end(pamh, retval);
+		    packet_disconnect("Account management stopped"
+				      " attempt by %.100s@%.100s for"
+				      " user %.100s.",
+				      ruser, get_canonical_hostname(),
+				      user);
+		}
+	    }
+
+	    xfree(ruser);
+
+	    /* we have successfully logged in and are permitted to do
+	       so at this time. */
+
+	    not_authenticating=1;
+	    authentication_type = SSH_AUTH_PAM;
+	    break;
+	}
+#endif /* HAVE_PAM */
 #ifdef KERBEROS_TGT_PASSING
 #ifdef KRB5
 	case SSH_CMSG_HAVE_KERBEROS_TGT:
@@ -2222,6 +2402,19 @@
   /* Cancel the alarm we set to limit the time taken for authentication. */
   alarm(0);
 
+#ifdef HAVE_PAM
+  /* here we open a pam_session */
+
+  if (pamh) {
+      int retval;
+
+      retval = pam_open_session(pamh, 0);
+      if (retval != PAM_SUCCESS) {
+	  fatal("Failed to open session.");
+      }
+  }
+#endif /* HAVE_PAM */
+
   /* Inform the channel mechanism that we are the server side and that
      the client may request to connect to any port at all.  (The user could
      do it anyway, and we wouldn\'t know what is permitted except by the
@@ -2670,6 +2863,17 @@
     last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name,
 					  buf, sizeof(buf));
 
+#ifdef HAVE_PAM
+  if (pamh != NULL) {
+      int retval;
+
+      retval = pam_setcred(pamh, PAM_ESTABLISH_CRED);
+      if (retval != PAM_SUCCESS) {
+	  fatal("Failed setting credentials.");
+      }
+  }
+#endif /* HAVE_PAM */
+
   /* Fork the child. */
   if ((pid = fork()) == 0)
     { 
@@ -2799,6 +3003,24 @@
   /* server_loop has closed ptyfd and fdout. */
   /* server_loop has already Released the pseudo-tty. */
 
+#ifdef HAVE_PAM
+  if (pamh != NULL) {
+      int retval;
+
+      retval = pam_setcred(pamh, PAM_DELETE_CRED);
+      if (retval != PAM_SUCCESS) {
+	  fatal("Failed deleting credentials.");
+      }
+      retval = pam_session_close(pamh, 0);
+      if (retval != PAM_SUCCESS) {
+	  fatal("Failed closing session.");
+      }
+
+      pam_end(pamh, retval);
+      pamh = NULL;
+  }
+#endif /* HAVE_PAM */
+
   /* Cancel the cleanup function. */
   fatal_remove_cleanup(pty_cleanup_proc, (void *)&cleanup_context);
 
@@ -3419,6 +3641,18 @@
 	cp = shell;
     }
   
+#ifdef HAVE_PAM
+  /* XXX - we should also have taken the environment from PAM */
+  if (pamh != NULL) {
+      pam_end(pamh, PAM_SUCCESS
+#ifdef PAM_DATA_QUIET                                  /* Linux-PAM only */
+	      | PAM_DATA_QUIET
+#endif
+	  );
+      pamh = NULL;
+  }
+#endif /* HAVE_PAM */
+
   /* If we have no command, execute the shell.  In this case, the shell name
      to be passed in argv[0] is preceded by '-' to indicate that this is
      a login shell. */

--ELM877918194-12976-0_--
From owner-ietf-ssh@clinet.fi  Mon Oct 27 21:28:43 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 VAA05791;
	Mon, 27 Oct 1997 21:28:43 +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 VAA28316;
	Mon, 27 Oct 1997 21:28:41 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id VAA05603
	for ietf-ssh-outgoing; Mon, 27 Oct 1997 21:05:53 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from LIMPET.INNOSOFT.COM (LIMPET.INNOSOFT.COM [192.160.253.59])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id VAA05485
	for <ietf-ssh@clinet.fi>; Mon, 27 Oct 1997 21:04:30 +0200 (EET)
Received: from eleanor.innosoft.com ("port 42316"@ELEANOR.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-10 #8694)
 with SMTP id <01IPAS2ZY4Z69JD9BZ@INNOSOFT.COM> for ietf-ssh@clinet.fi; Mon,
 27 Oct 1997 11:02:54 PDT
Date: Mon, 27 Oct 1997 11:05:03 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: New secsh -02 drafts
To: IETF Secure Shell list <ietf-ssh@clinet.fi>
Message-id: <Pine.SOL.3.95.971027095353.11555A-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: 5857
Lines: 127

I recently finished a careful review of all four documents.  My overall
opinion is that the transport and userauth protocols are great (probably
the most readable and implementable security specs I've seen in the IETF),
but the connect protocol needs a lot of work.

Specific comments:

Architecture document:

Section 3.6 needs some work.  I am not convinced that negotiating terminal
emulation is sufficient to negotiate an unambiguous character set.  I
think there should at least be a way to indicate that UTF-8 is active and
available on both ends, so it is possible for character sets to
interoperate between clients and servers from different vendors.  The
wording on user names is also too vague -- I think something like your
wording for passwords in the userauth spec section 5 is a good model.

Section 4 could use a couple more examples for the "mpint" format.  I'd
like to see an example showing a negative number and one showing a
positive number which needed a leading zero.

Section 5 limits identifiers to 64 characters, but it also notes that
domain names can be used to construct identifiers.  I believe domain names
can be as long as 256 characters.  If you keep the 64 character limit, you
need to be aware that some domains may be unable to define their own
identifiers.

Transport document:

You currently list five ciphers.  The required one is conservative
(3des-cbc) and the recommended one is fast (blowfish-cbc).  Is there any
need to have other optional ciphers in the base spec?  It would seem to me
they simply make it harder to do the interoperability testing necessary to
reach draft status.

Section 9.1 & 9.3 have language tagged strings.  However, no where is
there a discussion of how the client communicates it's language
preferences to the server.  I think you need a client->server message
which lists language tags in order of preference.

I also notice that you include the language tag _after_ the message. 
Would it be possible to include it before the message?  Some systems use
the language tag to affect the display of the characters and it would be
useful to get it first.  If this is too hard to change, it's not that big
a deal.

Userauth document:

I couldn't find a mention of the technique where the server sleeps after
an unsuccessful authentication to make key search harder.  Should this be
mentioned somewhere?

I'm a bit concerned that the request to get a list of authentication
mechanisms ("none") is the same as the request to do anonymous
authentication. I suggest you instead have a separate anonymous
authentication mechanism (which may include a string for logging purposes
along the lines of the password in anonymous login to other protocols).  I
defined one for SASL in draft-ietf-acap-anon-01.txt.

Connection document:

This seems to be really focused on Unix servers.  I'd have no idea how to
implement a server for, say, VMS, MacOS or Windows NT.  The concepts
"pty" and "tty" are not general concepts.

Using IP addresses in a protocol is a *really* bad idea.  It's caused a
lot of problems for FTP due to firewalls and the IPv4->IPv6 transition.
If there is no way to avoid using IP addresses, you need to allow for IPv6
addresses.

>From a model standpoint, I can't tell if this is a TCP/IP multiplexing
protocol along the lines of PPP (for a reliable transport) or if this is
an application protocol along the lines of Telnet.  I think the conceptual
split between those two services needs to be made clearer.

I also think there needs to be a better discussion of architecture of
various forwarding services.  I have no idea what "auth-agent" forwarding
is or what it does.

It's also unclear what services are required on port 22.

In section 3.1, I wonder if it would be useful to open an unwindowed
channel?

In section 3.2 you define the EXTENDED_DATA type and define a type of
DATA_STDERR.  This makes me very nervous as stderr is a Unix/C specific
concept and no other protocol has ever split them into different channels. 
Don't most UAs end up dumping them back in the same window?  I know I
would.  What's obviously missing is the SSH_EXTENDED_DATA_URGENT for TCP
urgent data.  I don't really like urgent data, but there are protocols
which use it, such as TN3270, which may be useful over SSH.  I'd be
inclined to remove the STDERR and put in an URGENT instead.

In section 4.2. you haven't defined the concept of a pty or terminal width
& height (in characters vs. pixels).

There's also no way to discover what terminal types the server supports,
as there is in telnet.  You probably need a "session-options" message from
the server which tells the client what options are available. 

In section 4.3.1, you need to reference something so implementors can
figure out how to construct these messages.

In section 4.6, I really don't like the "subsystem" channel request.  It
seems like there are too many levels of indirection.  Why not just use a
different channel or define a channel request type for each subsystem? 

I think section 4.9 is a bad idea.  Every time I've seen flow control
used, it causes more problems than it solves.  I believe your windowing
capability is more than sufficient.

Sections 4.10 and 4.11 are completely Unix specific.  You need to
generalize the concepts.

In section 6, the terminal modes are far too detailed and Unix specific. 
In general, most of these are never used, so you'll never be able to
interoperability test all of them between multiple implementations.  I'm
not convinced any of them are needed.  The only time telnet
implementations ever muck with terminal modes are for linemode (which you
don't seem to have) and 8 bit (SSH should be 8-bit clean in both
directions).  I suggest you remove all of the terminal options, and if you
think it's important, replace them with a line mode similar to RFC 1184.

		- Chris



From owner-ietf-ssh@clinet.fi  Mon Oct 27 22:41: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 WAA06279;
	Mon, 27 Oct 1997 22:41:05 +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 WAA28427;
	Mon, 27 Oct 1997 22:41:04 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id WAA08736
	for ietf-ssh-outgoing; Mon, 27 Oct 1997 22:36:05 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from Twig.Rodents.Montreal.QC.CA (root@Twig.Rodents.Montreal.QC.CA [132.206.78.3])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id WAA08632
	for <ietf-ssh@clinet.fi>; Mon, 27 Oct 1997 22:34:48 +0200 (EET)
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.5/8.8.5) id PAA15642;
	Mon, 27 Oct 1997 15:34:17 -0500 (EST)
Date: Mon, 27 Oct 1997 15:34:17 -0500 (EST)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <199710272034.PAA15642@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: ietf-ssh@clinet.fi
Subject: Re: New secsh -02 drafts
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3064
Lines: 65

I'm not going to say much about the drafts themselves, because the only
ones I've read are by now out of date.  But....

> Using IP addresses in a protocol is a *really* bad idea.  It's caused
> a lot of problems for FTP due to firewalls

Firewalls qua firewalls aren't nearly so much of a problem as NAT, in
my experience.  (My opinion on the issue is that NAT is evil and
anything that makes it harder to do is probably good - and yes, I do
realize this opinion is not widely shared.)

> In section 3.2 you define the EXTENDED_DATA type and define a type of
> DATA_STDERR.  This makes me very nervous as stderr is a Unix/C
> specific concept and no other protocol has ever split them into
> different channels. 

UNIX-specific, not C-specific (except for the "stderr" name).  As for
"no other protocol has ever split them", that's not true; rsh has
always (AFAIK) supported distinct stdout and stderr; certainly every
implementation I've used more than once or twice has.

> Don't most UAs end up dumping them back in the same window?  I know I
> would.

When used as a remote login protocol, yeah.  When used as a remote
execution protocol, no.  If I run

	% ssh fastbox awk -f script.awk < input > output

I certainly do _not_ want stderr from the remote awk run to end up
dumped into my output file!

This is a purely pragmatic point of view; whether it is appropriate to
put such a thing into these documents is another question entirely.  It
may be better to have a companion document discussing ssh specifically
as it is implemented on Unices, and just make sure the protocol as
defined here allows such things.

> In section 6, the terminal modes are far too detailed and Unix
> specific.  [...]  I'm not convinced any of them are needed.  The only
> time telnet implementations ever muck with terminal modes are for
> linemode (which you don't seem to have) and 8 bit (SSH should be
> 8-bit clean in both directions).  I suggest you remove all of the
> terminal options, and if you think it's important, replace them with
> a line mode similar to RFC 1184.

Again, let me interject a pragmatic point of view here.  As a user, I
want my remote logins to propagate my tty special characters; if my
suspend character is set to ^E locally and I remote-login, I would like
the remote machine to set my suspend character to ^E there.  Similarly
for mode bits like tostop. Note that this is completely independent of
line-at-a-time versus character-at-a-time, or 8-bit-cleanness.

I don't have any good answers.  As I remarked above, I haven't read the
latest drafts...but if they don't at least permit an implementor to
provide such a thing, IMO the protocol is crippled.  And in the
ssh-on-Unices document I alluded to above (whether separate or rolled
into one of the existing documents), I'd like to see implementation
methods standardized, so that interoperability in this respect is not a
matter of using the same implementation on both ends.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From owner-ietf-ssh@clinet.fi  Tue Oct 28 02:07: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 CAA08277;
	Tue, 28 Oct 1997 02:07:33 +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 CAA29050;
	Tue, 28 Oct 1997 02:07:32 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id CAA23739
	for ietf-ssh-outgoing; Tue, 28 Oct 1997 02:04:38 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id CAA23708
	for <ietf-ssh@clinet.fi>; Tue, 28 Oct 1997 02:04:24 +0200 (EET)
Received: from istari.sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [205.233.54.136])
	by lox.sandelman.ottawa.on.ca (8.8.7/8.8.7) with ESMTP id TAA04027
	for <ietf-ssh@clinet.fi>; Mon, 27 Oct 1997 19:08:01 -0500 (EST)
Received: from istari.sandelman.ottawa.on.ca ([[UNIX: localhost]]) by istari.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id TAA00850 for <ietf-ssh@clinet.fi>; Mon, 27 Oct 1997 19:08:17 -0500 (EST)
Message-Id: <199710280008.TAA00850@istari.sandelman.ottawa.on.ca>
To: ietf-ssh@clinet.fi
Subject: Re: New secsh -02 drafts 
In-reply-to: Your message of "Mon, 27 Oct 1997 11:05:03 PST."
             <Pine.SOL.3.95.971027095353.11555A-100000@eleanor.innosoft.com> 
Date: Mon, 27 Oct 1997 19:08:17 -0500
From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2106
Lines: 52

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Chris" == Chris Newman <Chris.Newman@INNOSOFT.COM> writes:
    Chris> You currently list five ciphers.  The required one is
    Chris> conservative (3des-cbc) and the recommended one is fast
    Chris> (blowfish-cbc).  Is there any need to have other optional

  3des can not legally be used without a permit in a number of
countries where DES is, for instance, legal, and even
exportable. (Israel is one such country) 
  
    Chris> I also think there needs to be a better discussion of
    Chris> architecture of various forwarding services.  I have no
    Chris> idea what "auth-agent" forwarding is or what it does.

  This is a good point.

    Chris> In section 6, the terminal modes are far too detailed and
    Chris> Unix specific.  In general, most of these are never used,
    Chris> so you'll never be able to interoperability test all of
    Chris> them between multiple implementations.  I'm not convinced
    Chris> any of them are needed.  The only time telnet
    Chris> implementations ever muck with terminal modes are for
    Chris> linemode (which you don't seem to have) and 8 bit (SSH
    Chris> should be 8-bit clean in both directions).  I suggest you
    Chris> remove all of the terminal options, and if you think it's
    Chris> important, replace them with a line mode similar to RFC
    Chris> 1184.

  Agreed.

   :!mcr!:            |  Network and security consulting/contract programming
   Michael Richardson |   I do IPsec policy code for SSH <http://www.ssh.fi/>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>. 






-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNFUs3aZpLyXYhL+BAQFLCQMAxJk0Xev65Hyo+PdY4wS1ePkmMga2V/2r
Jqj7vqpPj/dUFz8Q6EQfflYvUdn2iVEjKRQVoiizfyQwJEzajp2PxbzshDXAVc22
OCyKLAHMtdwkDlDO4TZf54y3YGJcgKoR
=sfey
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Tue Oct 28 17:17:26 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 RAA20831;
	Tue, 28 Oct 1997 17:17:26 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id RAA02043;
	Tue, 28 Oct 1997 17:17:25 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id NAA28636
	for ietf-ssh-outgoing; Tue, 28 Oct 1997 13:12:21 +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.6/8.8.6) with ESMTP id NAA28626
	for <ietf-ssh@clinet.fi>; Tue, 28 Oct 1997 13:12:16 +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 NAA01421;
	Tue, 28 Oct 1997 13:12:13 +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 NAA14730;
	Tue, 28 Oct 1997 13:12:09 +0200 (EET)
Date: Tue, 28 Oct 1997 13:12:08 +0200 (EET)
From: Markku-Juhani Saarinen <mjos@ssh.fi>
To: Chris Newman <Chris.Newman@INNOSOFT.COM>
cc: IETF Secure Shell list <ietf-ssh@clinet.fi>
Subject: Re: New secsh -02 drafts
In-Reply-To: <Pine.SOL.3.95.971027095353.11555A-100000@eleanor.innosoft.com>
Message-ID: <Pine.NEB.3.95q.971028110711.3732A-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: 8235
Lines: 194


On Mon, 27 Oct 1997, Chris Newman wrote:

> Section 3.6 needs some work.  I am not convinced that negotiating terminal
> emulation is sufficient to negotiate an unambiguous character set.
..  
> I think there should at least be a way to indicate that UTF-8 is active
> and available on both ends, so it is possible for character sets to
> interoperate between clients and servers from different vendors.

UTF-8 is used for error and debug messages. If you get an error message
that you can't display, an additional handshake procedure won't help much.
Displaying error messages is a SHOULD, not a MUST -- and you can
try to use the error code.

The shell stream itself is terminal specific and is typically not UTF-8.
Maybe this needs clarifying..

> wording on user names is also too vague -- I think something like your
> wording for passwords in the userauth spec section 5 is a good model.

You're right. I'll change that SHOULD into a MUST (use UTF-8 in user
names).

> Section 4 could use a couple more examples for the "mpint" format.  I'd
> like to see an example showing a negative number and one showing a
> positive number which needed a leading zero.

Ok. Will add those.

> Section 5 limits identifiers to 64 characters, but it also notes that
> domain names can be used to construct identifiers.  I believe domain names
> can be as long as 256 characters.  If you keep the 64 character limit, you
> need to be aware that some domains may be unable to define their own
> identifiers.

I think I'll remove this constraint altogether.

> Transport document:
> 
> You currently list five ciphers.  The required one is conservative
> (3des-cbc) and the recommended one is fast (blowfish-cbc).  Is there any
> need to have other optional ciphers in the base spec?

We like to state the SSH names of several ciphers to avoid confusion.
If someone succeeds in the cryptoanalysis of blowfish (which is a
relatively new cipher, after all) SSH users can easily change to other
algorithms.

> It would seem to me they simply make it harder to do the
> interoperability testing necessary to reach draft status.

You only need 3DES to interop (it is the only REQUIRED cipher).

> Section 9.1 & 9.3 have language tagged strings.  However, no where is
> there a discussion of how the client communicates it's language
> preferences to the server.  I think you need a client->server message
> which lists language tags in order of preference.

Hmm. Typically these messages are something that a system administrator
would write (e.g. "can't login because we're changing disks"). Of course
the admin may be multilingual..  

As the arch document says, "For data that is normally displayed, it
SHOULD be possible to fetch a localized message instead of the transmitted
one by using a numeric code.". The codes are used when possible.

> I also notice that you include the language tag _after_ the message. 
> Would it be possible to include it before the message?  Some systems use
> the language tag to affect the display of the characters and it would be
> useful to get it first.  If this is too hard to change, it's not that big
> a deal.

They are in the same packet; the order is really irrelevant. But I'll
change it.

> I couldn't find a mention of the technique where the server sleeps after
> an unsuccessful authentication to make key search harder.  Should this be
> mentioned somewhere?

This is not really a protocol issue. The protocol allows sleeping as it
is. I'll write something about it to the security considerations
section.
 
> I suggest you instead have a separate anonymous
> authentication mechanism (which may include a string for logging purposes
> along the lines of the password in anonymous login to other protocols).  I
> defined one for SASL in draft-ietf-acap-anon-01.txt.

One may use special user names (e.g. guest, visitor, archie, info) with
password authentication to do this. This is compatible with existing
systems and provides equal functionality. 

> This seems to be really focused on Unix servers.  I'd have no idea how to
> implement a server for, say, VMS, MacOS or Windows NT.  The concepts
> "pty" and "tty" are not general concepts.

> Using IP addresses in a protocol is a *really* bad idea.  It's caused a
> lot of problems for FTP due to firewalls and the IPv4->IPv6 transition.

We use fully qualified domain names (textual strings), not IP addresses.
IPv6 will work fine.

> From a model standpoint, I can't tell if this is a TCP/IP multiplexing
> protocol along the lines of PPP (for a reliable transport) or if this is
> an application protocol along the lines of Telnet. I think the
> conceptual split between those two services needs to be made clearer.

Ok. IMHO, SSH is an application protocol that happens to allow TCP/IP 
multiplexing :-)

> I also think there needs to be a better discussion of architecture of
> various forwarding services.  I have no idea what "auth-agent" forwarding
> is or what it does.

We have an unpublished draft on authentication agents. I'll polish it
and put it out in a couple of weeks.

> In section 3.2 you define the EXTENDED_DATA type and define a type of
> DATA_STDERR.  This makes me very nervous as stderr is a Unix/C specific
> concept and no other protocol has ever split them into different channels. 
> Don't most UAs end up dumping them back in the same window?

Yep. But it might be useful if someone wants to redirect the stderr.

> I know I would.  What's obviously missing is the 
> SSH_EXTENDED_DATA_URGENT for TCP urgent data.  I don't really like
> urgent data, but there are protocols which use it, such as TN3270, which
> may be useful over SSH.

I don't think that TN3270 really needs urgent (have to check).

> In section 4.2. you haven't defined the concept of a pty or terminal width
> & height (in characters vs. pixels).

err.. "the horizontal and vertical dimensions of the terminal window" ?
:-)

> There's also no way to discover what terminal types the server supports,
> as there is in telnet.  You probably need a "session-options" message from
> the server which tells the client what options are available. 

I think that this is a good idea, although the client typically only
supports one terminal type.

> In section 4.3.1, you need to reference something so implementors can
> figure out how to construct these messages.

Ok.

> In section 4.6, I really don't like the "subsystem" channel request.  It
> seems like there are too many levels of indirection.  Why not just use a
> different channel or define a channel request type for each subsystem? 

As the spec says, "Only one of these requests cam succeed per channel". 
A subsystem (e.g. archie, gopher, some banking application, ..) already
uses it's own channel.. ?  

> I think section 4.9 is a bad idea.  Every time I've seen flow control
> used, it causes more problems than it solves.  I believe your windowing
> capability is more than sufficient.

I agree for the most part. Local flow control is not required in SSH; you
can be SSH compatible and not implement this. Some UNIX folks just happen
to like this sort of flow control.

> Sections 4.10 and 4.11 are completely Unix specific.  You need to
> generalize the concepts.

Again, these are not required. They are specified only to avoid
confusion.. The section will state that these are only for POSIX-like
systems.

> In section 6, the terminal modes are far too detailed and Unix specific. 
> In general, most of these are never used, so you'll never be able to
> interoperability test all of them between multiple implementations.  I'm
> not convinced any of them are needed.  The only time telnet
> implementations ever muck with terminal modes are for linemode (which you
> don't seem to have) and 8 bit (SSH should be 8-bit clean in both
> directions).  I suggest you remove all of the terminal options, and if you
> think it's important, replace them with a line mode similar to RFC 1184.

I don't think that RFC 1184 line mode stuff is enough for all 
applications. I'll remove the codes and replace them with a reference to
appropriate POSIX documents.


Thank you for your thoughtful comments !

- mj

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


From owner-ietf-ssh@clinet.fi  Tue Oct 28 22:00:31 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 WAA27930;
	Tue, 28 Oct 1997 22:00:31 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id WAA03197;
	Tue, 28 Oct 1997 22:00:30 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id TAA15594
	for ietf-ssh-outgoing; Tue, 28 Oct 1997 19:54:04 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from LIMPET.INNOSOFT.COM (LIMPET.INNOSOFT.COM [192.160.253.59])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id TAA15566
	for <ietf-ssh@clinet.fi>; Tue, 28 Oct 1997 19:53:50 +0200 (EET)
Received: from eleanor.innosoft.com ("port 42687"@ELEANOR.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-10 #8694)
 with SMTP id <01IPC3RVAYI09JEBZK@INNOSOFT.COM> for ietf-ssh@clinet.fi; Tue,
 28 Oct 1997 09:49:06 PDT
Date: Tue, 28 Oct 1997 09:51:15 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: New secsh -02 drafts
In-reply-to: <199710272034.PAA15642@Twig.Rodents.Montreal.QC.CA>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: ietf-ssh@clinet.fi
Message-id: <Pine.SOL.3.95.971028093833.12214C-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: 1873
Lines: 44

On Mon, 27 Oct 1997, der Mouse wrote:
> When used as a remote login protocol, yeah.  When used as a remote
> execution protocol, no.  If I run
> 
> 	% ssh fastbox awk -f script.awk < input > output
> 
> I certainly do _not_ want stderr from the remote awk run to end up
> dumped into my output file!

Ok, you've changed my mind.  I think it is necessary to split stderr for
this purpose.

> It may be better to have a companion document discussing ssh specifically
> as it is implemented on Unices, and just make sure the protocol as
> defined here allows such things.

That sounds reasonable.

> Again, let me interject a pragmatic point of view here.  As a user, I
> want my remote logins to propagate my tty special characters; if my
> suspend character is set to ^E locally and I remote-login, I would like
> the remote machine to set my suspend character to ^E there.  Similarly
> for mode bits like tostop.

Why not just configure things in your shell rc file on the server?  Then
there's no need to grot up protocols to pass this sort of machine specific
junk.  I'm sure if I pulled out the VMS manuals I could find hundreds of
things which are equally justifiable to pass over the protocol. 

> I don't have any good answers.  As I remarked above, I haven't read the
> latest drafts...but if they don't at least permit an implementor to
> provide such a thing, IMO the protocol is crippled.

A protocol is complete not when there is nothing left to add, but when
there is nothing left to take away.

If it *really absolutely necessary* to pass this stuff, I suggest having
extensible arbitrary string-based attribute value pairs.  I suspect the
work necessary to determine which bits/flags/tty chars are useful to pass,
which need to be generalized and which shouldn't be passed is quite
complicated and is best left until after SSH is standards track.

		- Chris

From owner-ietf-ssh@clinet.fi  Tue Oct 28 20:39:51 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 UAA27179;
	Tue, 28 Oct 1997 20:39:43 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id UAA02862;
	Tue, 28 Oct 1997 20:39:41 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id UAA22390
	for ietf-ssh-outgoing; Tue, 28 Oct 1997 20:36:33 +0200 (EET)
Received: from capone.ch.apollo.hp.com (capone.ch.apollo.hp.com [15.254.24.3])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id UAA22250
	for <ietf-ssh@clinet.fi>; Tue, 28 Oct 1997 20:36:13 +0200 (EET)
Received: from thunk.ch.apollo.hp.com by capone.ch.apollo.hp.com id <AA139403726@capone.ch.apollo.hp.com>; Tue, 28 Oct 1997 13:35:26 -0500    
Received: from thunk ([[UNIX: localhost]])
	by thunk.ch.apollo.hp.com (8.8.6/8.8.6) with ESMTP id NAA01557;
	Tue, 28 Oct 1997 13:35:23 -0500 (EST)
Message-Id: <199710281835.NAA01557@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: ietf-ssh@clinet.fi
Subject: Re: New secsh -02 drafts 
In-Reply-To: mouse's message of Mon, 27 Oct 1997 15:34:17 -0500.
	     <199710272034.PAA15642@Twig.Rodents.Montreal.QC.CA> 
Date: Tue, 28 Oct 1997 13:35:20 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2851
Lines: 67

> > In section 3.2 you define the EXTENDED_DATA type and define a type of
> > DATA_STDERR.  This makes me very nervous as stderr is a Unix/C
> > specific concept and no other protocol has ever split them into
> > different channels. 
> 
> UNIX-specific, not C-specific (except for the "stderr" name).  As for
> "no other protocol has ever split them", that's not true; rsh has
> always (AFAIK) supported distinct stdout and stderr; certainly every
> implementation I've used more than once or twice has.

Separating "normal output" from "error output" is not a concept
limited to UNIX.  Apollo's Aegis also did this; I suspect that there
are others..

					- Bill






> 
> > Don't most UAs end up dumping them back in the same window?  I know I
> > would.
> 
> When used as a remote login protocol, yeah.  When used as a remote
> execution protocol, no.  If I run
> 
> 	% ssh fastbox awk -f script.awk < input > output
> 
> I certainly do _not_ want stderr from the remote awk run to end up
> dumped into my output file!
> 
> This is a purely pragmatic point of view; whether it is appropriate to
> put such a thing into these documents is another question entirely.  It
> may be better to have a companion document discussing ssh specifically
> as it is implemented on Unices, and just make sure the protocol as
> defined here allows such things.
> 
> > In section 6, the terminal modes are far too detailed and Unix
> > specific.  [...]  I'm not convinced any of them are needed.  The only
> > time telnet implementations ever muck with terminal modes are for
> > linemode (which you don't seem to have) and 8 bit (SSH should be
> > 8-bit clean in both directions).  I suggest you remove all of the
> > terminal options, and if you think it's important, replace them with
> > a line mode similar to RFC 1184.
> 
> Again, let me interject a pragmatic point of view here.  As a user, I
> want my remote logins to propagate my tty special characters; if my
> suspend character is set to ^E locally and I remote-login, I would like
> the remote machine to set my suspend character to ^E there.  Similarly
> for mode bits like tostop. Note that this is completely independent of
> line-at-a-time versus character-at-a-time, or 8-bit-cleanness.
> 
> I don't have any good answers.  As I remarked above, I haven't read the
> latest drafts...but if they don't at least permit an implementor to
> provide such a thing, IMO the protocol is crippled.  And in the
> ssh-on-Unices document I alluded to above (whether separate or rolled
> into one of the existing documents), I'd like to see implementation
> methods standardized, so that interoperability in this respect is not a
> matter of using the same implementation on both ends.
> 
> 					der Mouse
> 
> 			       mouse@rodents.montreal.qc.ca
> 		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From owner-ietf-ssh@clinet.fi  Tue Oct 28 21:22:42 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 VAA27629;
	Tue, 28 Oct 1997 21:22:35 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id VAA03128;
	Tue, 28 Oct 1997 21:22:35 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id VAA28598
	for ietf-ssh-outgoing; Tue, 28 Oct 1997 21:18:40 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id VAA28399
	for <ietf-ssh@clinet.fi>; Tue, 28 Oct 1997 21:17:28 +0200 (EET)
Received: from eleanor.innosoft.com ("port 43162"@ELEANOR.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-10 #8694)
 with SMTP id <01IPC6R6E27G9JEBZK@INNOSOFT.COM> for ietf-ssh@clinet.fi; Tue,
 28 Oct 1997 11:14:03 PDT
Date: Tue, 28 Oct 1997 11:16:08 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: New secsh -02 drafts
In-reply-to: <Pine.NEB.3.95q.971028110711.3732A-100000@pilari.ssh.fi>
To: Markku-Juhani Saarinen <mjos@ssh.fi>
Cc: IETF Secure Shell list <ietf-ssh@clinet.fi>
Message-id: <Pine.SOL.3.95.971028100724.12214E-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: 8122
Lines: 173

On Tue, 28 Oct 1997, Markku-Juhani Saarinen wrote:
> The shell stream itself is terminal specific and is typically not UTF-8.
> Maybe this needs clarifying..

I think there needs to be some way to configure the charset for the
terminal.  I know telnet clients often have a non-interoperable manually
configured charset (e.g., VT-100 + ISO-8859-1, or VT-100 + ISO-2022-JP).
There should be a way to negotiate this interoperably, IMHO.  The telnet
charset option is probably overkill, but leaving the charset undefined or
US-ASCII only isn't acceptable either, IMHO.

> We like to state the SSH names of several ciphers to avoid confusion.
> If someone succeeds in the cryptoanalysis of blowfish (which is a
> relatively new cipher, after all) SSH users can easily change to other
> algorithms.

That's why there's an IANA registry.  I'm suggesting removing them from
the base spec and registering them independently.

> > It would seem to me they simply make it harder to do the
> > interoperability testing necessary to reach draft status.
> 
> You only need 3DES to interop (it is the only REQUIRED cipher).

The standards process requires multiple interoperable implementations of
all options in order to advance to draft status.  You can leave those
ciphers in for proposed, but you may have to drop them to move to draft
status.  I'm suggesting it's easier to leave them out of the base spec and
just register them with IANA after the spec becomes an RFC.  See section
4.1.2 of RFC 2026 second paragraph.

> > Section 9.1 & 9.3 have language tagged strings.  However, no where is
> > there a discussion of how the client communicates it's language
> > preferences to the server.  I think you need a client->server message
> > which lists language tags in order of preference.
> 
> Hmm. Typically these messages are something that a system administrator
> would write (e.g. "can't login because we're changing disks"). Of course
> the admin may be multilingual..  

If the admin writes it than it will probably be "i-default" language and
won't need negotiation.  But I suspect many of those messages will be
machine generated and the client needs to specify preferences.  I suggest:

#define SSH_MSG_LANGUAGE   7

byte    SSH_MSG_LANGUAGE
string  language_list

This specifies a client's language preferences to the server for error
messages.  language_list is a comma-separated list of language tags [RFC
1766] in order of preference.  The client SHOULD send this message prior
to SSH_MSG_KEXINIT so that negotiation errors (possibly due to site policy
restrictions) and all future errors can be presented in the correct
language for the user.  If the client fails to send this message, the
language is "i-default" as defined in [CHARSET-POLICY].  Upon receiving
this message, the server SHOULD use error messages in a language in the
client's language list when available, and otherwise use i-default.

[CHARSET-POLICY] is in last call right now. See
draft-alvestrand-charset-policy-01.txt.

> As the arch document says, "For data that is normally displayed, it
> SHOULD be possible to fetch a localized message instead of the transmitted
> one by using a numeric code.". The codes are used when possible.

The problem is the codes will always have less detail than the server
messages.  For example, with SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT,
there might be a reason like "You have exceeded your login time quota, you
may try again tomorrow." It would be better if this sort of message could
be displayed in the correct language if possible. 

> > I suggest you instead have a separate anonymous
> > authentication mechanism (which may include a string for logging purposes
> > along the lines of the password in anonymous login to other protocols).  I
> > defined one for SASL in draft-ietf-acap-anon-01.txt.
> 
> One may use special user names (e.g. guest, visitor, archie, info) with
> password authentication to do this. This is compatible with existing
> systems and provides equal functionality. 

Then I suggest you not use "none" as anonymous and instead designate a
special user name (e.g., "anonymous") at least by convention.

> We use fully qualified domain names (textual strings), not IP addresses.
> IPv6 will work fine.

Then you need to fix your examples and labels to say so.  For example,
in the connection protocol spec see 4.3.2, 5.1, 5.2.

> Ok. IMHO, SSH is an application protocol that happens to allow TCP/IP 
> multiplexing :-)

You're lucky the IETF applications area doesn't have "not invented here"
syndrome as some other areas do.  But it might be courteous to drop Harald
and Keith a note mentioning this so ssh gets reviewed by people with
applications protocol experience other than myself.

> > I know I would.  What's obviously missing is the 
> > SSH_EXTENDED_DATA_URGENT for TCP urgent data.  I don't really like
> > urgent data, but there are protocols which use it, such as TN3270, which
> > may be useful over SSH.
> 
> I don't think that TN3270 really needs urgent (have to check).

TN3270 is built on top of the telnet protocol which requires urgent data
for IP (Interrupt Process) and "synch" support.  See RFC 1123.  I suppose
it might be possible to use without it, but it's technically required by
the standards.

> > In section 4.2. you haven't defined the concept of a pty or terminal width
> > & height (in characters vs. pixels).
> 
> err.. "the horizontal and vertical dimensions of the terminal window" ?
> :-)

Fixed or variable width fonts?  What are the pixel sizes used for?

> I think that this is a good idea, although the client typically only
> supports one terminal type.

My telnet client does several flavors of the VT series as well as H19/Z29.
Of course, these days probably all you need is three flavors (one with and 
one without the nasty end-of-line hack), plus TN3270.

> > In section 4.6, I really don't like the "subsystem" channel request.  It
> > seems like there are too many levels of indirection.  Why not just use a
> > different channel or define a channel request type for each subsystem? 
> 
> As the spec says, "Only one of these requests cam succeed per channel". 
> A subsystem (e.g. archie, gopher, some banking application, ..) already
> uses it's own channel.. ?  

I guess I didn't state myself clearly.  Underneath the connection/userauth
layer you have channels.  Underneath channels you have channel-requests.
Underneath channel-requests you have subsystems.  I'm wondering why that
last level of layering is necessary.  Why not just define new channel
request types or channel types for such extensions?

> I agree for the most part. Local flow control is not required in SSH; you
> can be SSH compatible and not implement this. Some UNIX folks just happen
> to like this sort of flow control.

Why can't the client implement flow control locally without this message?
It can just stop updating the window when the user hits ^S and cache the
data for later display.  It would be simpler and more efficient.  I still
don't see why section 4.9 is useful given the SSH windowing facilities.

> > Sections 4.10 and 4.11 are completely Unix specific.  You need to
> > generalize the concepts.
> 
> Again, these are not required. They are specified only to avoid
> confusion.. The section will state that these are only for POSIX-like
> systems.

I suggest you try to generalize some of these facilities.  Telnet already
has several generalized.  It should at least be possible to generalize a
basic break/abort signal.  If you allow other signals, there needs to be a
reference to a stable specification for the meanings of the signals. 
There also needs to be a way to discover which signals are supported
(clients need to gray-out/remove menu items which don't apply). 

The exit-status needs to be defined in some way.  One option would be to
add a string indicating the type of exit status (with "unix" as one of the
types).

Exit-signal also needs to be defined with a stable reference.  Perhaps it
should be conbined with exit-status and just have a different type of
exit?  That would simplify things.

		- Chris


From owner-ietf-ssh@clinet.fi  Wed Oct 29 09:35:56 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 JAA04643;
	Wed, 29 Oct 1997 09:35:56 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id JAA05139;
	Wed, 29 Oct 1997 09:35:55 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id JAA24340
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 09:31:07 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from tai.cisco.com (tai.cisco.com [171.69.160.33])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id JAA24282
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 09:30:53 +0200 (EET)
Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id CAA10425; Wed, 29 Oct 1997 02:29:21 -0500 (EST)
Date: Wed, 29 Oct 1997 02:29:21 -0500 (EST)
From: Michael Boe <mboe@cisco.com>
Reply-To: Michael Boe <mboe@cisco.com>
Subject: Re: New secsh -02 drafts
To: Markku-Juhani Saarinen <mjos@ssh.fi>
cc: Chris Newman <Chris.Newman@INNOSOFT.COM>,
        IETF Secure Shell list <ietf-ssh@clinet.fi>
In-Reply-To: <Pine.NEB.3.95q.971028110711.3732A-100000@pilari.ssh.fi>
Message-ID: <ML-3.3.878110161.9071.mboe@mboe-home-ss20.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 893
Lines: 22

[snip]

> > I know I would.  What's obviously missing is the 
> > SSH_EXTENDED_DATA_URGENT for TCP urgent data.  I don't really like
> > urgent data, but there are protocols which use it, such as TN3270, which
> > may be useful over SSH.
> 
> I don't think that TN3270 really needs urgent (have to check).

TN3270 does not need the urgent data byte.  Urgent data byte is used by the
TELNET Synch/DM command. No implementation of TN3270 client that I'm aware of
sends the sync/DM in conjunction with IP or AO.  Or more specifically, the
server that I help develop for has never had interoperability problems with
clients concerning the use of the urgent data-byte, and this server ignores
urgent data bytes.  

Indeed, proper observance of what's implied by the urgent dataflag (strip all
data until DM is found) can probably be considered harmful in a stateful
environment like TN3270.

/msb

From owner-ietf-ssh@clinet.fi  Wed Oct 29 10:34:11 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 KAA05058;
	Wed, 29 Oct 1997 10:34:10 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id KAA05293;
	Wed, 29 Oct 1997 10:34:10 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id KAA01224
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 10:32: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 KAA01199
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 10:32:36 +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 KAA05287;
	Wed, 29 Oct 1997 10:32:35 +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 KAA05053;
	Wed, 29 Oct 1997 10:32:23 +0200 (EET)
Date: Wed, 29 Oct 1997 10:32:22 +0200 (EET)
From: Markku-Juhani Saarinen <mjos@ssh.fi>
To: Chris Newman <Chris.Newman@INNOSOFT.COM>
cc: IETF Secure Shell list <ietf-ssh@clinet.fi>
Subject: Re: New secsh -02 drafts
In-Reply-To: <Pine.SOL.3.95.971028100724.12214E-100000@eleanor.innosoft.com>
Message-ID: <Pine.NEB.3.95q.971029085235.27016A-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: 6576
Lines: 159


On Tue, 28 Oct 1997, Chris Newman wrote:

> I think there needs to be some way to configure the charset for the
> terminal.  I know telnet clients often have a non-interoperable manually
> configured charset (e.g., VT-100 + ISO-8859-1, or VT-100 + ISO-2022-JP).
> There should be a way to negotiate this interoperably, IMHO.  The telnet
> charset option is probably overkill, but leaving the charset undefined or
> US-ASCII only isn't acceptable either, IMHO.

How about a simple MIME-style charset identification string (e.g.
"ISO-8859-1") in the pseudo-terminal request message (connect, 4.2) ?  
The server could use this identifier to help with charset translations
(but is not required to).


> The standards process requires multiple interoperable implementations of
> all options in order to advance to draft status.  You can leave those
> ciphers in for proposed, but you may have to drop them to move to draft
> status.  I'm suggesting it's easier to leave them out of the base spec and
> just register them with IANA after the spec becomes an RFC.  See section
> 4.1.2 of RFC 2026 second paragraph.

I agree. We'll write a separate draft on SSH options (to be published as
informational).


> #define SSH_MSG_LANGUAGE   7
> 
> byte    SSH_MSG_LANGUAGE
> string  language_list
> 
> This specifies a client's language preferences to the server for error
> messages.  language_list is a comma-separated list of language tags [RFC
> 1766] in order of preference.  The client SHOULD send this message prior
> to SSH_MSG_KEXINIT so that negotiation errors (possibly due to site policy
> restrictions) and all future errors can be presented in the correct
> language for the user.  If the client fails to send this message, the
> language is "i-default" as defined in [CHARSET-POLICY].  Upon receiving
> this message, the server SHOULD use error messages in a language in the
> client's language list when available, and otherwise use i-default.

I'd like to:

  1) include this list to the SSH_MSG_KEXINIT packet (we really don't need 
     additinal messages)
  2) change all SHOULDs to MAYs (the server is allowed to ignore the list)

> [CHARSET-POLICY] is in last call right now. See
> draft-alvestrand-charset-policy-01.txt.

Yes, it seems like we'll have to do this. (btw, the version number is 02)


(on anynymous services and anonymous authentication)
> > One may use special user names (e.g. guest, visitor, archie, info) with
> > password authentication to do this. This is compatible with existing
> > systems and provides equal functionality. 
> 
> Then I suggest you not use "none" as anonymous and instead designate a
> special user name (e.g., "anonymous") at least by convention.

That might create an name space overlap. What if the host has an user
named "anonymous" which actually DOES require real authentication ? 


> > We use fully qualified domain names (textual strings), not IP addresses.
> > IPv6 will work fine.
> 
> Then you need to fix your examples and labels to say so.  For example,
> in the connection protocol spec see 4.3.2, 5.1, 5.2.

Thanks. I'll fix those.
 

> > I don't think that TN3270 really needs urgent (have to check).
> 
> TN3270 is built on top of the telnet protocol which requires urgent data
> for IP (Interrupt Process) and "synch" support.  See RFC 1123.  I suppose
> it might be possible to use without it, but it's technically required by
> the standards.

Ok. We'll define :

  #define SSH_EXTENDED_DATA_URGENT 2

for urgent data (this will go to 3.2, connect). Obviously this will only
be implemented if the TCP stack and OS support it. 


> > > In section 4.2. you haven't defined the concept of a pty or terminal width
> > > & height (in characters vs. pixels).
> > err.. "the horizontal and vertical dimensions of the terminal window" ?
> > :-) 
> Fixed or variable width fonts?  What are the pixel sizes used for?

I'll write some more text to 4.2 and 4.8 in connect.


> I guess I didn't state myself clearly.  Underneath the connection/userauth
> layer you have channels.  Underneath channels you have channel-requests.
> Underneath channel-requests you have subsystems.  I'm wondering why that
> last level of layering is necessary.  Why not just define new channel
> request types or channel types for such extensions?

Yes, that will allow additinal parameters to SSH_MSG_CHANNEL_REQUEST if
so needed. Also, I'll add some text saying that the SSH naming conventions
are used in SSH_MSG_CHANNEL_REQUEST strings (e.g. archie, app@bank.fi).


> Why can't the client implement flow control locally without this message?
> It can just stop updating the window when the user hits ^S and cache the
> data for later display.  It would be simpler and more efficient.  I still
> don't see why section 4.9 is useful given the SSH windowing facilities.

The flow control in unices does more than just put the output to a
buffer.. typically the process is freezed when the buffer is full. A
client-side flow control mechanism can't do this. 

Do a "yes | less" and you'll see what I mean: the "yes" process is freezed
when the buffer gets full; it is reactivated when "less" needs more text.

I think that this is an useful feature.


> > > Sections 4.10 and 4.11 are completely Unix specific.  You need to
> > > generalize the concepts.
> > 
> > Again, these are not required. They are specified only to avoid
> > confusion.. The section will state that these are only for POSIX-like
> > systems.
> 
> I suggest you try to generalize some of these facilities.  Telnet already
> has several generalized.  It should at least be possible to generalize a
> basic break/abort signal.  If you allow other signals, there needs to be a
> reference to a stable specification for the meanings of the signals. 
> There also needs to be a way to discover which signals are supported
> (clients need to gray-out/remove menu items which don't apply). 
>
> The exit-status needs to be defined in some way.  One option would be to
> add a string indicating the type of exit status (with "unix" as one of the
> types).
> 
> Exit-signal also needs to be defined with a stable reference.  Perhaps it
> should be conbined with exit-status and just have a different type of
> exit?  That would simplify things.

I'll write some more text on these. I won't modify anything, but I'll
document some basic POSIX signalling and exit status codes so that these 
can be implemented on non-POSIX systems in a compatible way.


Again, thank you for your comments. 

- mj

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


From owner-ietf-ssh@clinet.fi  Wed Oct 29 14:31:03 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 OAA06439;
	Wed, 29 Oct 1997 14:31:02 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id OAA06069;
	Wed, 29 Oct 1997 14:31:01 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id OAA23782
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 14:25:05 +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 OAA23768
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 14:24:58 +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 OAA20626; Wed, 29 Oct 1997 14:24:35 +0200 (EET)
Received: (from kivinen@localhost) by shadows.cs.hut.fi (8.7.6/8.7.3) id OAA13670; Wed, 29 Oct 1997 14:25:31 +0200 (EET)
Date: Wed, 29 Oct 1997 14:25:31 +0200 (EET)
Message-Id: <199710291225.OAA13670@shadows.cs.hut.fi>
From: Tero Kivinen <kivinen@niksula.hut.fi>
To: Markku-Juhani Saarinen <mjos@ssh.fi>
Cc: Chris Newman <Chris.Newman@INNOSOFT.COM>,
        IETF Secure Shell list <ietf-ssh@clinet.fi>
Subject: Re: New secsh -02 drafts
In-Reply-To: <Pine.NEB.3.95q.971029085235.27016A-100000@pilari.ssh.fi>
References: <Pine.SOL.3.95.971028100724.12214E-100000@eleanor.innosoft.com>
	<Pine.NEB.3.95q.971029085235.27016A-100000@pilari.ssh.fi>
Organization: Helsinki University of Technology
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-Edit-Time: 22 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3806
Lines: 74

Markku-Juhani Saarinen writes:
> (on anynymous services and anonymous authentication)
> > > One may use special user names (e.g. guest, visitor, archie, info) with
> > > password authentication to do this. This is compatible with existing
> > > systems and provides equal functionality. 
> > 
> > Then I suggest you not use "none" as anonymous and instead designate a
> > special user name (e.g., "anonymous") at least by convention.
> That might create an name space overlap. What if the host has an user
> named "anonymous" which actually DOES require real authentication ? 

Note, that servers can and will have several usernames that don't
require any password, but are still different. For example in Freenet
Finland, there is both visitor and vieras. The first one defaults to
English menu and the vieras defaults to Finnish menu system.

I think we must keep the username and this anonymous prosess
separated.

> > > We use fully qualified domain names (textual strings), not IP addresses.
> > > IPv6 will work fine.
> > Then you need to fix your examples and labels to say so.  For example,
> > in the connection protocol spec see 4.3.2, 5.1, 5.2.
> Thanks. I'll fix those.

No you have to use ip-address in those cases. The dns name of the
originator for example in x11 channel open can be something that is
not meaning full to you (some internal name etc) and there are some
security problems because then the client have to convert ip-address
to name and use unsecure dns to do that.

Note, that using ip address in those messages doesn't have any problem
with ipv6, the ip address can either be ipv4 address (192.168.7.38) or
ipv6 address (0000:0000:0000:0000:0000:0000:C0A8:0726). The originator
ip address is mainly used by server for logging purposes and it may do
some checks for them (for example require that the x11 originator is
127.0.0.1 or 0::7F00:0001). 

> 
> > > I don't think that TN3270 really needs urgent (have to check).
> > TN3270 is built on top of the telnet protocol which requires urgent data
> > for IP (Interrupt Process) and "synch" support.  See RFC 1123.  I suppose
> > it might be possible to use without it, but it's technically required by
> > the standards.
> Ok. We'll define :
>   #define SSH_EXTENDED_DATA_URGENT 2
> for urgent data (this will go to 3.2, connect). Obviously this will only
> be implemented if the TCP stack and OS support it. 

NO, no, no.... I don't think we should require or even try to use tcp
stack urgent data stuff for this. We have our own window system to do
flow control so there shouldn't be need for that. And if you don't
implement it by using the tcp urgent data pointer then this will do no
good, because all the extended data uses the same window than real
data. You cannot send urgent data if you don't have the data window
open for that channel. If you really want urgent data to be handled so
it will go have priority over normal data you have to create separate
channel for it, and I don't think we really need that. 

> > > > In section 4.2. you haven't defined the concept of a pty or terminal width
> > > > & height (in characters vs. pixels).
> > > err.. "the horizontal and vertical dimensions of the terminal window" ?
> > > :-) 
> > Fixed or variable width fonts?  What are the pixel sizes used for?
> I'll write some more text to 4.2 and 4.8 in connect.

I think most of the systems don't use them, but because most unix
systems will have struct winsize that has that information and we need
to send the rows and columns in characters anyway, we can send the
pixel information also in case somebody really uses it for something.
They can always be 0 if not meaning full or unknown. 
-- 
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 Oct 29 15:28:04 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 PAA06879;
	Wed, 29 Oct 1997 15:28:03 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id PAA06490;
	Wed, 29 Oct 1997 15:28:02 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id PAA29099
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 15:24:12 +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 PAA29089
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 15:24:05 +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 PAA06467;
	Wed, 29 Oct 1997 15:24:04 +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 PAA06859;
	Wed, 29 Oct 1997 15:24:01 +0200 (EET)
Date: Wed, 29 Oct 1997 15:24:01 +0200 (EET)
From: Markku-Juhani Saarinen <mjos@ssh.fi>
To: Tero Kivinen <kivinen@niksula.hut.fi>
cc: IETF Secure Shell list <ietf-ssh@clinet.fi>
Subject: Re: New secsh -02 drafts
In-Reply-To: <199710291225.OAA13670@shadows.cs.hut.fi>
Message-ID: <Pine.NEB.3.95q.971029143802.5331B-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: 1338
Lines: 39


On Wed, 29 Oct 1997, Tero Kivinen wrote:

> > > > We use fully qualified domain names (textual strings), not IP addresses.
> > > > IPv6 will work fine.
> > > Then you need to fix your examples and labels to say so.  For example,
> > > in the connection protocol spec see 4.3.2, 5.1, 5.2.
> > Thanks. I'll fix those.
 
> No you have to use ip-address in those cases. The dns name of the
> originator for example in x11 channel open can be something that is
> not meaningful to you (some internal name etc) and there are some
> security problems because then the client have to convert ip-address
> to name and use insecure dns to do that.

I think I see your point, but how can the (client) software know that a
given ip-address matches a specific host ?  The DNS (or static table)
lookup will just happen somewhere else. 

Or am I missing something here ?


> > Ok. We'll define :
> >   #define SSH_EXTENDED_DATA_URGENT 2
> > for urgent data (this will go to 3.2, connect). Obviously this will only
> > be implemented if the TCP stack and OS support it. 
> 
> NO, no, no.... I don't think we should require or even try to use tcp
> stack urgent data stuff for this.
(..)

I must agree with my coauthors. Sorry, there will be no
SSH_EXTENDED_DATA_URGENT..

- mj

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


From owner-ietf-ssh@clinet.fi  Wed Oct 29 16:22:40 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 QAA07268;
	Wed, 29 Oct 1997 16:22:40 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id QAA06796;
	Wed, 29 Oct 1997 16:22:39 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id QAA04591
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 16:17:51 +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 QAA04586
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 16:17:47 +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 QAA23771; Wed, 29 Oct 1997 16:17:46 +0200 (EET)
Received: (from kivinen@localhost) by shadows.cs.hut.fi (8.7.6/8.7.3) id QAA13960; Wed, 29 Oct 1997 16:18:41 +0200 (EET)
Date: Wed, 29 Oct 1997 16:18:41 +0200 (EET)
Message-Id: <199710291418.QAA13960@shadows.cs.hut.fi>
From: Tero Kivinen <kivinen@niksula.hut.fi>
To: Markku-Juhani Saarinen <mjos@ssh.fi>
Cc: IETF Secure Shell list <ietf-ssh@clinet.fi>
Subject: Re: New secsh -02 drafts
In-Reply-To: <Pine.NEB.3.95q.971029143802.5331B-100000@pilari.ssh.fi>
References: <199710291225.OAA13670@shadows.cs.hut.fi>
	<Pine.NEB.3.95q.971029143802.5331B-100000@pilari.ssh.fi>
Organization: Helsinki University of Technology
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-Edit-Time: 3 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 946
Lines: 18

Markku-Juhani Saarinen writes:
> I think I see your point, but how can the (client) software know that a
> given ip-address matches a specific host ?  The DNS (or static table)
> lookup will just happen somewhere else. 

Yes, it might happen, but it might not happen, and that depends how
that software will use that information. If the software will do the
lookup, it will also know how much it can trust the information. If it
gets the information from dnssec server it can trust it more than if
it just gets it from normal dns. It may also compare direct ip numbers
and not names, thus eliminating the problem with unsecure dns lookups.

If the sender does the lookup, the receiver have no way to know the
security parameters used when that ip->name lookup was done and it
cannot trust that information at all. 
-- 
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 Oct 29 16:23:39 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 QAA07285;
	Wed, 29 Oct 1997 16:23:30 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id QAA06807;
	Wed, 29 Oct 1997 16:23:28 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id QAA05077
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 16:23:21 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from Twig.Rodents.Montreal.QC.CA (root@Twig.Rodents.Montreal.QC.CA [132.206.78.3])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id QAA05055
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 16:23:09 +0200 (EET)
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.5/8.8.5) id JAA28805;
	Wed, 29 Oct 1997 09:22:32 -0500 (EST)
Date: Wed, 29 Oct 1997 09:22:32 -0500 (EST)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <199710291422.JAA28805@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: ietf-ssh@clinet.fi
Subject: Re: New secsh -02 drafts
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 564
Lines: 14

>> Then I suggest you not use "none" as anonymous and instead designate
>> a special user name (e.g., "anonymous") at least by convention.
> That might create an name space overlap.  What if the host has an
> user named "anonymous" which actually DOES require real
> authentication ?

The same applies to "none".  I'm in agreement with the person who said
that anonymous login semantics needs to be independent of any specific
username (or usernames).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From owner-ietf-ssh@clinet.fi  Wed Oct 29 16:57: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 QAA07667;
	Wed, 29 Oct 1997 16:57:51 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id QAA06918;
	Wed, 29 Oct 1997 16:57:51 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id QAA07694
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 16:52:17 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from Twig.Rodents.Montreal.QC.CA (Twig.Rodents.Montreal.QC.CA [132.206.78.3])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id QAA07517
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 16:50:42 +0200 (EET)
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.5/8.8.5) id JAA28963;
	Wed, 29 Oct 1997 09:49:41 -0500 (EST)
Date: Wed, 29 Oct 1997 09:49:41 -0500 (EST)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <199710291449.JAA28963@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: ietf-ssh@clinet.fi
Subject: Re: New secsh -02 drafts
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2117
Lines: 41

>>> What's obviously missing is the SSH_EXTENDED_DATA_URGENT for TCP
>>> urgent data.  I don't really like urgent data, but [...]
> Urgent data byte is used by the TELNET Synch/DM command.

"Urgent data byte"?  That doesn't sound like quite what TCP has.  What
it has an urgent pointer, which marks a point between two octets in the
data stream.  Everything from the current point up to the urgent
pointer is considered urgent data.  In particular, if you have queued
data and do an urgent send, then do another urgent send before the
previous one has actually made it to the peer, then there is no record
kept of the first urgent send.  The peer may have seen a packet or two
with the intermediate value of the urgent pointer, but it also may not.

Someone at Berkeley ("on either drugs or a shaky understanding of TCP",
as I usually say) decided to take the urgent pointer and treat it as
pointing at one of the octets it points between, making that octet into
an out-of-band byte.  This kinda-sorta-mostly works, as long as your
out-of-band data rate is low with respect to the bandwidth*delay
product of the connection.  This was true with Ethernetted VAXen at
Berkeley; it is not true in the current Internet.

Now, I may be preaching to the choir here; it may be that everyone
already knows this.  And admittedly I haven't actually read the draft
containing this stuff.  But this SSH_EXTENDED_DATA_URGENT, and the talk
about "urgent data byte", make it sound as though it's just a renaming
of the out-of-band data stream concept, in which case my remarks are
applicable.

> Indeed, proper observance of what's implied by the urgent dataflag
> (strip all data until DM is found) can probably be considered harmful
> in a stateful environment like TN3270.

Or the TELNET NVT, for that matter.  You can perhaps finesse this by
considering everything, even vanilla text, to fall under the "other
site-defined signals which can be acted on without delaying the scan of
the data stream" phrase in RFC854.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From owner-ietf-ssh@clinet.fi  Wed Oct 29 18:24:30 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 SAA08415;
	Wed, 29 Oct 1997 18:24:29 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id SAA07183;
	Wed, 29 Oct 1997 18:24:28 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id SAA15620
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 18:17:18 +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 SAA15595
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 18:17:09 +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 SAA26368; Wed, 29 Oct 1997 18:17:04 +0200 (EET)
Received: (from kivinen@localhost) by shadows.cs.hut.fi (8.7.6/8.7.3) id SAA14265; Wed, 29 Oct 1997 18:18:00 +0200 (EET)
Date: Wed, 29 Oct 1997 18:18:00 +0200 (EET)
Message-Id: <199710291618.SAA14265@shadows.cs.hut.fi>
From: Tero Kivinen <kivinen@niksula.hut.fi>
To: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Cc: ietf-ssh@clinet.fi
Subject: Re: New secsh -02 drafts
In-Reply-To: <199710291422.JAA28805@Twig.Rodents.Montreal.QC.CA>
References: <199710291422.JAA28805@Twig.Rodents.Montreal.QC.CA>
Organization: Helsinki University of Technology
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-Edit-Time: 3 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 804
Lines: 16

der Mouse writes:
> The same applies to "none".  I'm in agreement with the person who said
> that anonymous login semantics needs to be independent of any specific
> username (or usernames).

The none in current protocol is NOT username, it is authentication
method. The user names and authentication method names have separate
name spaces. The semantics of authentication method "none" is that if
there is no authentication required for user given in username field
then the authentication succeeds and the user is logged in. If
authentication is required then "none" can be used to get the initial
list of authentication methods that can be used for that user to log
in.
-- 
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 Oct 29 21:58:54 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 VAA10439;
	Wed, 29 Oct 1997 21:58:53 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id VAA08285;
	Wed, 29 Oct 1997 21:58:53 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id VAA10714
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 21:55:03 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from LIMPET.INNOSOFT.COM (LIMPET.INNOSOFT.COM [192.160.253.59])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id VAA10672
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 21:54:04 +0200 (EET)
Received: from eleanor.innosoft.com ("port 48031"@ELEANOR.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-10 #8694)
 with SMTP id <01IPDH8DCXTE9JEA9G@INNOSOFT.COM> for ietf-ssh@clinet.fi; Wed,
 29 Oct 1997 09:25:02 PDT
Date: Wed, 29 Oct 1997 09:27:12 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: New secsh -02 drafts
In-reply-to: <Pine.NEB.3.95q.971029085235.27016A-100000@pilari.ssh.fi>
To: Markku-Juhani Saarinen <mjos@ssh.fi>
Cc: IETF Secure Shell list <ietf-ssh@clinet.fi>
Message-id: <Pine.SOL.3.95.971029090512.15570C-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: 2779
Lines: 64

On Wed, 29 Oct 1997, Markku-Juhani Saarinen wrote:
> How about a simple MIME-style charset identification string (e.g.
> "ISO-8859-1") in the pseudo-terminal request message (connect, 4.2) ?  
> The server could use this identifier to help with charset translations
> (but is not required to).

I don't think that's quite enough.  Is there any way for the server to
return the charset it's using in response?  It could respond "unknown" for 
those situations where the server has no control over charsets used.

>   1) include this list to the SSH_MSG_KEXINIT packet (we really don't need 
>      additinal messages)

The problem with including it in KEXINIT is it's a client->server message
-- it's not a symmetric message.  But I suppose the client could simply
ignore what the server says in that field so that doesn't bother me.

>   2) change all SHOULDs to MAYs (the server is allowed to ignore the list)

I can live with that.

> That might create an name space overlap. What if the host has an user
> named "anonymous" which actually DOES require real authentication ? 

The problem I have with the status quo is any attempt to gain a list will
fall through to authenticated state if the server allows anonymous access. 
So I'll make a few suggestions:

(1) Have a "list" message distinct from "none".  The "list" message always
fails and returns the list of authentication mechanisms supported.

(2) Mention a "convention" that "anonymous" MAY be used as an anonymous
access account which permits login with any password.

(3) Always send a USERAUTH_BANNER although the message may be empty. 
Include a list of supported authentication mechanisms. 

> > TN3270 is built on top of the telnet protocol which requires urgent data
> > for IP (Interrupt Process) and "synch" support.  See RFC 1123.  I suppose
> > it might be possible to use without it, but it's technically required by
> > the standards.
> 
> Ok. We'll define :
> 
>   #define SSH_EXTENDED_DATA_URGENT 2
> 
> for urgent data (this will go to 3.2, connect). Obviously this will only
> be implemented if the TCP stack and OS support it. 

Well, someone else has stated that TN3270 interoperates just fine without
urgent data, despite what the standards say (the telnet standards are
pretty old and tired). That would leave telnet as the only protocol which
uses urgent data, and I know from experience that it doesn't require
urgent data to interoperate successfully.  Sounds like this isn't strictly
necessary so I'll leave the choice to you.

> The flow control in unices does more than just put the output to a
> buffer.. typically the process is freezed when the buffer is full. A
> client-side flow control mechanism can't do this. 

Wouldn't SSH freeze the process when the window fills up?

		- Chris

From owner-ietf-ssh@clinet.fi  Wed Oct 29 21:58:50 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 VAA10430;
	Wed, 29 Oct 1997 21:58:49 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id VAA08281;
	Wed, 29 Oct 1997 21:58:48 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id VAA10830
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 21:56:02 +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 VAA10551
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 21:52:37 +0200 (EET)
Received: from eleanor.innosoft.com ("port 48053"@ELEANOR.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-10 #8694)
 with SMTP id <01IPDHGDE2FI9JEA9G@INNOSOFT.COM> for ietf-ssh@clinet.fi; Wed,
 29 Oct 1997 09:31:29 PDT
Date: Wed, 29 Oct 1997 09:33:39 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: New secsh -02 drafts
In-reply-to: <199710291225.OAA13670@shadows.cs.hut.fi>
To: Tero Kivinen <kivinen@niksula.hut.fi>
Cc: Markku-Juhani Saarinen <mjos@ssh.fi>,
        IETF Secure Shell list <ietf-ssh@clinet.fi>
Message-id: <Pine.SOL.3.95.971029092749.15570D-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: 1301
Lines: 27

On Wed, 29 Oct 1997, Tero Kivinen wrote:
> Note, that using ip address in those messages doesn't have any problem
> with ipv6, the ip address can either be ipv4 address (192.168.7.38) or
> ipv6 address (0000:0000:0000:0000:0000:0000:C0A8:0726). The originator
> ip address is mainly used by server for logging purposes and it may do
> some checks for them (for example require that the x11 originator is
> 127.0.0.1 or 0::7F00:0001). 

You need to explicitly state IPv6 addresses are permitted there in order
to get past the IESG, I suspect.

> I think most of the systems don't use them, but because most unix
> systems will have struct winsize that has that information and we need
> to send the rows and columns in characters anyway, we can send the
> pixel information also in case somebody really uses it for something.
> They can always be 0 if not meaning full or unknown. 

There still needs to be a definition of what the pixel information
represents.  Is it the drawable area of a 4014 emulator window?  Is it the
drawable area of the terminal window?  Is it the number of pixels in the
character cell area of the terminal window (and thus can be used to
determine the number of pixels in each character)?  Is it the entire
client window area, including the border decorations?

		- Chris


From owner-ietf-ssh@clinet.fi  Wed Oct 29 20:50:33 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 UAA09964;
	Wed, 29 Oct 1997 20:50:32 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id UAA08149;
	Wed, 29 Oct 1997 20:50:31 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id UAA04861
	for ietf-ssh-outgoing; Wed, 29 Oct 1997 20:33:51 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from tai.cisco.com (tai.cisco.com [171.69.160.33])
	by hauki.clinet.fi (8.8.7/8.8.6) with ESMTP id UAA04840
	for <ietf-ssh@clinet.fi>; Wed, 29 Oct 1997 20:33:29 +0200 (EET)
Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by tai.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id NAA23229; Wed, 29 Oct 1997 13:31:58 -0500 (EST)
Date: Wed, 29 Oct 1997 13:31:58 -0500 (EST)
From: Michael Boe <mboe@cisco.com>
Reply-To: Michael Boe <mboe@cisco.com>
Subject: Re: New secsh -02 drafts
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
cc: ietf-ssh@clinet.fi
In-Reply-To: <199710291449.JAA28963@Twig.Rodents.Montreal.QC.CA>
Message-ID: <ML-3.3.878149918.6521.mboe@mboe-home-ss20.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2493
Lines: 48

> >>> What's obviously missing is the SSH_EXTENDED_DATA_URGENT for TCP
> >>> urgent data.  I don't really like urgent data, but [...]
> > Urgent data byte is used by the TELNET Synch/DM command.
> 
> "Urgent data byte"?  That doesn't sound like quite what TCP has.  What
> it has an urgent pointer, which marks a point between two octets in the
> data stream.  Everything from the current point up to the urgent
> pointer is considered urgent data.  In particular, if you have queued
> data and do an urgent send, then do another urgent send before the
> previous one has actually made it to the peer, then there is no record
> kept of the first urgent send.  The peer may have seen a packet or two
> with the intermediate value of the urgent pointer, but it also may not.
> 
> Someone at Berkeley ("on either drugs or a shaky understanding of TCP",
> as I usually say) decided to take the urgent pointer and treat it as
> pointing at one of the octets it points between, making that octet into
> an out-of-band byte.  This kinda-sorta-mostly works, as long as your
> out-of-band data rate is low with respect to the bandwidth*delay
> product of the connection.  This was true with Ethernetted VAXen at
> Berkeley; it is not true in the current Internet.
> 
> Now, I may be preaching to the choir here; it may be that everyone
> already knows this.  And admittedly I haven't actually read the draft
> containing this stuff.  But this SSH_EXTENDED_DATA_URGENT, and the talk
> about "urgent data byte", make it sound as though it's just a renaming
> of the out-of-band data stream concept, in which case my remarks are
> applicable.

I've got no trouble with you've said.  Just realize that TELNET ran over a few
more protocols originally than TCP, and that I was talking in terms of
TELNET-layer, not TCP-layer.

> 
> > Indeed, proper observance of what's implied by the urgent dataflag
> > (strip all data until DM is found) can probably be considered harmful
> > in a stateful environment like TN3270.
> 
> Or the TELNET NVT, for that matter.  You can perhaps finesse this by
> considering everything, even vanilla text, to fall under the "other
> site-defined signals which can be acted on without delaying the scan of
> the data stream" phrase in RFC854.

Agree. Though most implementations I've seen "finesse" this by just not doing
OOB signalling at all.  Does anybody know of TELNET/TN3270 implementations that
*do* attempt to take advantage of the urgent dataflag/DM capability?

/msb

From owner-ietf-ssh@clinet.fi  Fri Oct 31 13:32:13 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 NAA29480;
	Fri, 31 Oct 1997 13:32:12 +0200 (EET)
Received: from hauki.clinet.fi (hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id NAA14861;
	Fri, 31 Oct 1997 13:32:11 +0200 (EET)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.7/8.8.6) id NAA24861
	for ietf-ssh-outgoing; Fri, 31 Oct 1997 13:17:55 +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 NAA24839
	for <ietf-ssh@clinet.fi>; Fri, 31 Oct 1997 13:17:48 +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 NAA14808;
	Fri, 31 Oct 1997 13:17:46 +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 NAA29345;
	Fri, 31 Oct 1997 13:17:39 +0200 (EET)
Date: Fri, 31 Oct 1997 13:17:39 +0200 (EET)
From: Markku-Juhani Saarinen <mjos@ssh.fi>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
cc: ietf-ssh@clinet.fi
Subject: Re: New secsh -02 drafts
In-Reply-To: <199710291422.JAA28805@Twig.Rodents.Montreal.QC.CA>
Message-ID: <Pine.NEB.3.95q.971031130426.7042F-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: 769
Lines: 23

On Wed, 29 Oct 1997, der Mouse wrote:

> >> Then I suggest you not use "none" as anonymous and instead designate
> >> a special user name (e.g., "anonymous") at least by convention.
> > That might create an name space overlap.  What if the host has an
> > user named "anonymous" which actually DOES require real
> > authentication ?
> 
> The same applies to "none".  I'm in agreement with the person who said
> that anonymous login semantics needs to be independent of any specific
> username (or usernames).

I agree. 

The "none" referred above is not an username. See userauth, "2.3 The
none Authentication Request" (p. 4). The current draft is independent of
any specific usernames.

- mj

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


