From owner-ietf-ssh@clinet.fi  Fri Aug  1 18:55:02 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.6/8.8.6/EPIPE-1.9) with ESMTP id SAA08710;
	Fri, 1 Aug 1997 18:55:01 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.6/8.8.6/EPIPE-1.11) with ESMTP id SAA25982;
	Fri, 1 Aug 1997 18:54:57 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id SAA19480
	for ietf-ssh-outgoing; Fri, 1 Aug 1997 18:44:55 +0300 (EET DST)
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 SMTP id SAA19472
	for <ietf-ssh@clinet.fi>; Fri, 1 Aug 1997 18:44:50 +0300 (EET DST)
Received: from ietf.ietf.org by ietf.org id aa14022; 1 Aug 97 10:09 EDT
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-01.txt
Date: Fri, 01 Aug 1997 10:09:19 -0400
Message-ID:  <9708011009.aa14022@ietf.org>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2542
Lines: 85

--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
	Filename	: draft-ietf-secsh-transport-01.txt
	Pages		: 22
	Date		: 1997-07-31
	
This document describes the SSH 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.

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-01.txt'.
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-transport-01.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

OtherAccess
Content-Type:  Message/External-body;
	access-type='mail-server';
	server='mailserv@ds.internic.net'
	
Content-Type: text/plain
Content-ID:	<19970731162435.I-D@ietf.org>

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

--OtherAccess
Content-Type:	Message/External-body;
	name='draft-ietf-secsh-transport-01.txt';
	site='ds.internic.net';
	access-type='anon-ftp';
	directory='internet-drafts'
	
Content-Type: text/plain
Content-ID:	<19970731162435.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Fri Aug  1 18:55:02 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.6/8.8.6/EPIPE-1.9) with ESMTP id SAA08711;
	Fri, 1 Aug 1997 18:55:01 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.6/8.8.6/EPIPE-1.11) with ESMTP id SAA25983;
	Fri, 1 Aug 1997 18:54:58 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id SAA19871
	for ietf-ssh-outgoing; Fri, 1 Aug 1997 18:51:06 +0300 (EET DST)
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 SMTP id SAA19863
	for <ietf-ssh@clinet.fi>; Fri, 1 Aug 1997 18:51:00 +0300 (EET DST)
Received: from ietf.ietf.org by ietf.org id aa14086; 1 Aug 97 10:09 EDT
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-01.txt
Date: Fri, 01 Aug 1997 10:09:26 -0400
Message-ID:  <9708011009.aa14086@ietf.org>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2682
Lines: 86

--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
	Filename	: draft-ietf-secsh-userauth-01.txt
	Pages		: 12
	Date		: 1997-07-31
	
This documents describes the SSH authentication protocol.  It is used to 
prove that the client is authorized access the requested service with 
the supplied user name.  This authorization can be demonstrated through 
possession of a password, through possession of a key, by authenticating 
the client host and user, by some other method, or a combination of these.

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-01.txt'.
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-userauth-01.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

OtherAccess
Content-Type:  Message/External-body;
	access-type='mail-server';
	server='mailserv@ds.internic.net'
	
Content-Type: text/plain
Content-ID:	<19970731162651.I-D@ietf.org>

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

--OtherAccess
Content-Type:	Message/External-body;
	name='draft-ietf-secsh-userauth-01.txt';
	site='ds.internic.net';
	access-type='anon-ftp';
	directory='internet-drafts'
	
Content-Type: text/plain
Content-ID:	<19970731162651.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Fri Aug  1 19:09:19 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.6/8.8.6/EPIPE-1.9) with ESMTP id TAA09897;
	Fri, 1 Aug 1997 19:09:19 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by ssh.fi (8.8.6/8.8.6/EPIPE-1.11) with ESMTP id TAA26019;
	Fri, 1 Aug 1997 19:09:18 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id TAA20748
	for ietf-ssh-outgoing; Fri, 1 Aug 1997 19:08:45 +0300 (EET DST)
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 SMTP id TAA20736
	for <ietf-ssh@clinet.fi>; Fri, 1 Aug 1997 19:08:32 +0300 (EET DST)
Received: from ietf.ietf.org by ietf.org id aa14332; 1 Aug 97 10:10 EDT
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-01.txt
Date: Fri, 01 Aug 1997 10:10:00 -0400
Message-ID:  <9708011010.aa14332@ietf.org>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2560
Lines: 85

--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
	Filename	: draft-ietf-secsh-connect-01.txt
	Pages		: 17
	Date		: 1997-07-31
	
This document describes the SSH connection protocol.  It multiplexes a
single encrypted tunnel into a number of channels (interactive sessions,
forwarded TCP/IP ports, X11 connections, etc).  It is intended to run
above the SSH user authentication layer.

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-01.txt'.
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-connect-01.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

OtherAccess
Content-Type:  Message/External-body;
	access-type='mail-server';
	server='mailserv@ds.internic.net'
	
Content-Type: text/plain
Content-ID:	<19970731163606.I-D@ietf.org>

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

--OtherAccess
Content-Type:	Message/External-body;
	name='draft-ietf-secsh-connect-01.txt';
	site='ds.internic.net';
	access-type='anon-ftp';
	directory='internet-drafts'
	
Content-Type: text/plain
Content-ID:	<19970731163606.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Sun Aug 17 23:41:02 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 XAA08942;
	Sun, 17 Aug 1997 23:40:56 +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 XAA00206;
	Sun, 17 Aug 1997 23:40:55 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id XAA00155
	for ietf-ssh-outgoing; Sun, 17 Aug 1997 23:27:17 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id XAA00131
	for <ietf-ssh@clinet.fi>; Sun, 17 Aug 1997 23:27:01 +0300 (EET DST)
Received: from unix15.andrew.cmu.edu (UNIX15.ANDREW.CMU.EDU [128.2.72.55])
	by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id QAA19774
	for <ietf-ssh@clinet.fi>; Sun, 17 Aug 1997 16:25:18 -0400 (EDT)
Date: Sun, 17 Aug 1997 16:25:18 -0400 (EDT)
From: Michael Poole <poole+@andrew.cmu.edu>
Reply-To: Michael Poole <poole+@andrew.cmu.edu>
To: ietf-ssh@clinet.fi
Subject: comments on transport layer protocol
Message-ID: <Pine.SOL.3.95L.970817154206.3698B-100000@unix15.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3928
Lines: 77

	Here are some comments and questions on the newer SSH Transport
Layer Protocol draft RFC; these are mostly documentation things (I also
noted a  few typos, but haven't included them here, since they're easy
enough to find and correct). As a disclaimer, I don't have a lot of
crypto background, so some of these might be obvious to someone with
more experience.

Sec. 2.5: Signed mpints are mentioned, but I don't see any reference to
them elsewhere; this raises the question of how to store negative mpints.
I'd presume signed-magnitude, with the sign bit counted in the number of
bits.

Sec. 3: User-defined algorithm names are allowed to "contain any
non-control characters except at signs and commas".  Exactly what a
"control character" is isn't mentioned; is this the traditional usage
meaning anything less than 0x20?

Sec. 4.3.1: In sec. 4.2, the protocol version is "used to trigger
compatible extensions."  However, in sec. 4.3.1, the protocol version is
used to detect "old" protocol versions without saying how the proto
version string should be parsed -- how should a server supporting version
"2.0" treat a client supporting version "2.0.3" or "2.0foo" (if these are 
used to denote such compatible extensions)?

Sec. 5: The description of padding doesn't mention if the padding should
be random bytes or if there would be a weakness introduced by using all
0's; I presume any implementor would want to avoid a known-plaintext
attack, so it's not really an issue.
Also, there's a sentence in the first discussion paragraph ("In
particular, one has to be extra careful when computing the amount of
padding...") that (to me, at least) only made sense for the old wire
protocol, which used vlint32's to mark length, but does not make sense
with uint32's marking length.

Sec. 5.2: The second paragraph mentions total packet size limits and
maximum uncompressed payload sizes, but it is never mentioned how these
are determined.  Minimum values for these are established in 5.1, but
"implementations are ... encouraged to support longer packets" and no
method for negotiating larger packets is described.

Sec. 6: If a wrong guess is made about the kex method, the initial kex
packet is resent; it isn't clear whether or not the packet sequence number
is incremented when the kex packet is resent, although I assume it is.
Additionally, there are actually two key exchange methods described later,
double-encrypting-sha and diffie-hellman, although the latter isn't given
an official name or status.

Sec. 6.1: In the description of the first_kex_packet_follows field (second
paragraph), it isn't explicit how each side determines that they should
send an initial packet in the kex method.  Reading the DH and
double-encrypting methods makes it clear that whether a first kex packet
follows the SSH_MSG_KEXINIT packet depends on the role and the guessed kex
method; perhaps that could or should be noted explicitly.

Sec. 6.2: The hash algorithm used for the DH key exchange is hard-wired to
be SHA-1; I presume this is for the same reasons as noted in Sec. 6.3.2
about the double-encrypting-sha kex method.
In step 2 of the key exchange ("B generates a random number..."), B sends
the concatenation of K_B, f and s to A, but the packet description shows
them separated into different fields.

Here my crypto ignorance shows its head:
g is specified to be a generator of p, of order q; my group/field 
mathematics knowledge says that this means q==p.  q is also not mentioned
beyond the fact that it is the order of g.  Could the "and q is the order
of the generator" phrase be dropped to improve clarity?

Sec. 9.2: I may be missing something, but is there any point in having a
message that must be ignored by the client?  It could be used to obfuscate
any attempts to guess usage based on traffic patterns, I suppose, but that
seems tenuous.

	That's it; hopefully this will be useful to somebody.

Michael Poole


From owner-ietf-ssh@clinet.fi  Mon Aug 18 01:02: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 BAA10098;
	Mon, 18 Aug 1997 01:02:27 +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 BAA00326;
	Mon, 18 Aug 1997 01:02:24 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id BAA19367
	for ietf-ssh-outgoing; Mon, 18 Aug 1997 01:01:07 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from santra.hut.fi (santra.hut.fi [130.233.224.1])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id BAA19357
	for <ietf-ssh@clinet.fi>; Mon, 18 Aug 1997 01:01:03 +0300 (EET DST)
Received: from shadows.cs.hut.fi (shadows.cs.hut.fi [130.233.192.99])
	by santra.hut.fi (8.8.7/8.8.7) with ESMTP id BAA29319;
	Mon, 18 Aug 1997 01:01:02 +0300 (EET DST)
Received: (from kivinen@localhost) by shadows.cs.hut.fi (8.7.6/8.7.3) id BAA11480; Mon, 18 Aug 1997 01:01:27 +0300 (EET DST)
Date: Mon, 18 Aug 1997 01:01:27 +0300 (EET DST)
Message-Id: <199708172201.BAA11480@shadows.cs.hut.fi>
From: Tero Kivinen <kivinen@niksula.hut.fi>
To: Michael Poole <poole+@andrew.cmu.edu>
Cc: ietf-ssh@clinet.fi
Subject: comments on transport layer protocol
In-Reply-To: <Pine.SOL.3.95L.970817154206.3698B-100000@unix15.andrew.cmu.edu>
References: <Pine.SOL.3.95L.970817154206.3698B-100000@unix15.andrew.cmu.edu>
Organization: Helsinki University of Technology
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-Edit-Time: 19 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 5905
Lines: 129

Michael Poole writes:

There have already been lots of changes to drafts after last ietf, so
you all should probably wait a little so Tatu can finish them and send
them to list. Most of the stuff is already written, so it shouldn't
take long. 

> Sec. 2.5: Signed mpints are mentioned, but I don't see any reference to

The mpint definations have changed now. If I remember correctly they
are now always signed. 

> Sec. 3: User-defined algorithm names are allowed to "contain any
> non-control characters except at signs and commas".  Exactly what a
> "control character" is isn't mentioned; is this the traditional usage
> meaning anything less than 0x20?

This has been changed to "printable us-ascii characters, except
at-signs and commas". I think that is quite clear (0x20-0x7e). 

> Sec. 4.3.1: In sec. 4.2, the protocol version is "used to trigger
> compatible extensions."  However, in sec. 4.3.1, the protocol version is
> used to detect "old" protocol versions without saying how the proto
> version string should be parsed -- how should a server supporting version
> "2.0" treat a client supporting version "2.0.3" or "2.0foo" (if these are 
> used to denote such compatible extensions)?

The protocol version (2.0) is only incremented if uncompatible changes
are made to protocol. The software version number is just like the
those in http, version number and text describing the software
version. With this if we know this software version "2.0.3 ssh-foo for
unix" does something wrong, we can detect the exact version number and
do some kind of bug emulation code if we really want that. 

> Sec. 5: The description of padding doesn't mention if the padding should
> be random bytes or if there would be a weakness introduced by using all

New version says random bytes. 

> Also, there's a sentence in the first discussion paragraph ("In
> particular, one has to be extra careful when computing the amount of
> padding...") that (to me, at least) only made sense for the old wire
> protocol, which used vlint32's to mark length, but does not make sense
> with uint32's marking length.

Old junk left from vlint32 stuff, already removed. 

> Sec. 5.2: The second paragraph mentions total packet size limits and
> maximum uncompressed payload sizes, but it is never mentioned how these
> are determined.  Minimum values for these are established in 5.1, but
> "implementations are ... encouraged to support longer packets" and no
> method for negotiating larger packets is described.

I think that paragrap was removed entirely. Because there isn't any
fixed packet limit any more, only minimum limit, so the there isn't
any limits for compressed packets either.

> Sec. 6: If a wrong guess is made about the kex method, the initial kex
> packet is resent; it isn't clear whether or not the packet sequence number
> is incremented when the kex packet is resent, although I assume it is.

New version says the sequence number is incremented every time packet
is sent to wire. So it is incremented if this first key exchange
depended packet is send again. 

> Additionally, there are actually two key exchange methods described later,
> double-encrypting-sha and diffie-hellman, although the latter isn't given
> an official name or status.

The consesus in the ietf was to remove double-encrypting-sha. It might
be added later with separate draft though. 

> Sec. 6.1: In the description of the first_kex_packet_follows field (second
> paragraph), it isn't explicit how each side determines that they should
> send an initial packet in the kex method.  Reading the DH and

It is up to the implementator to decide when the implementation should
send the packet. Because there is now only one key exchange method
that guess will probably be correct, so I think implementators should
always send the first key exchange method depended packet after
kexinit. 

> double-encrypting methods makes it clear that whether a first kex packet
> follows the SSH_MSG_KEXINIT packet depends on the role and the guessed kex
> method; perhaps that could or should be noted explicitly.

I think most of that text is already rewritten so better wait for the
new draft. 

> Sec. 6.2: The hash algorithm used for the DH key exchange is hard-wired to
> be SHA-1; I presume this is for the same reasons as noted in Sec. 6.3.2
> about the double-encrypting-sha kex method.

Yes. In the next version the hash_algorithm_field is removed from the
kexinit packet altogether, and it was added to the key exchange name.
The hash_algorithm_field was only used to generate the keys and the
key exchange method used fixed kex depended hash. Now they both use
same fixed kex depended hash.

> In step 2 of the key exchange ("B generates a random number..."), B sends
> the concatenation of K_B, f and s to A, but the packet description shows
> them separated into different fields.

The generic Diffie-Hellman key exchange description didn't really talk
anything about the exact packet contents, it only described the
overall framework. 

> Here my crypto ignorance shows its head:
> g is specified to be a generator of p, of order q; my group/field 
> mathematics knowledge says that this means q==p.  q is also not mentioned
> beyond the fact that it is the order of g.  Could the "and q is the order
> of the generator" phrase be dropped to improve clarity?

I think Tatu can look that more tomorrow. 

> Sec. 9.2: I may be missing something, but is there any point in having a
> message that must be ignored by the client?  It could be used to obfuscate
> any attempts to guess usage based on traffic patterns, I suppose, but that
> seems tenuous.

Yes, it is there so client/server can make traffic analysis more
difficult. 

> 	That's it; hopefully this will be useful to somebody.

Sure.
-- 
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  Mon Aug 18 19:52:05 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) with ESMTP id TAA20060;
	Mon, 18 Aug 1997 19:51:28 +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 TAA02687;
	Mon, 18 Aug 1997 19:51:27 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id TAA06905
	for ietf-ssh-outgoing; Mon, 18 Aug 1997 19:31:32 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id TAA06674
	for <ietf-ssh@clinet.fi>; Mon, 18 Aug 1997 19:29:26 +0300 (EET DST)
Received: from borg.eos.home.net ([24.0.16.111]) by poptart.corp.home.net
          (Netscape Mail Server v2.02) with ESMTP id AAA24937;
          Mon, 18 Aug 1997 09:25:07 -0700
Received: (from rja@localhost) by borg.eos.home.net (8.7.5/8.7.3) id JAA23549; Mon, 18 Aug 1997 09:25:07 -0700 (PDT)
From: rja@corp.home.net (Ran Atkinson)
Message-Id: <970818092506.ZM23547@borg.eos.home.net>
Date: Mon, 18 Aug 1997 09:25:06 -0700
In-Reply-To: Tero Kivinen <kivinen@niksula.hut.fi>
        "comments on transport layer protocol" (Aug 18,  1:01)
References: <Pine.SOL.3.95L.970817154206.3698B-100000@unix15.andrew.cmu.edu> 
	<199708172201.BAA11480@shadows.cs.hut.fi>
X-Mailer: Z-Mail (4.0.1 13Jan97)
To: Tero Kivinen <kivinen@niksula.hut.fi>
Subject: Re: comments on transport layer protocol
Cc: ietf-ssh@clinet.fi
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4035
Lines: 89

On Aug 18  1:01, Tero Kivinen wrote:

> Sec. 3: User-defined algorithm names are allowed to "contain any
> non-control characters except at signs and commas".  Exactly what a
> "control character" is isn't mentioned; is this the traditional usage
> meaning anything less than 0x20?

% This has been changed to "printable us-ascii characters, except
% at-signs and commas". I think that is quite clear (0x20-0x7e).

Please add an explicit reference to "ANSI X3.4 (1986)" for US-ASCII.
Alternately, one could cite "control characters in the ISO-646
Invariant Code Set" if one preferred.  The IETF historically has
used ANSI X3.4 as its default character set, but in this particular
aspect (i.e. control characters) ISO-646 and ANSI X3.4 are identical.

Also, I believe it would be useful to specifically mention "0x00 through
0x20" as non-printing characters.  In some character sets that are
commonly mistaken for US-ASCII (specifically the Wintel PC character
sets), there are printing characters inside the control character
space of US-ASCII.  Making the spec crystal clear seems sensible. :-)

% The protocol version (2.0) is only incremented if uncompatible changes
% are made to protocol. The software version number is just like the
% those in http, version number and text describing the software
% version. With this if we know this software version "2.0.3 ssh-foo
% for unix" does something wrong, we can detect the exact version
% number and do some kind of bug emulation code if we really want that.

The full syntax of the protocol version needs to be specified in
formally in something like BNF so that everyone knows how to build
their parser.

% New version says random bytes.

It also needs to define what "random bytes" mean in this context.
Is "statistically random" sufficient or is "cryptographically
random" required ?  If the latter, RFC-1750 should be cited for
additional information on obtaining cryptographic randomness.

> Sec. 6.1: In the description of the first_kex_packet_follows field
>(second paragraph), it isn't explicit how each side determines that
> they should send an initial packet in the kex method.  Reading the
> DH and

% It is up to the implementator to decide when the implementation should
% send the packet.

That seems to be an unwise decision.  For interoperability, the
protocol needs to specify the full behaviour.  Aside from that,
the absence of full specification makes it tremendously more difficult
to perform formal analysis on the key exchange protocol using BAN logic
or other similar tools.

% Because there is now only one key exchange method that guess
% will probably be correct, so I think implementators should
% always send the first key exchange method depended packet after
% kexinit.

If an implementation should do this for all key exchange methods
for all time, it should be documented as a global rule.

If an implementation should do this ONLY IF the currently defined
key exchange method is in use, then it should be clearly defined
as a rule that applies only when that key exchange method is in
use.

In general, I believe that the key exchange method will need to vary
with time.  The history of published key management technologies in
the literature makes it very clear that the IETF should seek
algorithm-independence in its cryptography and protocol-independence
in its key management strategies.  This was one of the most important
design constraints for ESP/AH.

> Sec. 9.2: I may be missing something, but is there any point in having
> a message that must be ignored by the client?  It could be used
> to obfuscate any attempts to guess usage based on traffic patterns,
> I suppose, but that seems tenuous.

% Yes, it is there so client/server can make traffic analysis more
% difficult.

If one considers [VK83], it becomes fairly clear that trying to
prevent traffic analysis at an upper-layer in the protocol stack
is largely a futile exercise.  This appears to be additional protocol
complexity for negligible actual benefit.

Ran
rja@home.net
From owner-ietf-ssh@clinet.fi  Tue Aug 19 18:40: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 SAA09781;
	Tue, 19 Aug 1997 18:40:27 +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 SAA06187;
	Tue, 19 Aug 1997 18:40:26 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id SAA24152
	for ietf-ssh-outgoing; Tue, 19 Aug 1997 18:28:08 +0300 (EET DST)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id SAA24087
	for <ietf-ssh@clinet.fi>; Tue, 19 Aug 1997 18:27:26 +0300 (EET DST)
Received: from bcarsde5.ott.bnr.ca (actually 47.80.6.26) by bcarsde4.localhost;
          Tue, 19 Aug 1997 11:25:07 -0400
Received: from bftzh114.ott.bnr.ca by bcarsde5.ott.bnr.ca;
          Tue, 19 Aug 1997 11:21:55 -0400
Received: by bftzh114.ott.bnr.ca (1.37.109.16/16.2) id AA089623997;
          Tue, 19 Aug 1997 11:19:57 -0400
From: "Marcus Leech" <mleech@nortel.ca>
Message-Id: <199708191519.AA089623997@bftzh114.ott.bnr.ca>
Subject: Meeting report: SECSH working group
To: ietf-ssh@clinet.fi
Date: Tue, 19 Aug 1997 11:19:56 -0500 (EDT)
Cc: jis@MIT.EDU
Organization: Nortel Technologies, System Security Services
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1510
Lines: 38

The Secure Shell working group had a meeting at the 39th IETF in Munich.

Marcus Leech was acting as WG chair, due to the absence of Perry Metzger.

The agenda for the meeting was the discussion of the following drafts:

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

Tatu Ylonen presented these three drafts, and mostly led the discussion.

The group generally agreed on the following points:

  - Mandate the use of the signed Diffie Hellman key exchange,
    and deprecate the dual-RSA key exchange

  - Mandate the use of P-K-based authentication, and make
    password-based auth SHOULD

  - Mandate 3DES for symmetric crypto

  - Mandate DSS for digital signature

The documents require an overall "architecture" document, and perhaps
  userauth/connect could reasonably be merged.  The existing documents
  need to be more implementation oriented, perhaps with diagrams.

The TLS subject was raised, and it was generally agreed that TLS simply
  doesn't offer a suitable framework for SECSH to use at this time.

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M86, MS 012, FITZ
Systems Security Architect               Phone: (ESN) 393-9145  +1 613 763 9145
Messaging and Security Infrastructure    Fax:   (ESN) 395-1407  +1 613 765 1407
Nortel Technology              mleech@nortel.ca
-----------------Expressed opinions are my own, not my employer's------
From owner-ietf-ssh@clinet.fi  Tue Aug 19 20:02: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 UAA10591;
	Tue, 19 Aug 1997 20:01:56 +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 UAA06345;
	Tue, 19 Aug 1997 20:01:55 +0300 (EET DST)
Received: (from majordom@localhost)
	by hauki.clinet.fi (8.8.6/8.8.6) id TAA29680
	for ietf-ssh-outgoing; Tue, 19 Aug 1997 19:42:22 +0300 (EET DST)
Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id TAA29624
	for <ietf-ssh@clinet.fi>; Tue, 19 Aug 1997 19:41:45 +0300 (EET DST)
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.6/8.6.12) with SMTP id MAA28836; Tue, 19 Aug 1997 12:40:15 -0400 (EDT)
Message-Id: <199708191640.MAA28836@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: "Marcus Leech" <mleech@nortel.ca>
cc: ietf-ssh@clinet.fi
Subject: Re: Meeting report: SECSH working group 
In-reply-to: Your message of "Tue, 19 Aug 1997 11:19:56 CDT."
             <199708191519.AA089623997@bftzh114.ott.bnr.ca> 
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 19 Aug 1997 12:40:13 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 331
Lines: 10


"Marcus Leech" writes:
> Marcus Leech was acting as WG chair, due to the absence of Perry Metzger.

I want to take this opportunity to thank Marcus for stepping in for
me, especially given that he already had plenty on his hands with his
own working group. It was really great of him to help out like
this. Thanks, Marcus!

Perry
