From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 3 05:18:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17457 for ; Tue, 3 May 2005 05:18:30 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 90A7551A8; Tue, 3 May 2005 09:18:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id B688F517A for ; Tue, 3 May 2005 09:18:22 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id FAA10846; Tue, 3 May 2005 05:18:15 -0400 (EDT) From: der Mouse Message-Id: <200505030918.FAA10846@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 3 May 2005 05:14:15 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: draft-harris-ssh-rsa-kex-01 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I was just working on implementing draft-harris-ssh-rsa-kex-01, and I ran into a question. Everything is clear for the first kex. But what about re-keying? Is the server reusing the same K_T as for a previous kex a MUST, SHOULD, MAY, SHOULD NOT, or MUST NOT? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 3 07:01:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00809 for ; Tue, 3 May 2005 07:01:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D3A3051BA; Tue, 3 May 2005 11:00:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id D44155175 for ; Tue, 3 May 2005 11:00:54 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DSv93-0002im-00 for ietf-ssh@netbsd.org; Tue, 03 May 2005 12:00:53 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-01 In-Reply-To: <200505030918.FAA10846@Sparkle.Rodents.Montreal.QC.CA> References: <200505030918.FAA10846@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Tue, 03 May 2005 12:00:53 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200505030918.FAA10846@Sparkle.Rodents.Montreal.QC.CA> you write: >I was just working on implementing draft-harris-ssh-rsa-kex-01, and I >ran into a question. > >Everything is clear for the first kex. But what about re-keying? Is >the server reusing the same K_T as for a previous kex a MUST, SHOULD, >MAY, SHOULD NOT, or MUST NOT? My intention was that different key exchanges (whether in the same or different sessions) SHOULD use different RSA keys, largely so as to limit that number of session keys that an attacker gains access to by cracking a single RSA key. I seem to have forgotten to actually write that down anywhere, though. I'll fix that in -02. This does make rekeying a bit of a pain for a single-threaded (or rather, single-thread-per-session) server, but that's why it's a SHOULD. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 3 23:47:41 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10628 for ; Tue, 3 May 2005 23:47:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D0C135221; Wed, 4 May 2005 03:47:34 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 76D02517D for ; Wed, 4 May 2005 03:47:32 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA14791; Tue, 3 May 2005 23:47:31 -0400 (EDT) From: der Mouse Message-Id: <200505040347.XAA14791@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 3 May 2005 23:41:59 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex-01 In-Reply-To: References: <200505030918.FAA10846@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> But what about re-keying? Is the server reusing the same K_T as for >> a previous kex a MUST, SHOULD, MAY, SHOULD NOT, or MUST NOT? > My intention was that different key exchanges (whether in the same or > different sessions) SHOULD use different RSA keys, largely so as to > limit that number of session keys that an attacker gains access to by > cracking a single RSA key. I seem to have forgotten to actually > write that down anywhere, though. I'll fix that in -02. That would be good. Since it appears to be designed as an adaptation of historical ssh1 practice to the ssh2 world, I would have assumed there was an expectation that different sessions share the same K_T when they occurred within reasonable temporal proximity to one another (since something very much like that is what ssh1 did). > This does make rekeying a bit of a pain for a single-threaded (or > rather, single-thread-per-session) server, but that's why it's a > SHOULD. It's also a pain for any server running on hardware slow enough that generating a key is an expensive operation. I suspect what I'll do is simply use the most current available key at any time (blocking if no key has been generated yet) and kick off a new key generation in the background whenever a key is used. Arranging to background key generation should be interesting, but, I believe, thoroughly solvable.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 9 15:55:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26402 for ; Mon, 9 May 2005 15:55:12 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C60AE3A515; Mon, 9 May 2005 19:55:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 9431A3A504 for ; Mon, 9 May 2005 19:54:58 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26315; Mon, 9 May 2005 15:54:56 -0400 (EDT) Message-Id: <200505091954.PAA26315@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-gsskeyex-09.txt Date: Mon, 09 May 2005 15:54:55 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --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 : GSSAPI Authentication and Key Exchange for the Secure Shell Protocol Author(s) : J. Hutzelman, et al. Filename : draft-ietf-secsh-gsskeyex-09.txt Pages : 34 Date : 2005-5-9 The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) [GSSAPI] provides security services to callers in a mechanism- independent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-gsskeyex-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-gsskeyex-09.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2005-5-9160027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-9160027.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 9 17:25:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13484 for ; Mon, 9 May 2005 17:25:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 18FD63A3C2; Mon, 9 May 2005 21:25:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (unknown [IPv6:3ffe:1ce1:0:12:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id 88F993A3AE for ; Mon, 9 May 2005 21:25:29 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 293FFE0063; Mon, 9 May 2005 17:25:29 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: draft-harris-ssh-arcfour-fixes-02.txt: should this be a secsh draft From: Sam Hartman Date: Mon, 09 May 2005 17:12:06 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi. The IESG has received a request to publish draft-harris-ssh-arcfour-fixes-02 as a proposed standard. I'm aware that this draft has been discussed by participants in the secsh working group. Does the secsh working group wish to adopt this draft as a work item or shall I proceed with this draft as an individual submission? (There's a third option: the working group could argue that this draft should not be published at all. Based on discussion on the list I don't expect this option to be taken.) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 9 19:47:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28538 for ; Mon, 9 May 2005 19:47:26 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5D7C83A544; Mon, 9 May 2005 23:47:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by mail.netbsd.org (Postfix) with ESMTP id AFCFE3A3C2 for ; Mon, 9 May 2005 23:47:22 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from virgo.cus.cam.ac.uk ([131.111.8.20]:36321) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1DVHy3-0006jW-42 (Exim 4.51) for ietf-ssh@netbsd.org (return-path ); Tue, 10 May 2005 00:47:19 +0100 Received: from bjh21 (helo=localhost) by virgo.cus.cam.ac.uk with local-esmtp (Exim 4.51) id 1DVHy2-00052S-Um for ietf-ssh@netbsd.org; Tue, 10 May 2005 00:47:18 +0100 Date: Tue, 10 May 2005 00:47:18 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Where have our archives gone? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list I was looking up a past message at just now, and noticed that our mail archive stops on 2005-04-14. Does anyone know who to poke to get it going again? The private archive on mail.netbsd.org could be used to fill in the gap if necessary. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 10 18:20:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28780 for ; Tue, 10 May 2005 18:20:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F2A613A637; Tue, 10 May 2005 22:19:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 5A4313A635 for ; Tue, 10 May 2005 22:19:55 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DVd4y-0006YF-00; Tue, 10 May 2005 23:19:52 +0100 From: Ben Harris To: hartmans-ietf@mit.edu, ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-arcfour-fixes-02.txt: should this be a secsh draft In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Tue, 10 May 2005 23:19:52 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >The IESG has received a request to publish >draft-harris-ssh-arcfour-fixes-02 as a proposed standard. I'm aware >that this draft has been discussed by participants in the secsh >working group. > >Does the secsh working group wish to adopt this draft as a work item >or shall I proceed with this draft as an individual submission? Last time this was mentioned (in March, ISTR), there was no comment on Bill Sommerfeld's suggestion that it be sent to the IESG as an individual submission. I don't know about anyone else, but I couldn't see any great advantage to turning it into a WG document, so I submitted it individually. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed May 11 11:08:52 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11878 for ; Wed, 11 May 2005 11:08:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D00AF3A71C; Wed, 11 May 2005 15:08:45 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 56EE03A70E for ; Wed, 11 May 2005 15:08:43 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 50625E0063; Tue, 10 May 2005 18:29:12 -0400 (EDT) To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-arcfour-fixes-02.txt: should this be a secsh draft References: From: Sam Hartman Date: Tue, 10 May 2005 18:29:12 -0400 In-Reply-To: (Ben Harris's message of "Tue, 10 May 2005 23:19:52 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Ben" == Ben Harris writes: Ben> In article you write: >> The IESG has received a request to publish >> draft-harris-ssh-arcfour-fixes-02 as a proposed standard. I'm >> aware that this draft has been discussed by participants in the >> secsh working group. >> >> Does the secsh working group wish to adopt this draft as a work >> item or shall I proceed with this draft as an individual >> submission? Ben> Last time this was mentioned (in March, ISTR), there was no Ben> comment on Bill Sommerfeld's suggestion that it be sent to Ben> the IESG as an individual submission. I don't know about Ben> anyone else, but I couldn't see any great advantage to Ben> turning it into a WG document, so I submitted it Ben> individually. I think handling it as an individual submission is fine, but the working group effectively gets right of first refusal. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed May 11 11:17:07 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12789 for ; Wed, 11 May 2005 11:17:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 854543A742; Wed, 11 May 2005 15:15:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 645163A4EB for ; Wed, 11 May 2005 15:14:55 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7420317; Wed, 11 May 2005 09:14:51 -0600 Message-ID: <42822208.1060404@vandyke.com> Date: Wed, 11 May 2005 09:17:28 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Harris Cc: hartmans-ietf@mit.edu, ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-arcfour-fixes-02.txt: should this be a secsh draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ben Harris wrote: > In article you write: > >>The IESG has received a request to publish >>draft-harris-ssh-arcfour-fixes-02 as a proposed standard. I'm aware >>that this draft has been discussed by participants in the secsh >>working group. >> >>Does the secsh working group wish to adopt this draft as a work item >>or shall I proceed with this draft as an individual submission? > > > Last time this was mentioned (in March, ISTR), there was no comment on > Bill Sommerfeld's suggestion that it be sent to the IESG as an individual > submission. I don't know about anyone else, but I couldn't see any > great advantage to turning it into a WG document, so I submitted it > individually. Just so this doesn't happen out of sheer apathy... What advantage would there be to the working group taking this on as opposed to it proceeding as an individual submission? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed May 11 11:18:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12973 for ; Wed, 11 May 2005 11:18:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EE52E3A789; Wed, 11 May 2005 15:18:03 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id A89D83A77E for ; Wed, 11 May 2005 15:18:01 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j4BFHmjO026785; Wed, 11 May 2005 09:17:48 -0600 (MDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4BFHlOp009313; Wed, 11 May 2005 11:17:48 -0400 (EDT) Subject: Re: draft-harris-ssh-arcfour-fixes-02.txt: should this be a secsh draft From: Bill Sommerfeld To: Sam Hartman Cc: Ben Harris , ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1115824637.10359.4.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Wed, 11 May 2005 11:17:18 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-05-10 at 18:29, Sam Hartman wrote: > Ben> Last time this was mentioned (in March, ISTR), there was no > Ben> comment on Bill Sommerfeld's suggestion that it be sent to > Ben> the IESG as an individual submission. I don't know about > Ben> anyone else, but I couldn't see any great advantage to > Ben> turning it into a WG document, so I submitted it > Ben> individually. > > I think handling it as an individual submission is fine, but the > working group effectively gets right of first refusal. I asked this question of the working group about a month ago and got an apathetic response. I don't see any requirement for the WG to take ownership. as WG chair I don't see any problem with this going forward as an individual submission. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed May 11 12:38:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22365 for ; Wed, 11 May 2005 12:38:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C26C33A764; Wed, 11 May 2005 16:38:28 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (STRATTON-ONE-SIXTY.MIT.EDU [18.187.5.160]) by mail.netbsd.org (Postfix) with ESMTP id 2152E3A4F5 for ; Wed, 11 May 2005 16:38:27 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5B6E3E0063; Wed, 11 May 2005 12:11:05 -0400 (EDT) To: Joseph Galbraith Cc: Ben Harris , ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-arcfour-fixes-02.txt: should this be a secsh draft References: <42822208.1060404@vandyke.com> From: Sam Hartman Date: Wed, 11 May 2005 12:11:05 -0400 In-Reply-To: <42822208.1060404@vandyke.com> (Joseph Galbraith's message of "Wed, 11 May 2005 09:17:28 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Joseph" == Joseph Galbraith writes: Joseph> Just so this doesn't happen out of sheer apathy... Joseph> What advantage would there be to the working group taking Joseph> this on as opposed to it proceeding as an individual Joseph> submission? I actually think there are advantages to it going forward as an individual submission provided the quality is reasonable. IT can go faster. The working group should take the document if it believes it needs consensus-based revisions or believes the review it will get as an individual submission would be insufficient. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed May 11 12:56:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23734 for ; Wed, 11 May 2005 12:56:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DE4FF3A765; Wed, 11 May 2005 16:56:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by mail.netbsd.org (Postfix) with ESMTP id 47D613A4F5 for ; Wed, 11 May 2005 16:56:46 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from draco.cus.cam.ac.uk ([131.111.8.18]:64600) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1DVuVn-00041Y-4F (Exim 4.51) for ietf-ssh@netbsd.org (return-path ); Wed, 11 May 2005 17:56:43 +0100 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.51) id 1DVuVm-0003yw-Vk for ietf-ssh@netbsd.org; Wed, 11 May 2005 17:56:43 +0100 Date: Wed, 11 May 2005 17:56:42 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: break extension draft revival? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is there any likelihood of the draft-ietf-secsh-break being revived? It's reasonably simple and seems to be widely implemented. I'm happy to take on the job of editing it if necessary. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu May 12 12:21:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08479 for ; Thu, 12 May 2005 12:21:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A6CF23A3EE; Thu, 12 May 2005 16:21:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from av-tac-sj.cisco.com (firestar.cisco.com [171.68.227.75]) by mail.netbsd.org (Postfix) with ESMTP id 0D72C3A3E8 for ; Thu, 12 May 2005 16:21:11 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost [127.0.0.1]) by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CGAK212213; Thu, 12 May 2005 09:10:20 -0700 (PDT) Received: from premakerpc ([10.21.107.51]) by fire.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CGAJt09282; Thu, 12 May 2005 09:10:19 -0700 (PDT) Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.11.8]); Thu, 12 May 2005 09:10:18 -0700 Message-ID: <01d501c5570d$17762fe0$336b150a@premakerpc> From: "Phillip Remaker" To: "Ben Harris" , References: Subject: Re: break extension draft revival? Date: Thu, 12 May 2005 09:10:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Yes!! It has been on my todo list for 6 weeks now! If you wouild please just edit it with the IDNITS fixed and the Informative references updated, I'd appreciate that and resubmit it to the WG. I just haven't had time. Thanks! > Is there any likelihood of the draft-ietf-secsh-break being revived? It's > reasonably simple and seems to be widely implemented. I'm happy to take > on the job of editing it if necessary. > > -- > Ben Harris > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu May 19 09:14:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03087 for ; Thu, 19 May 2005 09:14:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6D80C3A535; Thu, 19 May 2005 13:14:16 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by mail.netbsd.org (Postfix) with ESMTP id 14F033A3C0 for ; Thu, 19 May 2005 13:14:14 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from draco.cus.cam.ac.uk ([131.111.8.18]:45957) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1DYkqX-000860-1w (Exim 4.51) for ietf-ssh@NetBSD.org (return-path ); Thu, 19 May 2005 14:13:53 +0100 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.51) id 1DYkqX-00014z-48; Thu, 19 May 2005 14:13:53 +0100 Date: Thu, 19 May 2005 14:13:53 +0100 (BST) From: Ben Harris To: Phillip Remaker Cc: ietf-ssh@NetBSD.org Subject: Re: break extension draft revival? In-Reply-To: <01d501c5570d$17762fe0$336b150a@premakerpc> Message-ID: References: <01d501c5570d$17762fe0$336b150a@premakerpc> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 12 May 2005, Phillip Remaker wrote: > If you wouild please just edit it with the IDNITS fixed and the Informative > references updated, I'd appreciate that and resubmit it to the WG. I've done that, and put it at and . I've also corrected various other problems (unexplained abbreviations, references in the Abstract, miscapitalisation of "Telnet", no reference to RFC 2119, no explanation of data types, incorrect informative/normative split, and maybe others) and put the result at and . Use whichever you want, and I'm sorry for the delay in sorting this out. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu May 19 11:47:10 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17804 for ; Thu, 19 May 2005 11:47:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 68B393A56C; Thu, 19 May 2005 15:47:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av-tac-sj.cisco.com (firestar.cisco.com [171.68.227.75]) by mail.netbsd.org (Postfix) with ESMTP id 806783A556 for ; Thu, 19 May 2005 15:47:00 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost [127.0.0.1]) by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4JFl0n06843 for ; Thu, 19 May 2005 08:47:00 -0700 (PDT) Received: from remakerw2k01 ([10.21.141.197]) by fire.cisco.com (8.11.7p1+Sun/8.11.7) with SMTP id j4JFkxt01727 for ; Thu, 19 May 2005 08:46:59 -0700 (PDT) Message-ID: <019e01c55c89$fd81e2f0$9ff0190a@amer.cisco.com> From: "Phillip Remaker" To: Subject: SSH Break Draft, resurrected (draft-ietf-secsh-break-04) Date: Thu, 19 May 2005 08:46:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit THANKS to Ben Harris at Vandyke for stepping up and editing this. It has been languishing for months on my TO DO list. I plan to resubmit this draft for SSH over break to this noble body. All just nits and tweaks, the content is unchanged, largely. But comments are most welcome!! -------------------------------------------------------------------- Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: November 15, 2005 P. Remaker Cisco Systems, Inc May 14, 2005 Secure Shell (SSH) Session Channel Break Extension draft-ietf-secsh-break-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. Galbraith & Remaker Expires November 15, 2005 [Page 1] Internet-Draft SSH Break Extension May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 3. The Break Request . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 11 Galbraith & Remaker Expires November 15, 2005 [Page 2] Internet-Draft SSH Break Extension May 2005 1. Introduction The Secure Shell (SSH) session channel provides a mechanism for the client-user to interactively enter commands and receive output from a remote host while taking advantage of the SSH transport's privacy and integrity features. SSH is increasingly being used to replace Telnet for terminal access applications. A common application of the Telnet protocol is the "Console Server" [7] whereby a Telnet Network Virtual Terminal (NVT) can be connected to a physical RS-232/V.24 asynchronous port, making the Telnet NVT appear as a locally attached terminal to that port, and making that physical port appear as a network addressable device. A number of major computer equipment vendors provide high level administrative functions through an asynchronous serial port and generally expect the attached terminal to be capable of send a BREAK signal. A BREAK signal is defined as the TxD signal being held in a SPACE ("0") state for a time greater than a whole character time. In practice, a BREAK signal is typically 250 to 500 ms in length. The Telnet protocol furnishes a means to send a "BREAK" signal, which RFC0854 defines as "a signal outside the USASCII set which is currently given local meaning within many systems." [1] Console Server vendors interpret the TELNET BREAK signal as a physical BREAK signal, which can then allow access to the full range of adminisrative functions available on an asynchronous serial console port. The lack of a similar facility in the SSH session channel has forced users to continue the use of Telnet for the "Console Server" function. Galbraith & Remaker Expires November 15, 2005 [Page 3] Internet-Draft SSH Break Extension May 2005 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. The "byte", "boolean", "uint32", and "string" data types are defined in [3]. Galbraith & Remaker Expires November 15, 2005 [Page 4] Internet-Draft SSH Break Extension May 2005 3. The Break Request The following channel specific request can be sent over a session channel to request that the remote host perform a BREAK operation. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "break" boolean want_reply uint32 break-length in milliseconds If the BREAK length cannot be controlled by the application receiving this request, the BREAK length parameter SHOULD be ignored and the default BREAK signal length of the chipset or underlying chipset driver SHOULD be sent. If the application receiving this request can control the BREAK- length, the following suggestions are made regarding BREAK duration. If a BREAK duration request of greater than 3000ms is received, it SHOULD be processed as a 3000ms BREAK, in order to prevent an unreasonably long BREAK request causing the port to become unavailable for as long as 49.7 days while executing the BREAK. Applications that require a longer BREAK may choose to ignore this requirement. If BREAK duration request of less than 500ms, is requested a BREAK of 500ms SHOULD be sent since most devices will recognize a BREAK of that length. In the event that an application needs a shorter BREAK, this suggestion can be ignored. If the BREAK- length parameter is 0, the BREAK SHOULD be sent as 500ms or the default BREAK signal length of the chipset or underlying chipset driver. If the SSH connection does not terminate on a physical serial port, the BREAK indication SHOULD be handled in a manner consistent with the general use of BREAK as an attention/interrupt signal; for instance, a service processor could use some other out-of-band facility to get the attention of a system it manages. In a case where an SSH connection cascades to another connection, the BREAK SHOULD be passed along the cascaded connection. For example, a Telnet session from an SSH shell should carry along an SSH initiated BREAK and an SSH client initiated from a Telnet connection SHOULD pass a BREAK indication from the Telnet connection. If the 'want_reply' boolean is set, the server MUST reply using an SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message. If a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be Galbraith & Remaker Expires November 15, 2005 [Page 5] Internet-Draft SSH Break Extension May 2005 sent. This operation SHOULD be supported by any general purpose SSH client. Galbraith & Remaker Expires November 15, 2005 [Page 6] Internet-Draft SSH Break Extension May 2005 4. Security Considerations Many computer systems treat serial consoles as local and secured, and interpret a BREAK signal as an instruction to halt execution of the operating system or to enter privileged configuration modes. Because of this, extra care should be taken to ensure that SSH access to BREAK-enabled ports are limited to users with appropriate privileges to execute such functions. Alternatively, support for the BREAK facility MAY be implemented configurable or a per port or per server basis. Implementations that literally interpret the BREAK length parameter without imposing the suggested BREAK time limit may cause a denial of service to or unexpected results from attached devices receiving the very long BREAK signal. Galbraith & Remaker Expires November 15, 2005 [Page 7] Internet-Draft SSH Break Extension May 2005 5. IANA Considerations IANA is requested to assign the Connection Protocol Channel Request Name "break" in accordance with [6]. Galbraith & Remaker Expires November 15, 2005 [Page 8] Internet-Draft SSH Break Extension May 2005 6. References 6.1 Normative References [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", draft-ietf-secsh-architecture-22 (work in progress), March 2005. [4] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. [5] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", draft-ietf-secsh-connect-25 (work in progress), March 2005. [6] Lehtinen, S. and C. Lonvick, "SSH Protocol Assigned Numbers", draft-ietf-secsh-assignednumbers-12 (work in progress), March 2005. 6.2 Informative References [7] Harris, D., "Greater Scroll of Console Knowledge", March 2004, . Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Galbraith & Remaker Expires November 15, 2005 [Page 9] Internet-Draft SSH Break Extension May 2005 Phillip Remaker Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95120 US Phone: +1 408 526 8614 Email: remaker@cisco.com Galbraith & Remaker Expires November 15, 2005 [Page 10] Internet-Draft SSH Break Extension May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Remaker Expires November 15, 2005 [Page 11] From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu May 19 11:53:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18442 for ; Thu, 19 May 2005 11:53:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 701A03A4E8; Thu, 19 May 2005 15:53:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id D2C7A3A3C0 for ; Thu, 19 May 2005 15:53:13 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DYnKi-0003lw-00; Thu, 19 May 2005 16:53:12 +0100 From: Ben Harris To: remaker@cisco.com, ietf-ssh@NetBSD.org Subject: Re: SSH Break Draft, resurrected (draft-ietf-secsh-break-04) In-Reply-To: <019e01c55c89$fd81e2f0$9ff0190a@amer.cisco.com> References: <019e01c55c89$fd81e2f0$9ff0190a@amer.cisco.com> Organization: Linux Unlimited Message-Id: Date: Thu, 19 May 2005 16:53:12 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <019e01c55c89$fd81e2f0$9ff0190a@amer.cisco.com> you write: >THANKS to Ben Harris at Vandyke for stepping up and editing this. Point of Information, I'm not of Vandyke. I'm either of the University of Cambridge or of the PuTTY project, but not acting on behalf of either. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 24 15:46:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07008 for ; Tue, 24 May 2005 15:46:12 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AA9383A519; Tue, 24 May 2005 19:46:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 01ED93A518 for ; Tue, 24 May 2005 19:46:01 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06967; Tue, 24 May 2005 15:45:59 -0400 (EDT) Message-Id: <200505241945.PAA06967@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-break-03.txt Date: Tue, 24 May 2005 15:45:59 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --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 : Secure Shell (SSH) Session Channel Break Extension Author(s) : J. Galbraith, P. Remaker Filename : draft-ietf-secsh-break-03.txt Pages : 11 Date : 2005-5-24 The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-break-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-break-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-break-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2005-5-24155048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-break-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-break-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-24155048.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed May 25 17:41:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01162 for ; Wed, 25 May 2005 17:41:32 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 40AAE3A3AC; Wed, 25 May 2005 21:41:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 803963A3A5 for ; Wed, 25 May 2005 21:41:23 +0000 (UTC) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4PLfM0R017006 for ; Wed, 25 May 2005 15:41:23 -0600 (MDT) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4PLfMAH022349; Wed, 25 May 2005 14:41:22 -0700 (PDT) Subject: WG Last Call: draft-ietf-secsh-break-03.txt From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1117057237.32717.415.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Wed, 25 May 2005 14:40:38 -0700 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit This message marks the start of a two-week working group Last Call on draft-ietf-secsh-break-03.txt for publication as a Proposed Standard. If you believe this document should not be published as-is, please send comments, ideally with suggested edits, to the working group list. Comments in support of publication and reports of successful implementation are also appropriate. This working group last call times out on June 8th, 2005; after that point if there is rough consensus to publish I will pass the document on to our AD. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun May 29 16:27:21 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21333 for ; Sun, 29 May 2005 16:27:21 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4651B3A497; Sun, 29 May 2005 20:27:16 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 3EE7C3A490 for ; Sun, 29 May 2005 20:27:14 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA14063; Sun, 29 May 2005 16:27:13 -0400 (EDT) From: der Mouse Message-Id: <200505292027.QAA14063@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sun, 29 May 2005 16:17:08 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: WG Last Call: draft-ietf-secsh-break-03.txt In-Reply-To: <1117057237.32717.415.camel@unknown.hamachi.org> References: <1117057237.32717.415.camel@unknown.hamachi.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > This message marks the start of a two-week working group Last Call on > draft-ietf-secsh-break-03.txt for publication as a Proposed Standard. I have some copy-edit comments on it. Indented lines are quotes from break-03; the following non-indented lines are fixes I would like to see made. Even if none of these chagnes are made, I would like to see this document advance. the attached terminal to be capable of send a BREAK signal. s/send/sending/ requirement. If BREAK duration request of less than 500ms, is s/requirement/suggestion/ s/ request / / s/,// facility MAY be implemented configurable or a per port or per server s/ted con/ted as con/ s/per /per-/g /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun May 29 18:52:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03408 for ; Sun, 29 May 2005 18:52:04 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3BB8C3A520; Sun, 29 May 2005 22:51:59 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6316A3A51B for ; Sun, 29 May 2005 22:51:57 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA14685; Sun, 29 May 2005 18:51:56 -0400 (EDT) From: der Mouse Message-Id: <200505292251.SAA14685@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sun, 29 May 2005 18:50:26 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: WG Last Call: draft-ietf-secsh-break-03.txt In-Reply-To: <200505292027.QAA14063@Sparkle.Rodents.Montreal.QC.CA> References: <1117057237.32717.415.camel@unknown.hamachi.org> <200505292027.QAA14063@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Writing of draft-ietf-secsh-break-03.txt, I wrote > facility MAY be implemented configurable or a per port or per server > > s/ted con/ted as con/ > s/per /per-/g I missed s/ or / on /. *blush* /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 30 01:50:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26338 for ; Mon, 30 May 2005 01:50:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9CC693A419; Mon, 30 May 2005 05:49:50 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id A8BC63A39F for ; Mon, 30 May 2005 05:49:48 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA28011; Mon, 30 May 2005 01:49:43 -0400 (EDT) From: der Mouse Message-Id: <200505300549.BAA28011@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 30 May 2005 01:45:44 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: rijndael-cbc@lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I see rijndael-cbc@lysator.liu.se in the encryption lists for at least one ssh implementation I've tried interop tests with (SSH-1.99-OpenSSH_3.6.1 NetBSD_Secure_Shell-20030917). But a little poking around failed to turn up a spec for it. Is that identical except in name to one of the aes* modes? If so, which one, and if not, what is it? I'd like to support it for interoperability reasons.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 30 01:53:20 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26532 for ; Mon, 30 May 2005 01:53:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 757923A438; Mon, 30 May 2005 05:53:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from shitei.mindrot.org (shitei.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 5E9273A419 for ; Mon, 30 May 2005 05:53:13 +0000 (UTC) Received: from baragon.mindrot.org (adsl-226-34.swiftdsl.com.au [218.214.226.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id A41D627C188; Mon, 30 May 2005 15:52:41 +1000 (EST) Received: from [127.0.0.1] (unknown [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 3C15A16F4D0; Mon, 30 May 2005 15:52:40 +1000 (EST) Message-ID: <429AAA20.3060502@mindrot.org> Date: Mon, 30 May 2005 15:52:32 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050512) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: rijndael-cbc@lysator.liu.se References: <200505300549.BAA28011@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200505300549.BAA28011@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit der Mouse wrote: > I see rijndael-cbc@lysator.liu.se in the encryption lists for at least > one ssh implementation I've tried interop tests with > (SSH-1.99-OpenSSH_3.6.1 NetBSD_Secure_Shell-20030917). But a little > poking around failed to turn up a spec for it. Is that identical > except in name to one of the aes* modes? If so, which one, and if not, > what is it? I'd like to support it for interoperability reasons.... It is identical to aes256-cbc, but we may remove it in the future. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 30 02:24:42 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19093 for ; Mon, 30 May 2005 02:24:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7ED253A47A; Mon, 30 May 2005 06:24:39 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 7353E3A419 for ; Mon, 30 May 2005 06:24:37 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA28316; Mon, 30 May 2005 02:24:36 -0400 (EDT) From: der Mouse Message-Id: <200505300624.CAA28316@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 30 May 2005 02:18:16 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: newmodes-03 buglet: *-ctr modes' blocksizes? Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Looking at newmodes-03, I see various *-ctr modes described. But they are basically stream ciphers, and as such, do not really have a blocksize any more than (say) arcfour does. But for interoperability everyone has to agree on what their blocksize is for purposes of ssh use. For the -ctr modes I've already implemented (blowfish-ctr and 3des-ctr) this hasn't mattered because their "native" blocksize is 64 bits, and strema ciphers are treated as having 64-bit blocks for purposes of ssh's stream blocking. But now I want to do the aes*-ctr modes, and this suddenly matters. So, I think newmodes-03 needs to be updated to clarify this: do these *-ctr modes run as stream ciphers, blocking the data stream to 64-bit blocks like any stream cipher, or do they run as block ciphers (which happen to be implemented as stream ciphers) with block sizes copied from their underlying block algorithms? (Or something else?) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 30 02:30:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19636 for ; Mon, 30 May 2005 02:30:24 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 418323A46D; Mon, 30 May 2005 06:30:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6FAA53A419 for ; Mon, 30 May 2005 06:30:18 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA28348; Mon, 30 May 2005 02:30:17 -0400 (EDT) From: der Mouse Message-Id: <200505300630.CAA28348@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 30 May 2005 02:29:27 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: newmodes-03 buglet: *-ctr modes' blocksizes? In-Reply-To: <200505300624.CAA28316@Sparkle.Rodents.Montreal.QC.CA> References: <200505300624.CAA28316@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > So, I think newmodes-03 needs to be updated to clarify this: [...] Never mind, I apparently can't read. "The block size is 8 bytes." "The block size is 16 bytes." Duh. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon May 30 09:50:24 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15267 for ; Mon, 30 May 2005 09:50:23 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0320F3A4E2; Mon, 30 May 2005 13:50:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by mail.netbsd.org (Postfix) with ESMTP id 4FC0E3A4E1 for ; Mon, 30 May 2005 13:50:15 +0000 (UTC) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id j4UDVANA020200 for ; Mon, 30 May 2005 15:31:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: SFTP and cross-platform text file detection. Date: Mon, 30 May 2005 15:31:29 +0200 Message-ID: Thread-Topic: SFTP and cross-platform text file detection. Thread-Index: AcVlG4+tcejgx0wYSiSrkTm3LpxciA== From: "Ouadah Farid" To: X-OriginalArrivalTime: 30 May 2005 13:35:29.0484 (UTC) FILETIME=[71EE00C0:01C5651C] X-Scanned-By: MIMEDefang 2.38 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hello, I'm confronted to an interesting problem that might require some = precisions in the "SSH file transfer protocol". Many Windows or Unix modern applications can transparently operate = text-files even if they are not in their native format (I.E: Unix texte = file for a Windows application). Stating about the ability for SFTP servers to do so might be intersting = since different behaviours could lead to different results. Since a proper local file format cannot always be guaranteed (I.E: for = shared filesystems) a same operation could give very different results. By example if we compare a text file transfer originating from two kinds = of SFTP theorical servers (a "strict" one and a "relaxed" one) it could = lead to very different results. A strict application only recognize its own local newline format. A relaxed application is capable of reading more than it's own file = format (A windows or Unix application that can read both LF and CRLF as = a newline). A Unix text file transfered with a strict SFTP Windows server would be = send unchanged (if we imagine that the client has no hint about the file = format). A Unix text file transfered with a relaxed SFTP Windows server would be = send transcoded (LF -> CRLF with the default newline convention). A Windows text transfered with a strict SFTP Unix server would be send = transcoded (CRLF -> CRCRLF with the default newline convention). A Windows text transfered with a relaxed SFTP Unix server would be send = transcoded differently (CRLF -> CRLF with the default newline = convention). From the client side, the resulting file could be very different. I have restricted the case to Windows and Unix but the problem concerns = every kind of SFTP server and text file. I think that either a relaxed text-file detection should be forbidden or = there must be some way to avoid mistakes. I hope I was clear enough. What is your opinion ? Farid From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 31 15:25:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10825 for ; Tue, 31 May 2005 15:25:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B33023A50F; Tue, 31 May 2005 19:25:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id AE9A33A505 for ; Tue, 31 May 2005 19:25:45 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA15513; Tue, 31 May 2005 15:25:44 -0400 (EDT) From: der Mouse Message-Id: <200505311925.PAA15513@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 31 May 2005 15:20:09 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: more interop testing? Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I've just added the aes* algorithms (and some rijndael-* algorithms) to my implementation, and I'd like to try some basic interop testing, at least for the aes* algorithms. (The one rijndael-* algorithm I expect anyone else to have implemented is rijndael-cbc@lysator.liu.se, and I feel confident that if my aes256-cbc works, so will my rijndael-cbc@lysator.liu.se.) I've done a little interop testing with "SSH-1.99-OpenSSH_3.6.1 NetBSD_Secure_Shell-20030917", and it seems to work OK. Anybody else up for it? I'd especially like to do interop with anyone who does Rijndael with a block size other than 128 bits (ie, other than the AES variants); one of us may need to add a new name, but I'm perfectly willing to be that one if necessary. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 31 15:42:54 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11696 for ; Tue, 31 May 2005 15:42:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 110613A505; Tue, 31 May 2005 19:42:49 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 403303A399 for ; Tue, 31 May 2005 19:42:46 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa09180; 31 May 2005 15:41 EDT Date: Tue, 31 May 2005 15:41:58 -0400 From: Jeffrey Hutzelman To: Sam Hartman Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org Subject: Re: What's up with gssapi-keyex Message-ID: <853F99A8E17585D5469152E9@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01e0FkKeWp2Z3HjNyqrr+UmBKzm1QCdd3otpKOscE=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, May 31, 2005 03:21:31 PM -0400 Sam Hartman wrote: > Hi. I noticed that a new draft has been posted but we have not yet > had a WG last call. It's my understanding that we were going to see > if the host key change advice was sufficient by seeing if it got > objections during last call. Are we waiting for anything else before > starting last call? That's the only item I knew about, and I had forgotten we weren't expecting any more comments before last call. Bill, can we start a WGLC on this? -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 31 15:53:10 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13073 for ; Tue, 31 May 2005 15:53:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DB8713A44A; Tue, 31 May 2005 19:53:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (STRATTON-THREE-SIXTY-NINE.MIT.EDU [18.187.6.114]) by mail.netbsd.org (Postfix) with ESMTP id 658403A399 for ; Tue, 31 May 2005 19:53:03 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3FAA7E0063; Tue, 31 May 2005 15:21:31 -0400 (EDT) To: jhutz@cmu.edu Cc: ietf-ssh@NetBSD.org Subject: What's up with gssapi-keyex From: Sam Hartman Date: Tue, 31 May 2005 15:21:31 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi. I noticed that a new draft has been posted but we have not yet had a WG last call. It's my understanding that we were going to see if the host key change advice was sufficient by seeing if it got objections during last call. Are we waiting for anything else before starting last call? --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue May 31 23:45:45 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23355 for ; Tue, 31 May 2005 23:45:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D53A93A42E; Wed, 1 Jun 2005 03:45:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from server.nextgenhosting.net (unknown [67.15.0.19]) by mail.netbsd.org (Postfix) with ESMTP id 4F3A93A40B for ; Wed, 1 Jun 2005 03:45:36 +0000 (UTC) X-ClientAddr: 127.0.0.1 Received: from 4everdecking.com (localhost.localdomain [127.0.0.1]) by server.nextgenhosting.net (8.12.10/8.12.10) with ESMTP id j512qMJt012847 for ; Tue, 31 May 2005 22:52:22 -0400 Received: (from albiondecking@localhost) by 4everdecking.com (8.12.10/8.12.11/Submit) id j512qMWA012845; Tue, 31 May 2005 22:52:22 -0400 Date: Tue, 31 May 2005 22:52:22 -0400 Message-Id: <200506010252.j512qMWA012845@4everdecking.com> To: ietf-ssh@NetBSD.org Subject: Re:Xtv Live Nagra 2 Beta Testers Dtv To Members From: Missing Channels Fix MIME-Version: 1.0 X-Mailer: PHPBulkEmailer 1.1 http://www.nukedweb.com/ Content-Type: text/plain Content-Transfer-Encoding: 8bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: albiondecking@4everdecking.com Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit HOT NEW MEMBERS SECTION SIGNUP http://www.nagra2ready.com Are you in need of a system to get back perhaps all your lost channels back? Well climb aboard and purchase a Nagra 2 Ready rciever with extnded memory capacity for nagra 2 beta flash testing.Please take note that this fix is available to members only club,once signed up you can access files and our N2 ready reciever ready for your testing wishes and needs,test away.Sign Up Today and get full access to our Super encrypted easy files.Once your a member you can access our Nagra 2 ready member reciever and test today,we have 30 day guarantee on hardware and software.You cannot lose at all.We are still here unlike other sites around that crumble.We are in house technicians wishing to serve you better. http://www.nagra2ready.com Isn't it time that you make the right decision and join a satellite testing site that has been running strong for such a long time, with fixes that have been running flawlessly since late 2004. Our code is ultra private therefore you are not taking any risk when becoming a member and we also extend a full 30 day refund guarantee, so within that time if you decide we are not up to your standards, email us and we will promptly rectify the situation. http://www.nagra2ready.com 8