From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 01:03:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtImr-00025L-Ba for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 01:03:17 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19694 for ; Mon, 2 Jan 2006 01:02:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6E03A63B187; Mon, 2 Jan 2006 06:03:11 +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 1B3B463B14F for ; Mon, 2 Jan 2006 06:03:06 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA12791; Mon, 2 Jan 2006 01:03:04 -0500 (EST) From: der Mouse Message-Id: <200601020603.BAA12791@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, 2 Jan 2006 01:00:06 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode In-Reply-To: <20051231160559.GK4231@riva.ucam.org> References: <20051231160559.GK4231@riva.ucam.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Recent versions of the Linux kernel support an IUTF8 flag [...]. > I would like to allow this mode to be preserved by SSH, but there is > no assignment for it at present. > Could this line be added to the appropriate place in > draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to > create this assignment? It's probably too late to do this before they make it to RFC status. > 42 seems like a reasonable place for it. > 42 IUTF8 Assume input characters are UTF-8 encoded. Actually, if you're going to be adding such things, how about adding bits for ECHOPRT, ALTWERASE, NOKERNINFO, and character size (CS5..CS8)? In my own implementation, I created a private channel request to carry those bits.... /~\ 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 Jan 02 03:34:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtL8v-0001cX-6x for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 03:34:15 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02516 for ; Mon, 2 Jan 2006 03:32:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EFA0663B346; Mon, 2 Jan 2006 08:34:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id D792F63B10A for ; Mon, 2 Jan 2006 08:34:05 +0000 (UTC) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k028Y5dK021221 for ; Mon, 2 Jan 2006 00:34:05 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k028Y4gr021755 for ; Mon, 2 Jan 2006 01:34:04 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k028Y3t3001923; Mon, 2 Jan 2006 02:34:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k028Y29M001922; Mon, 2 Jan 2006 02:34:02 -0600 (CST) Date: Mon, 2 Jan 2006 02:34:02 -0600 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <20060102083402.GS18698@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <20051231160559.GK4231@riva.ucam.org> <200601020603.BAA12791@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601020603.BAA12791@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jan 02, 2006 at 01:00:06AM -0500, der Mouse wrote: > > Recent versions of the Linux kernel support an IUTF8 flag [...]. > > > I would like to allow this mode to be preserved by SSH, but there is > > no assignment for it at present. > > > Could this line be added to the appropriate place in > > draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to > > create this assignment? > > It's probably too late to do this before they make it to RFC status. > > > 42 seems like a reasonable place for it. > > > 42 IUTF8 Assume input characters are UTF-8 encoded. > > Actually, if you're going to be adding such things, how about adding > bits for ECHOPRT, ALTWERASE, NOKERNINFO, and character size (CS5..CS8)? > In my own implementation, I created a private channel request to carry > those bits.... Using an "env" channel request to set LANG/LC_CTYPE/LC_ALL to a UTF-8 locale should do, though if the pty requires special attention then the server will have to know to interpret said environment variables specially. And, of course, this is definitely a POSIX-specific approach. Nico -- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 07:28:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtOnD-0004VQ-Ak for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 07:28:03 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22408 for ; Mon, 2 Jan 2006 07:26:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DAE6C63B211; Mon, 2 Jan 2006 12:27:57 +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 25F2063B20E for ; Mon, 2 Jan 2006 12:27:56 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EtOn6-0003RD-00 for ietf-ssh@netbsd.org; Mon, 02 Jan 2006 12:27:56 +0000 Date: Mon, 2 Jan 2006 12:27:55 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <20060102122755.GA483@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601020603.BAA12791@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: > [Colin Watson:] >> 42 IUTF8 Assume input characters are UTF-8 encoded. > > Actually, if you're going to be adding such things, how about adding > bits for ECHOPRT, ALTWERASE, NOKERNINFO, and character size (CS5..CS8)? > In my own implementation, I created a private channel request to carry > those bits.... (You have CS7 and CS8 already, although you have to be sensible about which combinations you enable.) Well, the IETF seems to care more about UTF-8 than those other things. :) Given that the SSH protocol doesn't assign any semantics to these terminal modes -- they are just tokens passed from one side to the other -- it's a shame that they don't have extensibility and private-use facilities, unlike most of the rest of the protocol. If it's too late to get IUTF8 (etc) into the core drafts, and consensus is that it's worth a new document, it's probably best to define a channel extension like yours with textual names, private-use provisions, etc, rather than just assign some new code points in the existing mechanism (given how long it looks like it will take to get _any_ document through). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 12:23:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTOu-0000y3-Dv for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 12:23:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22679 for ; Mon, 2 Jan 2006 12:22:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B900B63B3B1; Mon, 2 Jan 2006 17:23:10 +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 9394863B156 for ; Mon, 2 Jan 2006 17:23:09 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA15725; Mon, 2 Jan 2006 12:23:08 -0500 (EST) From: der Mouse Message-Id: <200601021723.MAA15725@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, 2 Jan 2006 12:13:32 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode In-Reply-To: <20060102122755.GA483@chiark.greenend.org.uk> References: <20060102122755.GA483@chiark.greenend.org.uk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> 42 IUTF8 Assume input characters are UTF-8 encoded. >> Actually, if you're going to be adding such things, how about adding >> bits for ECHOPRT, ALTWERASE, NOKERNINFO, and character size >> (CS5..CS8)? > (You have CS7 and CS8 already, although you have to be sensible about > which combinations you enable.) Yes, it seems odd to have a CS7 boolean and a CS* boolean, rather than a CS field which takes an argument like 7 or 8. > Well, the IETF seems to care more about UTF-8 than those other > things. :) Given that there's PENDIN present, which has no business being present at all (it's transient internal state which is exposed so that userland can set it to provoke a reprint, not something that it makes any sense to push across the wire at connection setup), I don't see why they wouldn't include ECHOPRT, ALTWERASE, and NOKERNINFO. CS5 and CS6 are a little iffier.... There's also the question of what to do if the input and output character sizes differ, since there's only one character-size field in the protocol, not one in each direction. > Given that the SSH protocol doesn't assign any semantics to these > terminal modes -- they are just tokens passed from one side to the > other -- it's a shame that they don't have extensibility and > private-use facilities, unlike most of the rest of the protocol. Sure they do. Just not in the way you're thinking of. You can always do it the way I did - use a private CHANNEL_REQUEST to carry other stuff. Not interoperable between different independent versions, but that's true of pretty much any private-use extensibility mechanism. /~\ 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 Jan 02 13:51:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtUmj-0004Uq-OY for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 13:51:57 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02033 for ; Mon, 2 Jan 2006 13:50:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EA4D763B444; Mon, 2 Jan 2006 18:51:52 +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 33D2763B440 for ; Mon, 2 Jan 2006 18:51:52 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k02Ippuf026622 for ; Mon, 2 Jan 2006 11:51:51 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k02Ipp2w002636 for ; Mon, 2 Jan 2006 11:51:51 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k02IppHR002193; Mon, 2 Jan 2006 12:51:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k02IpoqG002192; Mon, 2 Jan 2006 12:51:50 -0600 (CST) Date: Mon, 2 Jan 2006 12:51:50 -0600 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <20060102185150.GV18698@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <20060102122755.GA483@chiark.greenend.org.uk> <200601021723.MAA15725@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601021723.MAA15725@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jan 02, 2006 at 12:13:32PM -0500, der Mouse wrote: > > Given that the SSH protocol doesn't assign any semantics to these > > terminal modes -- they are just tokens passed from one side to the > > other -- it's a shame that they don't have extensibility and > > private-use facilities, unlike most of the rest of the protocol. > > Sure they do. Just not in the way you're thinking of. You can always > do it the way I did - use a private CHANNEL_REQUEST to carry other > stuff. Not interoperable between different independent versions, but > that's true of pretty much any private-use extensibility mechanism. Yes, but putting a pseudo-terminal into UTF-8 mode (including, perhaps, specifying a normalization form) is something that strikes me as fairly generic and which the IETF would care about. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 17:04:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtXn6-00025E-7n for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 17:04:32 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20516 for ; Mon, 2 Jan 2006 17:03:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D627B63B1E9; Mon, 2 Jan 2006 22:04:27 +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 1B96563B17E for ; Mon, 2 Jan 2006 22:04:26 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path cjwatson@chiark.greenend.org.uk) id 1EtXn0-0008Ar-00 for ietf-ssh@netbsd.org; Mon, 02 Jan 2006 22:04:26 +0000 From: Colin Watson To: ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode In-Reply-To: <20060102083402.GS18698@binky.Central.Sun.COM> Organization: riva.ucam.org Message-Id: Date: Mon, 02 Jan 2006 22:04:26 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <20060102083402.GS18698@binky.Central.Sun.COM>, Nicolas Williams wrote: >On Mon, Jan 02, 2006 at 01:00:06AM -0500, der Mouse wrote: >> > Recent versions of the Linux kernel support an IUTF8 flag [...]. >> >> > I would like to allow this mode to be preserved by SSH, but there is >> > no assignment for it at present. >> >> > Could this line be added to the appropriate place in >> > draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to >> > create this assignment? >> >> It's probably too late to do this before they make it to RFC status. (I thought this was probably the case, but it did no harm to ask.) >> > 42 IUTF8 Assume input characters are UTF-8 encoded. >> >> Actually, if you're going to be adding such things, how about adding >> bits for ECHOPRT, ALTWERASE, NOKERNINFO, and character size (CS5..CS8)? >> In my own implementation, I created a private channel request to carry >> those bits.... > >Using an "env" channel request to set LANG/LC_CTYPE/LC_ALL to a UTF-8 >locale should do, though if the pty requires special attention then the >server will have to know to interpret said environment variables >specially. While setting LANG et al is indeed useful, it's not enough to make the kernel's terminal driver do the right thing when erasing characters in cooked mode. That's why the termios flag was invented. It would probably indeed be possible to come up with some baroque shell configuration that set IUTF8 if in a UTF-8 locale, but, since SSH already supports passing pseudo-terminal modes, this seems like a more correct approach in the long run ... Cheers, -- Colin Watson [cjwatson@debian.org] From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 17:29:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYBb-0005nL-5Q for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 17:29:52 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23018 for ; Mon, 2 Jan 2006 17:28:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1A7F163B36D; Mon, 2 Jan 2006 22:29:47 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 6722C63B128 for ; Mon, 2 Jan 2006 22:29:46 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k02MTfdK027839; Mon, 2 Jan 2006 14:29:41 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k02MTfWa021584; Mon, 2 Jan 2006 17:29:41 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k02MTenv015193; Mon, 2 Jan 2006 17:29:40 -0500 (EST) Subject: Re: IUTF8 pseudo-terminal mode From: Bill Sommerfeld To: Colin Watson Cc: ietf-ssh@NetBSD.org, Vincent Lefevre , 337041@bugs.debian.org In-Reply-To: <20051231160559.GK4231@riva.ucam.org> References: <20051231160559.GK4231@riva.ucam.org> Content-Type: text/plain Message-Id: <1136240979.12972.48.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.330 Date: Mon, 02 Jan 2006 17:29:40 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Sat, 2005-12-31 at 11:05, Colin Watson wrote: > Recent versions of the Linux kernel support an IUTF8 flag (see > http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the > character-erase function in cooked mode to handle UTF-8 characters > correctly. I would like to allow this mode to be preserved by SSH, but > there is no assignment for it at present. > > Could this line be added to the appropriate place in > draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create > this assignment? 42 seems like a reasonable place for it. > > 42 IUTF8 Assume input characters are UTF-8 encoded. as others have suggested, it's already too late to modify -connect and -assignednumbers. So what needs to happen to get this standardized is for someone to write an internet-draft documenting this extension and advance it as either a working group item or as an individual submission. In response to later messages: > While setting LANG et al is indeed useful, it's not enough to make the > kernel's terminal driver do the right thing when erasing characters in > cooked mode. That's why the termios flag was invented. I think Nicolas was implying that a request from the client to use a UTF8 locale would cause the server to set up the pseudoterminal it creates/allocates/... appropriately for the requested locale. But that's perhaps at odds with the existing strategy within the protocol of making termios-level details visible on the wire. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 17:44:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYPP-0007B1-Jk for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 17:44:07 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24280 for ; Mon, 2 Jan 2006 17:42:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4387563B383; Mon, 2 Jan 2006 22:44:03 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 8116963B128 for ; Mon, 2 Jan 2006 22:44:02 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k02Mi2dK004193 for ; Mon, 2 Jan 2006 14:44:02 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k02Mi032024676 for ; Mon, 2 Jan 2006 15:44:01 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k02Mi0U3002388; Mon, 2 Jan 2006 16:44:00 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k02MhwwD002387; Mon, 2 Jan 2006 16:43:58 -0600 (CST) Date: Mon, 2 Jan 2006 16:43:58 -0600 From: Nicolas Williams To: Bill Sommerfeld Cc: Colin Watson , ietf-ssh@NetBSD.org, Vincent Lefevre , 337041@bugs.debian.org Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <20060102224358.GE18698@binky.Central.Sun.COM> References: <20051231160559.GK4231@riva.ucam.org> <1136240979.12972.48.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1136240979.12972.48.camel@thunk> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote: > In response to later messages: > > While setting LANG et al is indeed useful, it's not enough to make the > > kernel's terminal driver do the right thing when erasing characters in > > cooked mode. That's why the termios flag was invented. > > I think Nicolas was implying that a request from the client to use a > UTF8 locale would cause the server to set up the pseudoterminal it > creates/allocates/... appropriately for the requested locale. But > that's perhaps at odds with the existing strategy within the protocol of > making termios-level details visible on the wire. I think I was a bit more explicit about this, but, yes, this would be a hack, and very POSIX-specific (and I was explicit about that too). But such a hack would also probably make most users happy :^/ at the expense of elegance and code complexity for SSHv2 servers running on POSIXy platforms. SSHv2's pty negotiation could certainly improve in this regard, I don't deny it! But I suspect saying "UTF-8" is not enough here. What options are there? Should the pty driver reject non-UTF-8 sequences? Should it normalize? Pass input through raw? I suspect most users wouldn't want much of a pty UTF-8 input mechanism as their clients, presumably, have a decent UTF-8 input method already -- but then, maybe they don't. I definitely think this should be a WG work item, if nothing else to ensure it gets more eyeballs because I18N requires care. Nico -- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 18:30:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtZ8a-0004n2-Ei for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 18:30:50 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27329 for ; Mon, 2 Jan 2006 18:29:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3845B63B1B5; Mon, 2 Jan 2006 23:30:42 +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 CDF0563B12C for ; Mon, 2 Jan 2006 23:30:40 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k02NUeuf016425 for ; Mon, 2 Jan 2006 16:30:40 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k02NUc34013847 for ; Mon, 2 Jan 2006 16:30:39 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k02NUZZe002450; Mon, 2 Jan 2006 17:30:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k02NUYcg002449; Mon, 2 Jan 2006 17:30:34 -0600 (CST) Date: Mon, 2 Jan 2006 17:30:34 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Bill Sommerfeld , Colin Watson , ietf-ssh@NetBSD.org, Vincent Lefevre , 337041@bugs.debian.org Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <20060102233034.GH18698@binky.Central.Sun.COM> References: <20051231160559.GK4231@riva.ucam.org> <1136240979.12972.48.camel@thunk> <20060102224358.GE18698@binky.Central.Sun.COM> <6EEB1C8BF6320CE0BC7A70D9@bistromath.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EEB1C8BF6320CE0BC7A70D9@bistromath.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jan 02, 2006 at 06:20:50PM -0500, Jeffrey Hutzelman wrote: > The original request wasn't really about standardizing handling of UTF-8 in > SSH data streams. That's really outside the scope of the protocol -- > unlike telnet, SSH doesn't provide a "virtual terminal"; it connects the > shell running on the server to the user's real terminal, and experience has > shown this is basically the right thing to do. Well, yes, but I'm not entirely sure one wouldn't want to negotiate additional behaviours -- I'm not saying one should as I've not really thought this through. > The request here was to enable SSH to pass a platform-specific TTY mode bit > which it doesn't currently handle. The bit in question causes the tty > driver on Linux systems to behave in a particular way; specifically, it > tells the driver that the user is typing in UTF-8, and that when the user > types the ERASE character, the driver should remove a complete character > (possibly a multi-byte UTF-8 sequence) from the input buffer. Got it. > One could argue that an SSH server running on such a system should look at > the configured locale and configure the PTY appropriately, and that's > probably even a good idea. However, a user using 'stty' to change terminal > modes at the remote end of an ssh connection has an expectation that the > change will propagate to the local terminal as much as possible, and the > point of defining a bit for IUTF8 is to help make that possible. Did you switch local/remote here? Nico -- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 18:56:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtZXE-0008Eg-9g for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 18:56:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28674 for ; Mon, 2 Jan 2006 18:55:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A555563B122; Mon, 2 Jan 2006 23:56:10 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id C2D3463B126 for ; Mon, 2 Jan 2006 23:56:09 +0000 (UTC) Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41]) by currant.srv.cs.cmu.edu id aa07008; 2 Jan 2006 18:56 EST Received: from bistromath-home.pc.cs.cmu.edu (c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id k02NtwZe007011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Jan 2006 18:55:59 -0500 (EST) Date: Mon, 02 Jan 2006 18:55:58 -0500 From: Jeffrey Hutzelman To: Nicolas Williams cc: Bill Sommerfeld , Colin Watson , ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <1AF762753D5F622D66C0A8AE@bistromath.pc.cs.cmu.edu> In-Reply-To: <20060102233034.GH18698@binky.Central.Sun.COM> References: <20051231160559.GK4231@riva.ucam.org> <1136240979.12972.48.camel@thunk> <20060102224358.GE18698@binky.Central.Sun.COM> <6EEB1C8BF6320CE0BC7A70D9@bistromath.pc.cs.cmu.edu> <20060102233034.GH18698@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:014HymzErkG0Asxx5NE/rWO3fu3fdnsB9N8dQxFvw=; 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 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2006.1.2.29 X-Spam-OK: 7% Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I'm removing the Debian bug and original reporter from the CC list; I don't think they care about our protocol design discussion. On Monday, January 02, 2006 05:30:34 PM -0600 Nicolas Williams wrote: >> One could argue that an SSH server running on such a system should look >> at the configured locale and configure the PTY appropriately, and >> that's probably even a good idea. However, a user using 'stty' to >> change terminal modes at the remote end of an ssh connection has an >> expectation that the change will propagate to the local terminal as >> much as possible, and the point of defining a bit for IUTF8 is to help >> make that possible. > > Did you switch local/remote here? Nope. If I type 'stty iutf8', stty does an ioctl on the pty slave on the remote machine (the ssh server). My expectation is that sshd will notice the change, propagate it down the wire, and my ssh client will make the same ioctl on my terminal (assuming, of course, that both terminals support the bit). -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 19:21:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtZvd-0003C0-0i for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 19:21:30 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00778 for ; Mon, 2 Jan 2006 19:20:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3D6EB63B3DE; Tue, 3 Jan 2006 00:21:25 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id DE3B063B375 for ; Tue, 3 Jan 2006 00:21:23 +0000 (UTC) Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41]) by currant.srv.cs.cmu.edu id aa06793; 2 Jan 2006 18:20 EST Received: from bistromath-home.pc.cs.cmu.edu (c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id k02NKpHT007008 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Jan 2006 18:20:52 -0500 (EST) Date: Mon, 02 Jan 2006 18:20:50 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , Bill Sommerfeld cc: Colin Watson , ietf-ssh@NetBSD.org, Vincent Lefevre , 337041@bugs.debian.org, Jeffrey Hutzelman Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <6EEB1C8BF6320CE0BC7A70D9@bistromath.pc.cs.cmu.edu> In-Reply-To: <20060102224358.GE18698@binky.Central.Sun.COM> References: <20051231160559.GK4231@riva.ucam.org> <1136240979.12972.48.camel@thunk> <20060102224358.GE18698@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01Jqsdw5ATkjdy9pVEWSlNMr0dVO6t35aTIEsoXCs=; 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 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2006.1.2.27 X-Spam-OK: 7% Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, January 02, 2006 04:43:58 PM -0600 Nicolas Williams wrote: > On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote: >> In response to later messages: >> > While setting LANG et al is indeed useful, it's not enough to make the >> > kernel's terminal driver do the right thing when erasing characters in >> > cooked mode. That's why the termios flag was invented. >> >> I think Nicolas was implying that a request from the client to use a >> UTF8 locale would cause the server to set up the pseudoterminal it >> creates/allocates/... appropriately for the requested locale. But >> that's perhaps at odds with the existing strategy within the protocol of >> making termios-level details visible on the wire. > > I think I was a bit more explicit about this, but, yes, this would be a > hack, and very POSIX-specific (and I was explicit about that too). But > such a hack would also probably make most users happy :^/ at the expense > of elegance and code complexity for SSHv2 servers running on POSIXy > platforms. > > SSHv2's pty negotiation could certainly improve in this regard, I don't > deny it! > > But I suspect saying "UTF-8" is not enough here. What options are > there? Should the pty driver reject non-UTF-8 sequences? Should it > normalize? Pass input through raw? I suspect most users wouldn't want > much of a pty UTF-8 input mechanism as their clients, presumably, have a > decent UTF-8 input method already -- but then, maybe they don't. > > I definitely think this should be a WG work item, if nothing else to > ensure it gets more eyeballs because I18N requires care. The original request wasn't really about standardizing handling of UTF-8 in SSH data streams. That's really outside the scope of the protocol -- unlike telnet, SSH doesn't provide a "virtual terminal"; it connects the shell running on the server to the user's real terminal, and experience has shown this is basically the right thing to do. The request here was to enable SSH to pass a platform-specific TTY mode bit which it doesn't currently handle. The bit in question causes the tty driver on Linux systems to behave in a particular way; specifically, it tells the driver that the user is typing in UTF-8, and that when the user types the ERASE character, the driver should remove a complete character (possibly a multi-byte UTF-8 sequence) from the input buffer. One could argue that an SSH server running on such a system should look at the configured locale and configure the PTY appropriately, and that's probably even a good idea. However, a user using 'stty' to change terminal modes at the remote end of an ssh connection has an expectation that the change will propagate to the local terminal as much as possible, and the point of defining a bit for IUTF8 is to help make that possible. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 02 19:39:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtaCk-0004XD-HG for secsh-archive@megatron.ietf.org; Mon, 02 Jan 2006 19:39:10 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02728 for ; Mon, 2 Jan 2006 19:37:54 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A887163B35F; Tue, 3 Jan 2006 00:39: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 D709563B18B for ; Tue, 3 Jan 2006 00:39:04 +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 8342709; Mon, 02 Jan 2006 17:39:03 -0700 Message-ID: <43B9C793.8090401@vandyke.com> Date: Mon, 02 Jan 2006 17:38:43 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Nicolas Williams , Bill Sommerfeld , Colin Watson , ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode References: <20051231160559.GK4231@riva.ucam.org> <1136240979.12972.48.camel@thunk> <20060102224358.GE18698@binky.Central.Sun.COM> <6EEB1C8BF6320CE0BC7A70D9@bistromath.pc.cs.cmu.edu> <20060102233034.GH18698@binky.Central.Sun.COM> <1AF762753D5F622D66C0A8AE@bistromath.pc.cs.cmu.edu> In-Reply-To: <1AF762753D5F622D66C0A8AE@bistromath.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > I'm removing the Debian bug and original reporter from the CC list; I > don't think they care about our protocol design discussion. > > > On Monday, January 02, 2006 05:30:34 PM -0600 Nicolas Williams > wrote: > >>> One could argue that an SSH server running on such a system should look >>> at the configured locale and configure the PTY appropriately, and >>> that's probably even a good idea. However, a user using 'stty' to >>> change terminal modes at the remote end of an ssh connection has an >>> expectation that the change will propagate to the local terminal as >>> much as possible, and the point of defining a bit for IUTF8 is to help >>> make that possible. >> >> Did you switch local/remote here? > > Nope. If I type 'stty iutf8', stty does an ioctl on the pty slave on > the remote machine (the ssh server). My expectation is that sshd will > notice the change, propagate it down the wire, and my ssh client will > make the same ioctl on my terminal (assuming, of course, that both > terminals support the bit). I don't think this currently happens with any of the bits; the term bits (if I recall correctly) are sent only from client to server when the pty is requested. I don't believe there is currently a way on the wire for either the or the server to change their values after the pty is requested. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 03 14:19:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrgY-0001Um-BP for secsh-archive@megatron.ietf.org; Tue, 03 Jan 2006 14:19:06 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14977 for ; Tue, 3 Jan 2006 14:17:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 27C8E63B528; Tue, 3 Jan 2006 19:19:00 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id 5B33563B527 for ; Tue, 3 Jan 2006 19:18:59 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k03JIwdK010788 for ; Tue, 3 Jan 2006 11:18:58 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k03JIv32005080 for ; Tue, 3 Jan 2006 12:18:58 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k03JIv87002821; Tue, 3 Jan 2006 13:18:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k03JIuTB002820; Tue, 3 Jan 2006 13:18:56 -0600 (CST) Date: Tue, 3 Jan 2006 13:18:56 -0600 From: Nicolas Williams To: Joseph Galbraith Cc: Jeffrey Hutzelman , Bill Sommerfeld , Colin Watson , ietf-ssh@NetBSD.org Subject: Re: IUTF8 pseudo-terminal mode Message-ID: <20060103191855.GI18698@binky.Central.Sun.COM> References: <20051231160559.GK4231@riva.ucam.org> <1136240979.12972.48.camel@thunk> <20060102224358.GE18698@binky.Central.Sun.COM> <6EEB1C8BF6320CE0BC7A70D9@bistromath.pc.cs.cmu.edu> <20060102233034.GH18698@binky.Central.Sun.COM> <1AF762753D5F622D66C0A8AE@bistromath.pc.cs.cmu.edu> <43B9C793.8090401@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B9C793.8090401@vandyke.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jan 02, 2006 at 05:38:43PM -0700, Joseph Galbraith wrote: > Jeffrey Hutzelman wrote: > > On Monday, January 02, 2006 05:30:34 PM -0600 Nicolas Williams > > wrote: > >> Did you switch local/remote here? > > > > Nope. If I type 'stty iutf8', stty does an ioctl on the pty slave on > > the remote machine (the ssh server). My expectation is that sshd will > > notice the change, propagate it down the wire, and my ssh client will > > make the same ioctl on my terminal (assuming, of course, that both > > terminals support the bit). > > I don't think this currently happens with any of the bits; the > term bits (if I recall correctly) are sent only from client to > server when the pty is requested. I don't believe there > is currently a way on the wire for either the or the server > to change their values after the pty is requested. Correct. The client has to put its terminal into raw, echoff mode in order to let the pty on the server side handle stty settings on the remote side correctly. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 05 20:23:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EugJz-0001fK-ON for secsh-archive@megatron.ietf.org; Thu, 05 Jan 2006 20:23:12 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20743 for ; Thu, 5 Jan 2006 20:21:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2BC9163B17D; Fri, 6 Jan 2006 01:23:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 467EB63B10C for ; Fri, 6 Jan 2006 01:23:05 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2006 17:23:05 -0800 X-IronPort-AV: i="3.99,336,1131350400"; d="scan'208"; a="387946116:sNHT60943476" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k061N4jt004230; Thu, 5 Jan 2006 17:23:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: presence of authority was Re: SFTP URI issues Date: Thu, 5 Jan 2006 17:29:20 -0800 Message-ID: <7210B31550AC934A8637D6619739CE690672727E@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: presence of authority was Re: SFTP URI issues Thread-Index: AcYMa/0lwsGsSq9kSlWW6wA7gS2LTQF6x/3g From: "Salowey, Joe" To: "Tom Petch" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for catching this. In the SSH URI an authority should always be required, but the path should be empty (or perhaps ignored if it is there). So I think that the hier-part should be: hier-part =3D "//" authority ["/"] For SFTP I would think that an authority would always be required as well but the path could be there or empty =20 hier-part =3D "//" authority path-abempty=20 Make sense? =20 Joe=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, December 29, 2005 2:20 AM > To: Salowey, Joe; ietf-ssh@NetBSD.org > Subject: Re: presence of authority was Re: SFTP URI issues >=20 > ----- Original Message ----- > From: "Salowey, Joe" > To: "Tom Petch" ; > Sent: Wednesday, December 28, 2005 9:25 PM > Subject: RE: presence of authority was Re: SFTP URI issues >=20 >=20 > > This ABNF is for the SSH URI which should not contain a=20 > non-empty path. > > The deviation from the 3986 path was intended to describe=20 > this. I think > > the change is correct, but I could have missed something.=20 > The "sftp" URI > > uses the path description from 3986. > > > Yes, understood. I am being opaque:-( I was obliquely=20 > referring to the > addition of brackets in the SSH URI which, I believe, changes=20 > the meaning from > RFC3986 to mean that the ssh ABNF requires authority always=20 > to be present > whereas the URI ABNF only requires authority to be present=20 > for path-abempty, > not for the other variants of path. >=20 > So when the ABNF for the SFTP URI says it uses the path=20 > definition from RFC3986, > I am unclear what position it takes on authority, always=20 > present or not. >=20 > There is, I think, a defect in RFC3986 here, in that=20 > path-abempty, which is > allowed to start // (two solidus), is only permitted to be=20 > used when authority > is present - else the // that precedes authority could be=20 > confused with the // > that starts the path-abempty. Where RFC3986 could be=20 > defective is that > authority is defined as, being selective, >=20 > authority =3D host > host =3D reg-name > reg-name =3D *( unreserved / pct-encoded / sub-delims ) >=20 > which allows authority to be zero characters, in which case=20 > the // can get > confused with // :-) >=20 > So, you asked if it was ok to start a path with // - my=20 > reading of RFC3986 is > that that is what it intends to say but does not quite do so=20 > ie it is ok as long > as authority is present and is not zero length. If the last=20 > is what the ABNF for > the SFTP URI., or for the SSH URI, intends to say, then I=20 > think this should be > spelt out; but I am not clear what you are intending to say:-( >=20 > Tom Petch >=20 > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Wednesday, December 28, 2005 3:37 AM > > > To: Salowey, Joe; ietf-ssh@NetBSD.org > > > Subject: presence of authority was Re: SFTP URI issues > > > > > > Mmmm > > > > > > I should have added to my previous reply that I never find > > > RFC3986 easy to > > > understand, perhaps because it is not easy to understand:-( > > > > > > In RFC3986 is the following > > > hier-part =3D "//" authority path-abempty > > > / path-absolute > > > / path-rootless > > > / path-empty > > > which means > > > authority path-abempty OR > > > path-absolute OR > > > path-rootless OR > > > path-empty > > > while the I-D has > > > hier-part =3D "//" authority ( path-empty / path-abempty ) > > > which means > > > authority path-empty OR > > > authority path-abempty > > > Is this change intended? > > > > > > Tom Petch > > > > > > >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 07:58:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EurAU-0004ai-7r for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 07:58:08 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29303 for ; Fri, 6 Jan 2006 07:56:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9775363B174; Fri, 6 Jan 2006 12:58:00 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by mail.netbsd.org (Postfix) with ESMTP id 61D7D63B160 for ; Fri, 6 Jan 2006 12:57:59 +0000 (UTC) Received: from pc6 (1Cust49.tnt106.lnd4.gbr.da.uu.net [213.116.60.49]) by ranger.systems.pipex.net (Postfix) with SMTP id 896CEE0003D5; Fri, 6 Jan 2006 12:57:54 +0000 (GMT) Message-ID: <00f801c612b8$0800f240$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , References: <7210B31550AC934A8637D6619739CE690672727E@e2k-sea-xch2.sea-alpha.cisco.com> Subject: Re: presence of authority was Re: SFTP URI issues Date: Fri, 6 Jan 2006 12:54:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Salowey, Joe" To: "Tom Petch" ; Sent: Friday, January 06, 2006 2:29 AM Subject: RE: presence of authority was Re: SFTP URI issues Thanks for catching this. In the SSH URI an authority should always be required, but the path should be empty (or perhaps ignored if it is there). So I think that the hier-part should be: hier-part = "//" authority ["/"] For SFTP I would think that an authority would always be required as well but the path could be there or empty hier-part = "//" authority path-abempty Make sense? Joe Not sure. Staying with SSH for the moment, I am unclear about the trailing ["/"] and the precise semantic of empty path. To quote URI [RFC3986] The scheme and path components are required, though the path may be empty (no characters). When authority is present, the path must either be empty or begin with a slash ("/") character So there an empty path means no characters, but path must be present:-). Do you use empty in the same sense, or do you regard that lone / as an empty path? I am still unclear quite what it is you want to convey with the ABNF and so am uncertain whether or not the ABNF is suitable. I think we should follow URI whenever possible, eg in its semantics of empty and in its insistence that a path is present even if it is empty. (I don't know the ABNF for 'ignore a path if present' and suspect that that is better expressed in English:-) > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Thursday, December 29, 2005 2:20 AM > To: Salowey, Joe; ietf-ssh@NetBSD.org > Subject: Re: presence of authority was Re: SFTP URI issues > > ----- Original Message ----- > From: "Salowey, Joe" > To: "Tom Petch" ; > Sent: Wednesday, December 28, 2005 9:25 PM > Subject: RE: presence of authority was Re: SFTP URI issues > > > > This ABNF is for the SSH URI which should not contain a > non-empty path. > > The deviation from the 3986 path was intended to describe > this. I think > > the change is correct, but I could have missed something. > The "sftp" URI > > uses the path description from 3986. > > > Yes, understood. I am being opaque:-( I was obliquely > referring to the > addition of brackets in the SSH URI which, I believe, changes > the meaning from > RFC3986 to mean that the ssh ABNF requires authority always > to be present > whereas the URI ABNF only requires authority to be present > for path-abempty, > not for the other variants of path. > > So when the ABNF for the SFTP URI says it uses the path > definition from RFC3986, > I am unclear what position it takes on authority, always > present or not. > > There is, I think, a defect in RFC3986 here, in that > path-abempty, which is > allowed to start // (two solidus), is only permitted to be > used when authority > is present - else the // that precedes authority could be > confused with the // > that starts the path-abempty. Where RFC3986 could be > defective is that > authority is defined as, being selective, > > authority = host > host = reg-name > reg-name = *( unreserved / pct-encoded / sub-delims ) > > which allows authority to be zero characters, in which case > the // can get > confused with // :-) > > So, you asked if it was ok to start a path with // - my > reading of RFC3986 is > that that is what it intends to say but does not quite do so > ie it is ok as long > as authority is present and is not zero length. If the last > is what the ABNF for > the SFTP URI., or for the SSH URI, intends to say, then I > think this should be > spelt out; but I am not clear what you are intending to say:-( > > Tom Petch > > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Wednesday, December 28, 2005 3:37 AM > > > To: Salowey, Joe; ietf-ssh@NetBSD.org > > > Subject: presence of authority was Re: SFTP URI issues > > > > > > Mmmm > > > > > > I should have added to my previous reply that I never find > > > RFC3986 easy to > > > understand, perhaps because it is not easy to understand:-( > > > > > > In RFC3986 is the following > > > hier-part = "//" authority path-abempty > > > / path-absolute > > > / path-rootless > > > / path-empty > > > which means > > > authority path-abempty OR > > > path-absolute OR > > > path-rootless OR > > > path-empty > > > while the I-D has > > > hier-part = "//" authority ( path-empty / path-abempty ) > > > which means > > > authority path-empty OR > > > authority path-abempty > > > Is this change intended? > > > > > > Tom Petch > > > > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 14:20:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eux8e-0000qu-Hf for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 14:20:36 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24041 for ; Fri, 6 Jan 2006 14:19:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3699F63B144; Fri, 6 Jan 2006 19:20:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id 457FD63B11A for ; Fri, 6 Jan 2006 19:20:24 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06JJPi11743; Fri, 6 Jan 2006 11:19:25 -0800 (PST) Message-Id: <200601061919.k06JJPi11743@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4251 on The Secure Shell (SSH) Protocol Architecture Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Jan 2006 11:19:25 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4251 Title: The Secure Shell (SSH) Protocol Architecture Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox: ylo@ssh.com, clonvick@cisco.com Pages: 30 Characters: 71750 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-architecture-22.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4251.txt The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060106111806.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4251 --OtherAccess Content-Type: Message/External-body; name="rfc4251.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060106111806.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 14:21:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eux9h-0001Ea-N2 for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 14:21:41 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24320 for ; Fri, 6 Jan 2006 14:20:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AAB1163B13B; Fri, 6 Jan 2006 19:21:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id AC50E63B11A for ; Fri, 6 Jan 2006 19:21:37 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06JHpi11402; Fri, 6 Jan 2006 11:17:51 -0800 (PST) Message-Id: <200601061917.k06JHpi11402@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4250 on The Secure Shell (SSH) Protocol Assigned Numbers Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Jan 2006 11:17:51 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4250 Title: The Secure Shell (SSH) Protocol Assigned Numbers Author(s): S. Lehtinen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox: sjl@ssh.com, clonvick@cisco.com Pages: 20 Characters: 44010 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-assignednumbers-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4250.txt This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060106111636.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4250 --OtherAccess Content-Type: Message/External-body; name="rfc4250.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060106111636.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 14:22:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxAN-0001NW-GP for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 14:22:24 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24440 for ; Fri, 6 Jan 2006 14:21:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AB7AF63B1A0; Fri, 6 Jan 2006 19:22:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id 8A7BE63B11A for ; Fri, 6 Jan 2006 19:22:10 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06JLNi12808; Fri, 6 Jan 2006 11:21:23 -0800 (PST) Message-Id: <200601061921.k06JLNi12808@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4252 on The Secure Shell (SSH) Authentication Protocol Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Jan 2006 11:21:23 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4252 Title: The Secure Shell (SSH) Authentication Protocol Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox: ylo@ssh.com, clonvick@cisco.com Pages: 17 Characters: 34268 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-userauth-27.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4252.txt The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060106112025.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4252 --OtherAccess Content-Type: Message/External-body; name="rfc4252.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060106112025.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 14:23:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxBS-00026R-BI for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 14:23:30 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24877 for ; Fri, 6 Jan 2006 14:22:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0010363B183; Fri, 6 Jan 2006 19:23:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id 0C3F363B11A for ; Fri, 6 Jan 2006 19:23:24 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06JMki13138; Fri, 6 Jan 2006 11:22:46 -0800 (PST) Message-Id: <200601061922.k06JMki13138@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4253 on The Secure Shell (SSH) Transport Layer Protocol Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Jan 2006 11:22:46 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4253 Title: The Secure Shell (SSH) Transport Layer Protocol Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox: ylo@ssh.com, clonvick@cisco.com Pages: 32 Characters: 68263 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-transport-24.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4253.txt The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060106112134.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4253 --OtherAccess Content-Type: Message/External-body; name="rfc4253.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060106112134.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 14:25:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxDL-0002qi-VH for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 14:25:28 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25440 for ; Fri, 6 Jan 2006 14:24:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D5AE363B1A7; Fri, 6 Jan 2006 19:25:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id EA31663B11A for ; Fri, 6 Jan 2006 19:25:22 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06JO7i13672; Fri, 6 Jan 2006 11:24:07 -0800 (PST) Message-Id: <200601061924.k06JO7i13672@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4254 on The Secure Shell (SSH) Connection Protocol Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Jan 2006 11:24:07 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4254 Title: The Secure Shell (SSH) Connection Protocol Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox: ylo@ssh.com, clonvick@cisco.com Pages: 24 Characters: 50338 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-connect-25.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4254.txt Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060106112300.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4254 --OtherAccess Content-Type: Message/External-body; name="rfc4254.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060106112300.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 14:26:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxED-00035B-Nh for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 14:26:21 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25635 for ; Fri, 6 Jan 2006 14:25:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D173163B195; Fri, 6 Jan 2006 19:26:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id B630963B11A for ; Fri, 6 Jan 2006 19:26:17 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06JPSi14177; Fri, 6 Jan 2006 11:25:28 -0800 (PST) Message-Id: <200601061925.k06JPSi14177@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4255 on Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Jan 2006 11:25:27 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4255 Title: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints Author(s): J. Schlyter, W. Griffin Status: Standards Track Date: January 2006 Mailbox: jakob@openssh.com, wgriffin@sparta.com Pages: 9 Characters: 18399 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-dns-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4255.txt This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060106112415.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4255 --OtherAccess Content-Type: Message/External-body; name="rfc4255.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060106112415.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 06 14:29:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxHE-0004If-84 for secsh-archive@megatron.ietf.org; Fri, 06 Jan 2006 14:29:28 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26485 for ; Fri, 6 Jan 2006 14:28:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EACE063B1AD; Fri, 6 Jan 2006 19:29:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id 0BBED63B11A for ; Fri, 6 Jan 2006 19:29:11 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06JRNi15122; Fri, 6 Jan 2006 11:27:23 -0800 (PST) Message-Id: <200601061927.k06JRNi15122@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4256 on Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Jan 2006 11:27:23 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4256 Title: Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) Author(s): F. Cusack, M. Forssen Status: Standards Track Date: January 2006 Mailbox: frank@savecore.net, maf@appgate.com Pages: 12 Characters: 24728 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-auth-kbdinteract-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4256.txt The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060106112532.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4256 --OtherAccess Content-Type: Message/External-body; name="rfc4256.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060106112532.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 07 16:27:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvLbS-0000ia-LN for secsh-archive@megatron.ietf.org; Sat, 07 Jan 2006 16:27:58 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05850 for ; Sat, 7 Jan 2006 16:26:40 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DA9FE63B2E2; Sat, 7 Jan 2006 21:27:53 +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 334F563B1E2 for ; Sat, 7 Jan 2006 21:27:53 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EvLbM-00008q-00 for ietf-ssh@netbsd.org; Sat, 07 Jan 2006 21:27:52 +0000 Date: Sat, 7 Jan 2006 21:27:52 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: collated comments for -dns (RFC 4255) and -kbdinteract (RFC 4256) Message-ID: <20060107212752.GA29425@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051118004250.GD5569@chiark.greenend.org.uk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Only one of these comments (10) is addressed in the published kbdinteract (RFC 4256). Is it worth raising some of these as RFC errata? The ones that might be worth mentioning are: - 2/9 (confusion over whether IANA assign code points; the current registry does not, which is correct) - 6 (language-tag-related stuff that makes no sense) - 8 ("compared" vs current "compare them") -- perhaps a semantic change From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 08 19:37:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evl2B-0005iY-3e for secsh-archive@megatron.ietf.org; Sun, 08 Jan 2006 19:37:15 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29962 for ; Sun, 8 Jan 2006 19:35:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9DEA663B29C; Mon, 9 Jan 2006 00:37:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cb1.warwick.net (cb1.warwick.net [204.255.24.233]) by mail.netbsd.org (Postfix) with ESMTP id C7F0963B122 for ; Mon, 9 Jan 2006 00:37:09 +0000 (UTC) Received: (from httpd@localhost) by cb1.warwick.net (8.11.6/8.11.6) id k08NT9N03095; Sun, 8 Jan 2006 18:29:09 -0500 Date: Sun, 8 Jan 2006 18:29:09 -0500 Message-Id: <200601082329.k08NT9N03095@cb1.warwick.net> To: ietf-ssh@NetBSD.org Subject: Account Update From: National Australia Bank MIME-Version: 1.0 Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA29962

Dear National Australia Bank customer,

We at National = Australia Bank, would like to remind you that your National Australia Ban= k Account has not been updated to the latest Online Access Agreement for = National Australia Bank Online Services.

In order for us, at Natio= nal Australia Bank to guarantee your online security, you need to update = your account information. We urge you to partner with us to prevent consu= mer fraud, by going through the 2 steps National Australia Bank Account C= onfirmation process. This operation involves logging in and confirming yo= ur identity over a secure connection at:

http://www.national= .com.au/?ncID=3DZBG

After completing t! his process, you will be informed that your account has been updated and = you will be redirected to the actual Online Access Agreement, for you to = review.

Thank you for choosing National Australia Bank as your Fina= ncial Institution.

=A9 National Australia Ba= nk Limited. Use of the information contained on this page is governed by = Australian law and is subject to the disclaimers which can be read on the= disclaimer page . View the National Privacy Policy .

From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 09 01:03:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evq7r-0005gP-5O for secsh-archive@megatron.ietf.org; Mon, 09 Jan 2006 01:03:27 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18203 for ; Mon, 9 Jan 2006 01:02:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E48E63B21C; Mon, 9 Jan 2006 06:03:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 0B0F663B15F for ; Mon, 9 Jan 2006 06:03:20 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Jan 2006 22:03:21 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0963Jjt026598; Sun, 8 Jan 2006 22:03:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: presence of authority was Re: SFTP URI issues Date: Sun, 8 Jan 2006 22:09:37 -0800 Message-ID: <7210B31550AC934A8637D6619739CE69067275B9@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: presence of authority was Re: SFTP URI issues Thread-Index: AcYSwbTCrs2e7GGOTZOPGeQxvNFnMACH4V6g From: "Salowey, Joe" To: "Tom Petch" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Friday, January 06, 2006 3:55 AM > To: Salowey, Joe; ietf-ssh@NetBSD.org > Subject: Re: presence of authority was Re: SFTP URI issues >=20 > > Tom Petch > ----- Original Message ----- > From: "Salowey, Joe" > To: "Tom Petch" ; > Sent: Friday, January 06, 2006 2:29 AM > Subject: RE: presence of authority was Re: SFTP URI issues >=20 > Thanks for catching this. In the SSH URI an authority should=20 > always be > required, but the path should be empty (or perhaps ignored if it is > there). So I think that the hier-part should be: >=20 > hier-part =3D "//" authority ["/"] >=20 > For SFTP I would think that an authority would always be required as > well but the path could be there or empty >=20 > hier-part =3D "//" authority path-abempty >=20 > Make sense? >=20 > Joe >=20 > > Not sure. Staying with SSH for the moment, I am unclear=20 > about the trailing > ["/"] and the precise semantic of empty path. To quote URI [RFC3986] > The scheme and path components are required, though the path may be > empty (no characters). When authority is present, the path must > either be empty or begin with a slash ("/") character > So there an empty path means no characters, but path must be=20 > present:-). Do you > use empty in the same sense, or do you regard that lone / as=20 > an empty path? I > am still unclear quite what it is you want to convey with the=20 > ABNF and so am > uncertain whether or not the ABNF is suitable. >=20 > I think we should follow URI whenever possible, eg in its=20 > semantics of empty and > in its insistence that a path is present even if it is empty.=20 > (I don't know > the ABNF for 'ignore a path if present' and suspect that that=20 > is better > expressed in English:-) > [Joe] OK, so how about for ssh hier-part =3D "//" authority path-empty With some text in the document that states if there is a non-empty path it MUST be ignored. =20 =20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Thursday, December 29, 2005 2:20 AM > > To: Salowey, Joe; ietf-ssh@NetBSD.org > > Subject: Re: presence of authority was Re: SFTP URI issues > > > > ----- Original Message ----- > > From: "Salowey, Joe" > > To: "Tom Petch" ; > > Sent: Wednesday, December 28, 2005 9:25 PM > > Subject: RE: presence of authority was Re: SFTP URI issues > > > > > > > This ABNF is for the SSH URI which should not contain a > > non-empty path. > > > The deviation from the 3986 path was intended to describe > > this. I think > > > the change is correct, but I could have missed something. > > The "sftp" URI > > > uses the path description from 3986. > > > > > Yes, understood. I am being opaque:-( I was obliquely > > referring to the > > addition of brackets in the SSH URI which, I believe, changes > > the meaning from > > RFC3986 to mean that the ssh ABNF requires authority always > > to be present > > whereas the URI ABNF only requires authority to be present > > for path-abempty, > > not for the other variants of path. > > > > So when the ABNF for the SFTP URI says it uses the path > > definition from RFC3986, > > I am unclear what position it takes on authority, always > > present or not. > > > > There is, I think, a defect in RFC3986 here, in that > > path-abempty, which is > > allowed to start // (two solidus), is only permitted to be > > used when authority > > is present - else the // that precedes authority could be > > confused with the // > > that starts the path-abempty. Where RFC3986 could be > > defective is that > > authority is defined as, being selective, > > > > authority =3D host > > host =3D reg-name > > reg-name =3D *( unreserved / pct-encoded / sub-delims ) > > > > which allows authority to be zero characters, in which case > > the // can get > > confused with // :-) > > > > So, you asked if it was ok to start a path with // - my > > reading of RFC3986 is > > that that is what it intends to say but does not quite do so > > ie it is ok as long > > as authority is present and is not zero length. If the last > > is what the ABNF for > > the SFTP URI., or for the SSH URI, intends to say, then I > > think this should be > > spelt out; but I am not clear what you are intending to say:-( > > > > Tom Petch > > > > > > -----Original Message----- > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > Sent: Wednesday, December 28, 2005 3:37 AM > > > > To: Salowey, Joe; ietf-ssh@NetBSD.org > > > > Subject: presence of authority was Re: SFTP URI issues > > > > > > > > Mmmm > > > > > > > > I should have added to my previous reply that I never find > > > > RFC3986 easy to > > > > understand, perhaps because it is not easy to understand:-( > > > > > > > > In RFC3986 is the following > > > > hier-part =3D "//" authority path-abempty > > > > / path-absolute > > > > / path-rootless > > > > / path-empty > > > > which means > > > > authority path-abempty OR > > > > path-absolute OR > > > > path-rootless OR > > > > path-empty > > > > while the I-D has > > > > hier-part =3D "//" authority ( path-empty / path-abempty ) > > > > which means > > > > authority path-empty OR > > > > authority path-abempty > > > > Is this change intended? > > > > > > > > Tom Petch > > > > > > > > > > >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 09 10:31:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvyzH-0005yi-4J for secsh-archive@megatron.ietf.org; Mon, 09 Jan 2006 10:31:11 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21940 for ; Mon, 9 Jan 2006 10:29:51 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5F43363B2BC; Mon, 9 Jan 2006 15:31:05 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by mail.netbsd.org (Postfix) with ESMTP id F2CB963B147 for ; Mon, 9 Jan 2006 15:31:03 +0000 (UTC) Received: from pc6 (1Cust154.tnt2.lnd4.gbr.da.uu.net [62.188.131.154]) by blaster.systems.pipex.net (Postfix) with SMTP id 20F0EE0003C7; Mon, 9 Jan 2006 15:10:55 +0000 (GMT) Message-ID: <00fd01c61526$18e2dfe0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , References: <7210B31550AC934A8637D6619739CE69067275B9@e2k-sea-xch2.sea-alpha.cisco.com> Subject: Re: presence of authority was Re: SFTP URI issues Date: Mon, 9 Jan 2006 15:01:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Salowey, Joe" To: "Tom Petch" ; Sent: Monday, January 09, 2006 7:09 AM Subject: RE: presence of authority was Re: SFTP URI issues > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Friday, January 06, 2006 3:55 AM > To: Salowey, Joe; ietf-ssh@NetBSD.org > Subject: Re: presence of authority was Re: SFTP URI issues > > > Tom Petch > ----- Original Message ----- > From: "Salowey, Joe" > To: "Tom Petch" ; > Sent: Friday, January 06, 2006 2:29 AM > Subject: RE: presence of authority was Re: SFTP URI issues > > Thanks for catching this. In the SSH URI an authority should always be > required, but the path should be empty (or perhaps ignored if it is > there). So I think that the hier-part should be: > > hier-part = "//" authority ["/"] > > For SFTP I would think that an authority would always be required as > well but the path could be there or empty > > hier-part = "//" authority path-abempty > > Make sense? > > Joe > > > Not sure. Staying with SSH for the moment, I am unclear about the trailing > ["/"] and the precise semantic of empty path. To quote URI [RFC3986] > The scheme and path components are required, though the path may be > empty (no characters). When authority is present, the path must > either be empty or begin with a slash ("/") character > So there an empty path means no characters, but path must be > present:-). Do you > use empty in the same sense, or do you regard that lone / as an empty path? I > am still unclear quite what it is you want to convey with the ABNF and so am > uncertain whether or not the ABNF is suitable. > > I think we should follow URI whenever possible, eg in its semantics of empty and > in its insistence that a path is present even if it is empty. (I don't know > the ABNF for 'ignore a path if present' and suspect that that is better > expressed in English:-) > [Joe] OK, so how about for ssh hier-part = "//" authority path-empty With some text in the document that states if there is a non-empty path it MUST be ignored. [tom2] Yes, either that or hier-part = "//" authority path-abempty I see the difference being a matter of how the ABNF is used. I understand that implementors may use ABNF as input to a syntax checker, if which case would cause a syntax failure when a to-be-ignored path is present while would allow the syntax but still cause the path to be semantically ignored. I am fine with either. On a related topic, I did post the URI list to check that in can be empty, ie a zero length string and yes, generic URI syntax does allow that. It is used, for example, by smb which allows smb:// with nothing following. I think you said that host should be non-empty for ssh: in which case, I would add a line to that effect eg host MUST/SHOULD be a non-empty string. Tom Petch > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Thursday, December 29, 2005 2:20 AM > > To: Salowey, Joe; ietf-ssh@NetBSD.org > > Subject: Re: presence of authority was Re: SFTP URI issues > > > > ----- Original Message ----- > > From: "Salowey, Joe" > > To: "Tom Petch" ; > > Sent: Wednesday, December 28, 2005 9:25 PM > > Subject: RE: presence of authority was Re: SFTP URI issues > > > > > > > This ABNF is for the SSH URI which should not contain a > > non-empty path. > > > The deviation from the 3986 path was intended to describe > > this. I think > > > the change is correct, but I could have missed something. > > The "sftp" URI > > > uses the path description from 3986. > > > > > Yes, understood. I am being opaque:-( I was obliquely > > referring to the > > addition of brackets in the SSH URI which, I believe, changes > > the meaning from > > RFC3986 to mean that the ssh ABNF requires authority always > > to be present > > whereas the URI ABNF only requires authority to be present > > for path-abempty, > > not for the other variants of path. > > > > So when the ABNF for the SFTP URI says it uses the path > > definition from RFC3986, > > I am unclear what position it takes on authority, always > > present or not. > > > > There is, I think, a defect in RFC3986 here, in that > > path-abempty, which is > > allowed to start // (two solidus), is only permitted to be > > used when authority > > is present - else the // that precedes authority could be > > confused with the // > > that starts the path-abempty. Where RFC3986 could be > > defective is that > > authority is defined as, being selective, > > > > authority = host > > host = reg-name > > reg-name = *( unreserved / pct-encoded / sub-delims ) > > > > which allows authority to be zero characters, in which case > > the // can get > > confused with // :-) > > > > So, you asked if it was ok to start a path with // - my > > reading of RFC3986 is > > that that is what it intends to say but does not quite do so > > ie it is ok as long > > as authority is present and is not zero length. If the last > > is what the ABNF for > > the SFTP URI., or for the SSH URI, intends to say, then I > > think this should be > > spelt out; but I am not clear what you are intending to say:-( > > > > Tom Petch > > > > > > -----Original Message----- > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > Sent: Wednesday, December 28, 2005 3:37 AM > > > > To: Salowey, Joe; ietf-ssh@NetBSD.org > > > > Subject: presence of authority was Re: SFTP URI issues > > > > > > > > Mmmm > > > > > > > > I should have added to my previous reply that I never find > > > > RFC3986 easy to > > > > understand, perhaps because it is not easy to understand:-( > > > > > > > > In RFC3986 is the following > > > > hier-part = "//" authority path-abempty > > > > / path-absolute > > > > / path-rootless > > > > / path-empty > > > > which means > > > > authority path-abempty OR > > > > path-absolute OR > > > > path-rootless OR > > > > path-empty > > > > while the I-D has > > > > hier-part = "//" authority ( path-empty / path-abempty ) > > > > which means > > > > authority path-empty OR > > > > authority path-abempty > > > > Is this change intended? > > > > > > > > Tom Petch > > > > > > > > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 10 11:52:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMjK-0006hb-BG for secsh-archive@megatron.ietf.org; Tue, 10 Jan 2006 11:52:18 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20489 for ; Tue, 10 Jan 2006 11:50:56 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3431363B167; Tue, 10 Jan 2006 16:52:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by mail.netbsd.org (Postfix) with ESMTP id 2D73563B154 for ; Tue, 10 Jan 2006 16:52:04 +0000 (UTC) Received: from pc6 (1Cust243.tnt28.lnd4.gbr.da.uu.net [62.188.156.243]) by astro.systems.pipex.net (Postfix) with SMTP id 7D8D0E00031D; Tue, 10 Jan 2006 16:52:02 +0000 (GMT) Message-ID: <028d01c615fd$63188ba0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , References: <7210B31550AC934A8637D6619739CE690672727E@e2k-sea-xch2.sea-alpha.cisco.com> Subject: SFTP was Re: presence of authority was Re: SFTP URI issues Date: Tue, 10 Jan 2006 16:48:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Salowey, Joe" To: "Tom Petch" ; Sent: Friday, January 06, 2006 2:29 AM Subject: RE: presence of authority was Re: SFTP URI issues > Thanks for catching this. In the SSH URI an authority should always be > required, but the path should be empty (or perhaps ignored if it is > there). So I think that the hier-part should be: > > hier-part = "//" authority ["/"] > > For SFTP I would think that an authority would always be required as > well but the path could be there or empty > > hier-part = "//" authority path-abempty > > Joe > Assuming that the SSH URI is sorted, back to the SFTP one. Yes that ABNF is fine but I am not sure about the following paragraph in the I-D, on two counts. a) The Generic Syntax for URI [RFC3986] says "If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character. " which is what achieves. The I-D goes on to say that if a path starts with a / then it is relative to the root of the file system, otherwise it is relative to the user's home or default directory. But the Generic Syntax requires the path to start with a / or be empty, so you can never have a path relative to the user's home directory except for an empty one:-) b) In this section, the I-D says that / is a reserved character - I agree - and that it must be encoded - disagree. In URI, reserved is not used in the way I would like to see it used - it means that sometimes the character must be encoded, other times not:-{ " If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed." The initial / of is a delimiter between authority and path and so must be just that, / not %2F. So are you allowing sftp://example.com/%2Fetc/protocols for absolute paths as opposed to sftp://example.com/mylocalfile.txt for relative ones? I am unclear. (The end of will be signalled by the end of the URI or the characters ? or # and so / is not a delimiter for that purpose and can appear as such as many times as it likes unencoded within such a path). Tom Petch From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 10 12:28:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNIQ-0002XT-44 for secsh-archive@megatron.ietf.org; Tue, 10 Jan 2006 12:28:34 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23200 for ; Tue, 10 Jan 2006 12:27:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0395C63B1C3; Tue, 10 Jan 2006 17:28:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 393C563B167 for ; Tue, 10 Jan 2006 17:28:28 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Jan 2006 09:28:28 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0AHSRWF013725; Tue, 10 Jan 2006 09:28:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: SFTP was Re: presence of authority was Re: SFTP URI issues Date: Tue, 10 Jan 2006 09:34:45 -0800 Message-ID: <7210B31550AC934A8637D6619739CE690672795A@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: SFTP was Re: presence of authority was Re: SFTP URI issues Thread-Index: AcYWBxRCyxIrK0KJTPmS9faTiXRYFwAAHMiA From: "Salowey, Joe" To: "Tom Petch" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable =20 =20 >=20 > a) The Generic Syntax for URI [RFC3986] says > "If a URI contains an authority component, then the path component > must either be empty or begin with a slash ("/") character. " > which is what achieves. The I-D goes on to say that > if a path starts with a / then it is relative to the root of=20 > the file system, > otherwise it is relative to the user's home or default=20 > directory. But the > Generic Syntax requires the path to start with a / or be=20 > empty, so you can never > have a path relative to the user's home directory except for=20 > an empty one:-) >=20 > b) In this section, the I-D says that / is a reserved=20 > character - I agree - and > that it must be encoded - disagree. In URI, reserved is not=20 > used in the way I > would like to see it used - it means that sometimes the=20 > character must be > encoded, other times not:-{ > " If data for a URI component would conflict with a reserved > character's purpose as a delimiter, then the conflicting=20 > data must be > percent-encoded before the URI is formed." > The initial / of is a delimiter between=20 > authority and path and so > must be just that, / not %2F. > So are you allowing > sftp://example.com/%2Fetc/protocols > for absolute paths as opposed to > sftp://example.com/mylocalfile.txt > for relative ones? > [Joe] Yes, that was the intent of the draft. However this doesn't seem to be the best way to handle this. I think most people would rather not have to enter in %2F into a URL to specify an absolute path. Using "//" to represent the absolute path is better and you confirm that it would work fine. =20 Is this behavior consistent with other URLs? In RFC3986 these are referred to as absolute paths so perhaps it would be better to have paths default to root and define a special delimiter to indicate home directory at the beginning of the path. This would seem to make it more likely that an HTTP URL path would also work as an SFTP URL path, but perhaps the two cases are too different for this actually to work. =20 > I am unclear. >=20 > (The end of will be signalled by the end of=20 > the URI or the > characters ? or # and so / is not a delimiter for that=20 > purpose and can appear as > such as many times as it likes unencoded within such a path). >=20 > Tom Petch >=20 > >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 10 15:57:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQYl-0002WI-Ar for secsh-archive@megatron.ietf.org; Tue, 10 Jan 2006 15:57:39 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07693 for ; Tue, 10 Jan 2006 15:56:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 22B9D63B32E; Tue, 10 Jan 2006 20:57:33 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by mail.netbsd.org (Postfix) with ESMTP id DF04063B30B for ; Tue, 10 Jan 2006 20:57:31 +0000 (UTC) Received: from pc6 (1Cust242.tnt24.lnd4.gbr.da.uu.net [62.188.151.242]) by astro.systems.pipex.net (Postfix) with SMTP id 086E8E00041B; Tue, 10 Jan 2006 20:57:28 +0000 (GMT) Message-ID: <04ce01c6161f$acc00360$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , References: <7210B31550AC934A8637D6619739CE690672795A@e2k-sea-xch2.sea-alpha.cisco.com> Subject: Re: SFTP was Re: presence of authority was Re: SFTP URI issues Date: Tue, 10 Jan 2006 20:54:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit My sense is that the Generic URI syntax has been retrofitted to a variety of pre-existing paths and so looks a bit like Topsy, and would have looked different had it come first:-) I like RFC1738 as a (obsolescent) collection of schemes and syntax and, which I had forgotten, does include, for ftp, %2F, differentiating //etc as generating CWD /%2Fetc as generating CWD /etc /etc as generating CWD etc It says, and RFC3986 does not, that the first slash is not part of the path but a separator, with another character for home directory draft-hoffman-ftp-uri-04.txt, which is/was intended to supersede that piece, says that most implementations put in a / anyway in conflict with RFC1738. That I-D did run into some difficulties which may be why I cannot see it as an RFC. (There was an e-mail from Paul Hoffman to the URI list that he was abandoning work on the file: scheme because consensus was impossible but I never saw such a statement for ftp:) In between came RFC2396 which warns us that / delimits parts of the hierarchy and is not to be confused with the identical / which is used as part of a path. IMHO, it is a mess because / was chosen as a URI delimiter when it already was in use in file paths. Still, RFC3986 is what matters and that allows us // at the start of a path (or /// for that matter) to interpret as we will. I think // for an absolute path is fine. I had always seen tilde ~ as the indicator of user directory. It is an unreserved character in most URI (tel being the exception) which is probably why I cannot see its use being defined in any other URI. Would it do, ie // for absolute /~ for relative and / being invalid? or does this run into the same problem namely that the tilde may or may not already be there as part of the path the end user wishes to provide via the URI to client and thence to server? Tom Petch ----- Original Message ----- From: "Salowey, Joe" To: "Tom Petch" ; Sent: Tuesday, January 10, 2006 6:34 PM Subject: RE: SFTP was Re: presence of authority was Re: SFTP URI issues > > a) The Generic Syntax for URI [RFC3986] says > "If a URI contains an authority component, then the path component > must either be empty or begin with a slash ("/") character. " > which is what achieves. The I-D goes on to say that > if a path starts with a / then it is relative to the root of > the file system, > otherwise it is relative to the user's home or default > directory. But the > Generic Syntax requires the path to start with a / or be > empty, so you can never > have a path relative to the user's home directory except for > an empty one:-) > > b) In this section, the I-D says that / is a reserved > character - I agree - and > that it must be encoded - disagree. In URI, reserved is not > used in the way I > would like to see it used - it means that sometimes the > character must be > encoded, other times not:-{ > " If data for a URI component would conflict with a reserved > character's purpose as a delimiter, then the conflicting > data must be > percent-encoded before the URI is formed." > The initial / of is a delimiter between > authority and path and so > must be just that, / not %2F. > So are you allowing > sftp://example.com/%2Fetc/protocols > for absolute paths as opposed to > sftp://example.com/mylocalfile.txt > for relative ones? > [Joe] Yes, that was the intent of the draft. However this doesn't seem to be the best way to handle this. I think most people would rather not have to enter in %2F into a URL to specify an absolute path. Using "//" to represent the absolute path is better and you confirm that it would work fine. Is this behavior consistent with other URLs? In RFC3986 these are referred to as absolute paths so perhaps it would be better to have paths default to root and define a special delimiter to indicate home directory at the beginning of the path. This would seem to make it more likely that an HTTP URL path would also work as an SFTP URL path, but perhaps the two cases are too different for this actually to work. > I am unclear. > > (The end of will be signalled by the end of > the URI or the > characters ? or # and so / is not a delimiter for that > purpose and can appear as > such as many times as it likes unencoded within such a path). > > Tom Petch > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 11 15:47:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewmsb-0001lU-Vs for secsh-archive@megatron.ietf.org; Wed, 11 Jan 2006 15:47:38 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11522 for ; Wed, 11 Jan 2006 15:46:16 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5DF3163B17B; Wed, 11 Jan 2006 20:47:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id BEDC263B10E for ; Wed, 11 Jan 2006 20:47:30 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2006 12:47:31 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0BKlTkB027898 for ; Wed, 11 Jan 2006 12:47:30 -0800 (PST) Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 12:47:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Congratulations Date: Wed, 11 Jan 2006 12:47:20 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D8011491D5@xmb-sjc-218.amer.cisco.com> Thread-Topic: Congratulations Thread-Index: AcYW8DdhRtIyPhodRqWWm6EqGpSUAw== From: "Phillip Remaker \(remaker\)" To: Cc: "Chris Lonvick \(clonvick\)" X-OriginalArrivalTime: 11 Jan 2006 20:47:21.0263 (UTC) FILETIME=[37E933F0:01C616F0] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable After all these years, I see that the SSH core drafts have finally made RFC status, and there was not a single comment on the list, even after 5 days. Do we just not believe it? 8-) So, let me be the first to make the noise: Congratulations, folks. Well done, bravo!=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 11 20:57:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwriO-0004VL-Af for secsh-archive@megatron.ietf.org; Wed, 11 Jan 2006 20:57:24 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05249 for ; Wed, 11 Jan 2006 20:56:02 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8824763B214; Thu, 12 Jan 2006 01:57:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.netbsd.org (Postfix) with ESMTP id A00D563B209 for ; Thu, 12 Jan 2006 01:57:17 +0000 (UTC) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0C1u2i08934; Wed, 11 Jan 2006 17:56:02 -0800 (PST) Message-Id: <200601120156.k0C1u2i08934@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4344 on The Secure Shell (SSH) Transport Layer Encryption Modes Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 11 Jan 2006 17:56:02 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4344 Title: The Secure Shell (SSH) Transport Layer Encryption Modes Author(s): M. Bellare, T. Kohno, C. Namprempre Status: Standards Track Date: January 2006 Mailbox: mihir@cs.ucsd.edu, tkohno@cs.ucsd.edu, meaw@alum.mit.edu Pages: 12 Characters: 27521 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-newmodes-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4344.txt Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060111175447.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4344 --OtherAccess Content-Type: Message/External-body; name="rfc4344.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060111175447.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 11 22:19:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewt09-00017l-It for secsh-archive@megatron.ietf.org; Wed, 11 Jan 2006 22:19:49 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15655 for ; Wed, 11 Jan 2006 22:18:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4377E63B22C; Thu, 12 Jan 2006 03:19:43 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from dfw0.icgmedia.com (dfw0.icgmedia.com [69.93.3.2]) by mail.netbsd.org (Postfix) with ESMTP id 3B31D63B191 for ; Thu, 12 Jan 2006 03:19:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dfw0.icgmedia.com (Postfix) with ESMTP id 610691861D for ; Wed, 11 Jan 2006 20:56:50 -0600 (CST) Received: from dfw0.icgmedia.com ([127.0.0.1]) by localhost (dfw0 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01376-01 for ; Wed, 11 Jan 2006 20:56:45 -0600 (CST) Received: from netserver.braingia.org (24-197-255-185.dhcp.stpt.wi.charter.com [24.197.255.185]) by dfw0.icgmedia.com (Postfix) with ESMTP id 9722F18612 for ; Wed, 11 Jan 2006 20:56:45 -0600 (CST) Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10]) by netserver.braingia.org (8.13.4/8.13.4/Debian-3) with ESMTP id k0C2ufME024170 for ; Wed, 11 Jan 2006 20:56:41 -0600 Received: (from suehring@localhost) by netserver.braingia.org (8.13.4/8.13.4/Submit) id k0C2uaBT024166 for ietf-ssh@netbsd.org; Wed, 11 Jan 2006 20:56:36 -0600 Date: Wed, 11 Jan 2006 20:56:36 -0600 From: Steve Suehring To: ietf-ssh@NetBSD.org Subject: URI Draft Message-ID: <20060112025636.GA24032@mail.braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at icgmedia.com Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi all, I apologize if the following has already been discussed. I've been somewhat away from the mailing list for a time and can't remember if this was discussed here or elsewhere off-list. I, along with all of you, would like to get the URI draft wrapped up asap. From what I've gathered from the comments and discussion, there seems to be some disagreement on the formatting of scp and sftp URIs and less so for the ssh URI. Therefore, is it in the best interest of the community (and WG) to split these drafts into three separate drafts, one for each of scp, sftp, and ssh? The ssh draft might gain consensus from the WG leaving the other two to be discussed further. Opinions? Steve From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 13 09:06:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPZG-0000BX-Nl for secsh-archive@megatron.ietf.org; Fri, 13 Jan 2006 09:06:15 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07977 for ; Fri, 13 Jan 2006 09:04:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1FF7563B13E; Fri, 13 Jan 2006 14:06:05 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by mail.netbsd.org (Postfix) with ESMTP id A574C63B139 for ; Fri, 13 Jan 2006 14:06:03 +0000 (UTC) Received: from pc6 (1Cust43.tnt30.lnd3.gbr.da.uu.net [62.188.122.43]) by ranger.systems.pipex.net (Postfix) with SMTP id 3AB39E0003F6; Fri, 13 Jan 2006 14:05:59 +0000 (GMT) Message-ID: <024e01c61841$ae08f000$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , Subject: Re: SFTP was Re: presence of authority was Re: SFTP URI issues Date: Fri, 13 Jan 2006 13:43:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joe Expanding on my previous post, I think we have an intractable problem to which there is no good solution:-( I do see how you ended up with the use of %2F but believe that the experience of ftp: suggests that such a scheme would not get followed. URIs should be easy to transcribe and convey protocol information. So draft-ietf-secsh-filexfer-10.txt can define filenames as an almost free string, the only syntax being 'File names starting with a slash are absolute', wrap them up in a string and transmit them. URI cannot and must embed them in a syntax where / already has a special meaning. The logical approach is to make sftp://example.com//etc/protocol/ an absolute path and, with one fewer /, sftp://example.com/etc/protocol/ a relative one but draft-hoffman-ftp-uri-04.txt suggests that such an approach has failed with ftp: since clients put in a / regardless. (The ftp: scheme is not that close a parallel since it does impose a syntax on path, parsing it with / and expecting each element to be sent in a separate CWD command, which secsh-filexfer does not). tftp [RFC3617] opts out of this problem specifying tftp://host /file interpret file how you like smb: [draft-crhertel-smb-url-10.txt] requires the path to be ie starting with / but not // http:, at least as defined in RFC2616, uses , which always starts with a / I suggested putting in a tilde or some such for paths relative to a user directory but it is only a half-hearted suggestion because I anticipate clients doing something comparable to their behaviour with ftp:, failing to remove the tilde when they should or doing the opposite and inserting it when they shoud not. We could insert something competely different, in effect saying path= whatever comes next, ie sftp://example.com/path=/etc/protocol/ replacing path= with a character sequence tbd. If only secsh-filexfer specified a tighter syntax - but it doesn't, so I see no good solution. Tom Petch ----- Original Message ----- From: "Tom Petch" To: "Salowey, Joe" ; Sent: Tuesday, January 10, 2006 8:54 PM Subject: Re: SFTP was Re: presence of authority was Re: SFTP URI issues > My sense is that the Generic URI syntax has been retrofitted to a variety of > pre-existing paths and so looks a bit like Topsy, and would have looked > different had it come first:-) > > I like RFC1738 as a (obsolescent) collection of schemes and syntax and, which I > had forgotten, does include, for ftp, %2F, differentiating > //etc as generating CWD > /%2Fetc as generating CWD /etc > /etc as generating CWD etc > It says, and RFC3986 does not, that the first slash is not part of the path but > a separator, with another character for home directory > > draft-hoffman-ftp-uri-04.txt, which is/was intended to supersede that piece, > says that most implementations put in a / anyway in conflict with RFC1738. That > I-D did run into some difficulties which may be why I cannot see it as an RFC. > (There was an e-mail from Paul Hoffman to the URI list that he was abandoning > work on the file: scheme because consensus was impossible but I never saw such a > statement for ftp:) > > In between came RFC2396 which warns us that / delimits parts of the hierarchy > and is not to be confused with the identical / which is used as part of a path. > IMHO, it is a mess because / was chosen as a URI delimiter when it already was > in use in file paths. > > Still, RFC3986 is what matters and that allows us // at the start of a path (or > /// for that matter) to interpret as we will. I think // for an absolute path > is fine. > > I had always seen tilde ~ as the indicator of user directory. It is an > unreserved character in most URI (tel being the exception) which is probably why > I cannot see its use being defined in any other URI. Would it do, ie // for > absolute /~ for relative and / being invalid? or does this run > into the same problem namely that the tilde may or may not already be there as > part of the path the end user wishes to provide via the URI to client and thence > to server? > > Tom Petch > > ----- Original Message ----- > From: "Salowey, Joe" > To: "Tom Petch" ; > Sent: Tuesday, January 10, 2006 6:34 PM > Subject: RE: SFTP was Re: presence of authority was Re: SFTP URI issues > > > > > > a) The Generic Syntax for URI [RFC3986] says > > "If a URI contains an authority component, then the path component > > must either be empty or begin with a slash ("/") character. " > > which is what achieves. The I-D goes on to say that > > if a path starts with a / then it is relative to the root of > > the file system, > > otherwise it is relative to the user's home or default > > directory. But the > > Generic Syntax requires the path to start with a / or be > > empty, so you can never > > have a path relative to the user's home directory except for > > an empty one:-) > > > > b) In this section, the I-D says that / is a reserved > > character - I agree - and > > that it must be encoded - disagree. In URI, reserved is not > > used in the way I > > would like to see it used - it means that sometimes the > > character must be > > encoded, other times not:-{ > > " If data for a URI component would conflict with a reserved > > character's purpose as a delimiter, then the conflicting > > data must be > > percent-encoded before the URI is formed." > > The initial / of is a delimiter between > > authority and path and so > > must be just that, / not %2F. > > So are you allowing > > sftp://example.com/%2Fetc/protocols > > for absolute paths as opposed to > > sftp://example.com/mylocalfile.txt > > for relative ones? > > > > [Joe] Yes, that was the intent of the draft. However this doesn't seem > to be the best way to handle this. I think most people would rather not > have to enter in %2F into a URL to specify an absolute path. Using "//" > to represent the absolute path is better and you confirm that it would > work fine. > > Is this behavior consistent with other URLs? In RFC3986 these are > referred to as absolute paths so perhaps it would be better to have > paths default to root and define a special delimiter to indicate home > directory at the beginning of the path. This would seem to make it more > likely that an HTTP URL path would also work as an SFTP URL path, but > perhaps the two cases are too different for this actually to work. > > > I am unclear. > > > > (The end of will be signalled by the end of > > the URI or the > > characters ? or # and so / is not a delimiter for that > > purpose and can appear as > > such as many times as it likes unencoded within such a path). > > > > Tom Petch > > > > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 13 12:17:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSXw-00027X-Ug for secsh-archive@megatron.ietf.org; Fri, 13 Jan 2006 12:17:05 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23039 for ; Fri, 13 Jan 2006 12:15:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5F10463B14F; Fri, 13 Jan 2006 17:17:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sphinx.chicagopeoplez.org (sphinx.chicagopeoplez.org [67.18.129.178]) by mail.netbsd.org (Postfix) with ESMTP id C329063B19E for ; Fri, 13 Jan 2006 17:16:59 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by sphinx.chicagopeoplez.org (Postfix) with ESMTP id B0763C007 for ; Fri, 13 Jan 2006 10:44:41 -0600 (CST) Received: from sphinx.chicagopeoplez.org ([127.0.0.1]) by localhost (sphinx.chicagopeoplez.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03771-01 for ; Fri, 13 Jan 2006 10:44:41 -0600 (CST) Received: by sphinx.chicagopeoplez.org (Postfix, from userid 506) id 80024C006; Fri, 13 Jan 2006 10:44:41 -0600 (CST) Date: Fri, 13 Jan 2006 10:44:41 -0600 From: David Terrell To: ietf-ssh@NetBSD.org Subject: Re: SFTP was Re: presence of authority was Re: SFTP URI issues Message-ID: <20060113164441.GK4822@sphinx.chicagopeoplez.org> Reply-To: David Terrell References: <024e01c61841$ae08f000$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024e01c61841$ae08f000$0601a8c0@pc6> User-Agent: Mutt/1.4.1i X-Virus-Scanned: amavisd-new at sphinx.chicagopeoplez.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list > If only secsh-filexfer specified a tighter syntax - but it doesn't, so I see no > good solution. Does sftp://host/./relative/path work as a magic path? I guess most url normalization code will drop that "./".... From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 11:26:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytfZ-0007m4-VE for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 11:26:54 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28390 for ; Tue, 17 Jan 2006 11:25:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2D4A663B2C6; Tue, 17 Jan 2006 16:26:46 +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 E0DA963B2C3 for ; Tue, 17 Jan 2006 16:26:43 +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 8383860; Tue, 17 Jan 2006 09:26:42 -0700 Message-ID: <43CD1ADB.4010204@vandyke.com> Date: Tue, 17 Jan 2006 09:27:07 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Please publish the attached draft-galb-filexfer-extensions-00.txt Content-Type: multipart/mixed; boundary="------------010201090309010502090003" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------010201090309010502090003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Joseph --------------010201090309010502090003 Content-Type: text/plain; name="draft-galb-secsh-filexfer-extensions-00.txt" Content-Disposition: inline; filename="draft-galb-secsh-filexfer-extensions-00.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: July 21, 2006 O. Saarenmaa F-Secure January 17, 2006 SSH File Transfer Protocol draft-galb-secsh-filexfer-extensions-00.txt 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 July 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SSH File Transfer Protocol provides a rich infrastructure for sharing information about files. This document describes several optional extensions that build on this infrastructure. Galbraith & Saarenmaa Expires July 21, 2006 [Page 1] Internet-Draft SSH File Transfer Protocol January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Vendor Id . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. File Hashing . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Querying Available Space . . . . . . . . . . . . . . . . . . . 6 5. Querying User Home Directory . . . . . . . . . . . . . . . . . 7 6. Copying Remote Files . . . . . . . . . . . . . . . . . . . . . 7 7. Temporary files & directories . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Galbraith & Saarenmaa Expires July 21, 2006 [Page 2] Internet-Draft SSH File Transfer Protocol January 2006 1. Introduction This is a collection of optional extensions to the SSH File Transfer Protocol [I-D.ietf-secsh-filexfer]. This extensions make it possible for clients to query the server for additional information which may not be widely supported, but can increase the quality of the users experience when the server can support them. 2. Vendor Id It is often necessary to detect the version of the server so that bugs can be worked around. This extension allows the client to do so. string "vendor-id" string vendor-structure string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number vendor-name Arbitrary name identifying the maker of the product. product-name Arbitrary name identifying the product. product-name Arbitrary string identifying the version of the product. product-build-number A build-number for the product, such that if a bug is fixed in build-number 'x', it can be assumed that (barring regression in the product) it is fixed in all build-numbers > 'x'. This extension may also be sent by the client as a SSH_FXP_EXTENDED packet; in this case the contents of the vendor-structure become the extension-specific data: byte SSH_FXP_EXTENDED uint32 request-id string "vendor-id" string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number Galbraith & Saarenmaa Expires July 21, 2006 [Page 3] Internet-Draft SSH File Transfer Protocol January 2006 The server responds to this request with a SSH_FXP_STATUS message. The status SHOULD be SSH_FX_OK. 3. File Hashing This extension allows a client to easily check if a file (or portion thereof) that it already has matches what is on the server. byte SSH_FXP_EXTENDED uint32 request-id string "check-file-handle" / "check-file-name" string handle / name string hash-algorithm-list uint64 start-offset uint64 length uint32 block-size handle For "check-file-handle", 'handle' is an open file handle returned by SSH_FXP_OPEN. If 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST return SSH_FX_INVALID_HANDLE. If ACE4_READ_DATA was not included when the file was opened, the server MUST return STATUS_PERMISSION_DENIED. If this file handle was opened in SSH_FXF_ACCESS_TEXT_MODE mode, the check must be performed on the data as it would be sent on the wire. name For "check-file-name", 'name' is the path to the file to check. If 'check-file-name' is a directory, SSH_FX_FILE_IS_A_DIRECTORY SHOULD be returned. If 'check-file-name' refers to a SSH_FILEXFER_TYPE_SYMLINK, the target should be opened. The results are undefined file types other than SSH_FILEXFER_TYPE_REGULAR. The file MUST be opened without the SSH_FXF_ACCESS_TEXT_MODE access flag (in binary mode.) hash-algorithm-list A comma separated list of hash algorithms the client is willing to accept for this operation. The server MUST pick the first hash on the list that it supports. Galbraith & Saarenmaa Expires July 21, 2006 [Page 4] Internet-Draft SSH File Transfer Protocol January 2006 Currently defined algorithms are "md5", "sha1", "sha224", "sha256", "sha384", "sha512", and "crc32". Additional algorithms may be added by following the DNS extensibility naming convention outlined in [RFC4251]. MD5 is described in [RFC1321]. SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 are described in [FIPS-180-2]. [ISO.3309.1991] describes crc32, and is the same algorithm used in [RFC1510] start-offset The starting offset of the data to include in the hash. length The length of data to include in the hash. If length is zero, all the data from start-offset to the end-of-file should be included. block-size An independent hash MUST be computed over every block in the file. The size of blocks is specified by block-size. The block-size MUST NOT be smaller than 256 bytes. If the block-size is 0, then only one hash, over the entire range, MUST be made. The response is either a SSH_FXP_STATUS packet, indicating an error, or the following extended reply packet: This extension MUST be represented in the "supported2" extension as "check-file" and both version MUST either be support or neither. byte SSH_FXP_EXTENDED_REPLY uint32 request-id string hash-algo-used byte hash[n][block-count] hash-algo-used The hash algorithm that was actually used. hash The computed hashes. The hash algorithm used determines the size of n. The number of block-size chunks of data in the file determines block-count. The hashes are placed in the packet one after another, with no decoration. Note that if the length of the range is not an even multiple of block-size, the last hash will have been computed over only the remainder of the range instead of a full block. Galbraith & Saarenmaa Expires July 21, 2006 [Page 5] Internet-Draft SSH File Transfer Protocol January 2006 4. Querying Available Space The following extension provides a way to discover the available space for an arbitrary path. byte SSH_FXP_EXTENDED uint32 request-id string "space-available" string path [UTF-8] path 'path' for which the available space should be reported. This 'path' is not required to be the mount point path, but MAY be a directory or file contained within the mount. The reply to the request is as follows: byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint64 bytes-on-device uint64 unused-bytes-on-device uint64 bytes-available-to-user uint64 unused-bytes-available-to-user uint32 bytes-per-allocation-unit bytes-on-device The total number of bytes on the device which stores 'path', both used and unused, or 0 if unknown. unused-bytes-on-device The total number of unused bytes available on the device which stores 'path', or 0 if unknown. bytes-available-to-user The total number of bytes, both used and unused, available to the authenticated user on the device which stores 'path', or 0 if unknown. unused-bytes-available-to-user The total number of unused bytes available to the authenticated user on the device which stores 'path', or 0 if unknown. bytes-per-allocation-unit The number of bytes in each allocation unit on the device, or in other words, the minimum number of bytes that a file allocation size can grow or shrink by. If the server does not know this information, or the file-system in use does not use allocation blocks, this value MUST be 0. Galbraith & Saarenmaa Expires July 21, 2006 [Page 6] Internet-Draft SSH File Transfer Protocol January 2006 5. Querying User Home Directory Many users are used to being able to type '~' as an alias for their home directory, or ~username as an alias for another user's home directory. To support this feature, a server MAY support following extension. byte SSH_FXP_EXTENDED uint32 request-id string "home-directory" string username [UTF-8] username Username whose home directory path is being requested. An empty string implies the current user. The reply to the request is either a SSH_FXP_STATUS packet or a SSH_FXP_NAME packet containing the absolute real-path of the home directory. 6. Copying Remote Files byte SSH_FXP_EXTENDED uint32 request-id string "copy-file" string source-file string destination-file bool overwrite-destination Copy a file from one location to another on the server. The server responds with SSH_FXP_STATUS. byte SSH_FXP_EXTENDED uint32 request-id string "copy-data" string read-from-handle uint64 read-from-offset string write-to-handle uint64 write-to-offset uint64 data-length Copy data from one handle to another on the server. The server responds with SSH_FXP_STATUS. 7. Temporary files & directories Galbraith & Saarenmaa Expires July 21, 2006 [Page 7] Internet-Draft SSH File Transfer Protocol January 2006 byte SSH_FXP_EXTENDED uint32 request-id string "get-temp-folder" Retrieves the users prefered location for temporary files and folders. The server responds with SSH_FXP_STATUS or SSH_FXP_NAME containing the realpath of the prefereed location. byte SSH_FXP_EXTENDED uint32 request-id string "make-temp-folder" Requests that the server create a folder in the users preferred location for temporary files and folders for use by the client. The server responds with SSH_FXP_STATUS or SSH_FXP_NAME containing the realpat of the new folder. It is the clients responsibility to cleanup and remove the folder when it is done with it. However, the server MAY remove the folder and it's contents when the client closes the connection. 8. Security Considerations The home directory extension could be used to discover whether a given user is valid; however, since users are assumed to be authenticated by the underlying protocol, this is probably not significant in most situations. If a server would not normally allow an authenticated user to query the existance of another user, the server MUST NOT allow the "home-directory" extension. 9. References 9.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [I-D.ietf-secsh-filexfer] Galbraith, J. and O. Saarenmaa, "SSH File Transfer Protocol", draft-ietf-secsh-filexfer-10 (work in Galbraith & Saarenmaa Expires July 21, 2006 [Page 8] Internet-Draft SSH File Transfer Protocol January 2006 progress), October 2005. [FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002. [ISO.3309.1991] International Organization for Standardization, "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", ISO Standard 3309, June 1991. 9.2. Informative References Trademark notice "ssh" is a registered trademark in the United States and/or other countries. Galbraith & Saarenmaa Expires July 21, 2006 [Page 9] Internet-Draft SSH File Transfer Protocol January 2006 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 Oskari Saarenmaa F-Secure Tammasaarenkatu 7 Helsinki 00180 FI Email: oskari.saarenmaa@f-secure.com Galbraith & Saarenmaa Expires July 21, 2006 [Page 10] Internet-Draft SSH File Transfer Protocol January 2006 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 (2006). 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 & Saarenmaa Expires July 21, 2006 [Page 11] --------------010201090309010502090003-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 11:37:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eytq6-0001OK-4B for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 11:37:46 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29114 for ; Tue, 17 Jan 2006 11:36:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5EB7E63B2D5; Tue, 17 Jan 2006 16:37:42 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id AA53663B2D1 for ; Tue, 17 Jan 2006 16:37:41 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Please publish the attached draft-galb-filexfer-extensions-00.txt Date: Tue, 17 Jan 2006 11:37:42 -0500 Message-ID: <3EF96AF20489A34296050FBD5C36ECB93BCCE8@beacon.PSC.process.com> Thread-Topic: Please publish the attached draft-galb-filexfer-extensions-00.txt Thread-Index: AcYbgtpXn2u+shZUQO6MavvpF8l+HgAAO5rw From: "Richard Whalen" To: "Joseph Galbraith" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Are there any restrictions on "copy-data"? How are the offsets treated = when the file is opened for text transfers? In section 7 (Temporary files & directories) You use "prefered" and "preferreed" that I believe should be "preferred" From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 11:56:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyu8g-0006Jr-PG for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 11:56:58 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00189 for ; Tue, 17 Jan 2006 11:55:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 73F7863B2E0; Tue, 17 Jan 2006 16:56:53 +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 F301063B2DD for ; Tue, 17 Jan 2006 16:56:51 +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 8383985; Tue, 17 Jan 2006 09:56:51 -0700 Message-ID: <43CD21EC.30301@vandyke.com> Date: Tue, 17 Jan 2006 09:57:16 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Richard Whalen CC: ietf-ssh@NetBSD.org Subject: Re: Please publish the attached draft-galb-filexfer-extensions-00.txt References: <3EF96AF20489A34296050FBD5C36ECB93BCCE8@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB93BCCE8@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > Are there any restrictions on "copy-data"? How are the offsets treated when the file is opened for text transfers? Excellent questions... I feel a new draft coming on. I believe the answer is that "copy-data" has no restrictions, other than that the the user not exceed quota (of course.) Of course if it is a huge operation, the server is permitted to complete it out of order or out right refuse to do it. Clarified in local sources. I believe, since this is a local-to-local copy operation, we should forbid the files to be opened for text transfer-- of course, with VMS having multiple different file local file formats, perhaps you'd prefer something different? What do you think it should do? > In section 7 (Temporary files & directories) > You use "prefered" and "preferreed" that I believe should be "preferred" Ahh.. I see that my creative speller was at full throttle. Fixed in local source. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 12:20:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuVI-0005Tv-Cp for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 12:20:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02133 for ; Tue, 17 Jan 2006 12:18:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D41F363B20C; Tue, 17 Jan 2006 17:20:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id 0209D63B19D for ; Tue, 17 Jan 2006 17:20:15 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Please publish the attached draft-galb-filexfer-extensions-00.txt Date: Tue, 17 Jan 2006 12:20:17 -0500 Message-ID: <3EF96AF20489A34296050FBD5C36ECB93BCCE9@beacon.PSC.process.com> Thread-Topic: Please publish the attached draft-galb-filexfer-extensions-00.txt Thread-Index: AcYbhwn7s9g2I4zNRKi4Bg284M4BNQAAH4zg From: "Richard Whalen" To: "Joseph Galbraith" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I think that "copy-data" should either be forbidden for text files, or = as follows: Both files must be opened for text transfer. The "write-to-offset" is = ignored, and the transfer starts at the server's current write position. = The "read-from-offset" and "data-length" parameters are ignored. This avoids problems with differences in the way the file may be stored = and problems with the (write?) data length being less than the = difference between the write-to-offset and the current allocation o the = file being written to. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Tuesday, January 17, 2006 11:57 AM To: Richard Whalen Cc: ietf-ssh@netbsd.org Subject: Re: Please publish the attached draft-galb-filexfer-extensions-00.txt Richard Whalen wrote: > Are there any restrictions on "copy-data"? How are the offsets = treated when the file is opened for text transfers? Excellent questions... I feel a new draft coming on. I believe the answer is that "copy-data" has no restrictions, other than that the the user not exceed quota (of course.) Of course if it is a huge operation, the server is permitted to complete it out of order or out right refuse to do it. Clarified in local sources. I believe, since this is a local-to-local copy operation, we should forbid the files to be opened for text transfer-- of course, with VMS having multiple different file local file formats, perhaps you'd prefer something different? What do you think it should do? > In section 7 (Temporary files & directories) > You use "prefered" and "preferreed" that I believe should be = "preferred" Ahh.. I see that my creative speller was at full throttle. Fixed in local source. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 12:45:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyutT-0004i3-3T for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 12:45:19 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04141 for ; Tue, 17 Jan 2006 12:43:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6206063B2E8; Tue, 17 Jan 2006 17:45:08 +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 98EB263B24A for ; Tue, 17 Jan 2006 17:45:07 +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 8384203; Tue, 17 Jan 2006 10:45:06 -0700 Message-ID: <43CD2D3B.6080102@vandyke.com> Date: Tue, 17 Jan 2006 10:45:31 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Richard Whalen CC: ietf-ssh@NetBSD.org Subject: Re: Please publish the attached draft-galb-filexfer-extensions-00.txt References: <3EF96AF20489A34296050FBD5C36ECB93BCCE9@beacon.PSC.process.com> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB93BCCE9@beacon.PSC.process.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > I think that "copy-data" should either be forbidden for text files, or as follows: > > Both files must be opened for text transfer. The "write-to-offset" is ignored, and the transfer starts at the server's current write position. The "read-from-offset" and "data-length" parameters are ignored. If the "data-length" parameter is ignore, how much data is copied? Until EOF is reached? Unless someone really needs this to work usefully in text mode, I'm strongly tempted to let it pass-- > This avoids problems with differences in the way the file may be stored and problems with the (write?) data length being less than the difference between the write-to-offset and the current allocation o the file being written to. Thanks, Joseph > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, January 17, 2006 11:57 AM > To: Richard Whalen > Cc: ietf-ssh@netbsd.org > Subject: Re: Please publish the attached > draft-galb-filexfer-extensions-00.txt > > > Richard Whalen wrote: >> Are there any restrictions on "copy-data"? How are the offsets treated when the file is opened for text transfers? > > Excellent questions... I feel a new draft coming on. > > I believe the answer is that "copy-data" has no restrictions, > other than that the the user not exceed quota (of course.) > > Of course if it is a huge operation, the server is permitted > to complete it out of order or out right refuse to do it. > > Clarified in local sources. > > I believe, since this is a local-to-local copy operation, > we should forbid the files to be opened for text transfer-- > of course, with VMS having multiple different file local > file formats, perhaps you'd prefer something different? > What do you think it should do? > >> In section 7 (Temporary files & directories) >> You use "prefered" and "preferreed" that I believe should be "preferred" > > Ahh.. I see that my creative speller was at full throttle. > Fixed in local source. > > Thanks, > > Joseph > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 13:23:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvUA-0005J4-GQ for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 13:23:14 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06611 for ; Tue, 17 Jan 2006 13:21:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7F10463B2F1; Tue, 17 Jan 2006 18:23:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id 89AEE63B2DF for ; Tue, 17 Jan 2006 18:23:08 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Please publish the attached draft-galb-filexfer-extensions-00.txt Date: Tue, 17 Jan 2006 13:23:10 -0500 Message-ID: <3EF96AF20489A34296050FBD5C36ECB93BCCEA@beacon.PSC.process.com> Thread-Topic: Please publish the attached draft-galb-filexfer-extensions-00.txt Thread-Index: AcYbjcRqOOI65suHQjC2Ln27243YYAABO9Ag From: "Richard Whalen" To: "Joseph Galbraith" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Yes, the data would be copied until EOF on the read handle. Whether or not the files are opened for text transfer a well written = server should check for the potentially bad case of the read file and = the write file being the same. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Tuesday, January 17, 2006 12:46 PM To: Richard Whalen Cc: ietf-ssh@netbsd.org Subject: Re: Please publish the attached draft-galb-filexfer-extensions-00.txt Richard Whalen wrote: > I think that "copy-data" should either be forbidden for text files, or as follows: >=20 > Both files must be opened for text transfer. The "write-to-offset" is ignored, and the transfer starts at the server's current write position. The "read-from-offset" and "data-length" parameters are ignored. If the "data-length" parameter is ignore, how much data is copied? Until EOF is reached? Unless someone really needs this to work usefully in text mode, I'm strongly tempted to let it pass-- > This avoids problems with differences in the way the file may be stored and problems with the (write?) data length being less than the difference between the write-to-offset and the current allocation o the file being written to. Thanks, Joseph > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, January 17, 2006 11:57 AM > To: Richard Whalen > Cc: ietf-ssh@netbsd.org > Subject: Re: Please publish the attached > draft-galb-filexfer-extensions-00.txt >=20 >=20 > Richard Whalen wrote: >> Are there any restrictions on "copy-data"? How are the offsets = treated when the file is opened for text transfers? >=20 > Excellent questions... I feel a new draft coming on. >=20 > I believe the answer is that "copy-data" has no restrictions, > other than that the the user not exceed quota (of course.) >=20 > Of course if it is a huge operation, the server is permitted > to complete it out of order or out right refuse to do it. >=20 > Clarified in local sources. >=20 > I believe, since this is a local-to-local copy operation, > we should forbid the files to be opened for text transfer-- > of course, with VMS having multiple different file local > file formats, perhaps you'd prefer something different? > What do you think it should do? >=20 >> In section 7 (Temporary files & directories) >> You use "prefered" and "preferreed" that I believe should be = "preferred" >=20 > Ahh.. I see that my creative speller was at full throttle. > Fixed in local source. >=20 > Thanks, >=20 > Joseph >=20 >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 20:17:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez1we-0006yE-CX for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 20:17:04 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18900 for ; Tue, 17 Jan 2006 20:15:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 298C263B321; Wed, 18 Jan 2006 01:17:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from leander.cnchost.com (leander.cnchost.com [207.155.252.112]) by mail.netbsd.org (Postfix) with ESMTP id 8E7BE63B101 for ; Wed, 18 Jan 2006 01:16:59 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by leander.cnchost.com id TAA24376; Tue, 17 Jan 2006 19:19:40 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith , Richard Whalen CC: X-Mailer: Barca 2.0 (3350) - EVALUATION VERSION X-URL: http://www.pocosystems.com/ Date: Wed, 18 Jan 2006 01:19:39 +0100 Message-ID: <200611811939.051375@nucleus> In-Reply-To: <200611811632.544542@nucleus> Subject: Re: copy-data Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Copying to end-of-file with a single request should be permitted, though. No= need to force many packets for the copying process. On Wed, 18 Jan 2006 01:16:32 +0100, denis bider wrote: >>> Are there any restrictions on "copy-data"? How are the offsets >>> >>> treated when the file is opened for text transfers? >>> >> I believe, since this is a local-to-local copy operation, >> we should forbid the files to be opened for text transfer-- >> > No... it's simpler than that. > > The copy-data request is a shortcut for read followed by write, > just without the data transmission. The server should internally do > the same thing that would happen if one did a "read" from the > source, followed by a "write" of the same data that "read" would > transmit on the wire. No need to prohibit or dictate anything with > regard to how the two file handles were opened. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 17 21:18:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez2th-0004nj-KW for secsh-archive@megatron.ietf.org; Tue, 17 Jan 2006 21:18:06 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22967 for ; Tue, 17 Jan 2006 21:16:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BAB6763B11B; Wed, 18 Jan 2006 02:17:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by mail.netbsd.org (Postfix) with ESMTP id 01B1E63B101 for ; Wed, 18 Jan 2006 02:17:58 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by repulse.cnchost.com id TAA08671; Tue, 17 Jan 2006 19:16:33 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith , Richard Whalen CC: X-Mailer: Barca 2.0 (3350) - EVALUATION VERSION X-URL: http://www.pocosystems.com/ Date: Wed, 18 Jan 2006 01:16:32 +0100 Message-ID: <200611811632.544542@nucleus> In-Reply-To: <43CD21EC.30301@vandyke.com> Subject: copy-data Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >> Are there any restrictions on "copy-data"? How are the offsets >> treated when the file is opened for text transfers? > > I believe, since this is a local-to-local copy operation, > we should forbid the files to be opened for text transfer-- No... it's simpler than that. The copy-data request is a shortcut for read followed by write, just without= the data transmission. The server should internally do the same thing that= would happen if one did a "read" from the source, followed by a "write" of= the same data that "read" would transmit on the wire. No need to prohibit= or dictate anything with regard to how the two file handles were opened. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 18 10:18:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzF4w-0007v9-Pf for secsh-archive@megatron.ietf.org; Wed, 18 Jan 2006 10:18:32 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23132 for ; Wed, 18 Jan 2006 10:17:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E15363B34E; Wed, 18 Jan 2006 15:18:25 +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 A108F63B153 for ; Wed, 18 Jan 2006 15:18:22 +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 8387277; Wed, 18 Jan 2006 08:18:21 -0700 Message-ID: <43CE5C58.1080901@vandyke.com> Date: Wed, 18 Jan 2006 08:18:48 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Please publish the attached draft-ietf-secsh-filexfer-extensions-00.txt Content-Type: multipart/mixed; boundary="------------080704000606080003090906" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------080704000606080003090906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Joseph --------------080704000606080003090906 Content-Type: text/plain; name="draft-ietf-secsh-filexfer-extensions.txt" Content-Disposition: inline; filename="draft-ietf-secsh-filexfer-extensions.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: July 22, 2006 O. Saarenmaa F-Secure January 18, 2006 SSH File Transfer Protocol draft-ietf-secsh-filexfer-extensions-00.txt 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 July 22, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SSH File Transfer Protocol provides a rich infrastructure for sharing information about files. This document describes several optional extensions that build on this infrastructure. Galbraith & Saarenmaa Expires July 22, 2006 [Page 1] Internet-Draft SSH File Transfer Protocol January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Vendor Id . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. File Hashing . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Querying Available Space . . . . . . . . . . . . . . . . . . . 6 5. Querying User Home Directory . . . . . . . . . . . . . . . . . 7 6. Copying Remote Files . . . . . . . . . . . . . . . . . . . . . 7 7. Copying remote data . . . . . . . . . . . . . . . . . . . . . 7 8. Temporary files & directories . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Galbraith & Saarenmaa Expires July 22, 2006 [Page 2] Internet-Draft SSH File Transfer Protocol January 2006 1. Introduction This is a collection of optional extensions to the SSH File Transfer Protocol [I-D.ietf-secsh-filexfer]. This extensions make it possible for clients to query the server for additional information which may not be widely supported, but can increase the quality of the users experience when the server can support them. 2. Vendor Id It is often necessary to detect the version of the server so that bugs can be worked around. This extension allows the client to do so. string "vendor-id" string vendor-structure string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number vendor-name Arbitrary name identifying the maker of the product. product-name Arbitrary name identifying the product. product-name Arbitrary string identifying the version of the product. product-build-number A build-number for the product, such that if a bug is fixed in build-number 'x', it can be assumed that (barring regression in the product) it is fixed in all build-numbers > 'x'. This extension may also be sent by the client as a SSH_FXP_EXTENDED packet; in this case the contents of the vendor-structure become the extension-specific data: byte SSH_FXP_EXTENDED uint32 request-id string "vendor-id" string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number Galbraith & Saarenmaa Expires July 22, 2006 [Page 3] Internet-Draft SSH File Transfer Protocol January 2006 The server responds to this request with a SSH_FXP_STATUS message. The status SHOULD be SSH_FX_OK. 3. File Hashing This extension allows a client to easily check if a file (or portion thereof) that it already has matches what is on the server. byte SSH_FXP_EXTENDED uint32 request-id string "check-file-handle" / "check-file-name" string handle / name string hash-algorithm-list uint64 start-offset uint64 length uint32 block-size handle For "check-file-handle", 'handle' is an open file handle returned by SSH_FXP_OPEN. If 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST return SSH_FX_INVALID_HANDLE. If ACE4_READ_DATA was not included when the file was opened, the server MUST return STATUS_PERMISSION_DENIED. If this file handle was opened in SSH_FXF_ACCESS_TEXT_MODE mode, the check must be performed on the data as it would be sent on the wire. name For "check-file-name", 'name' is the path to the file to check. If 'check-file-name' is a directory, SSH_FX_FILE_IS_A_DIRECTORY SHOULD be returned. If 'check-file-name' refers to a SSH_FILEXFER_TYPE_SYMLINK, the target should be opened. The results are undefined file types other than SSH_FILEXFER_TYPE_REGULAR. The file MUST be opened without the SSH_FXF_ACCESS_TEXT_MODE access flag (in binary mode.) hash-algorithm-list A comma separated list of hash algorithms the client is willing to accept for this operation. The server MUST pick the first hash on the list that it supports. Galbraith & Saarenmaa Expires July 22, 2006 [Page 4] Internet-Draft SSH File Transfer Protocol January 2006 Currently defined algorithms are "md5", "sha1", "sha224", "sha256", "sha384", "sha512", and "crc32". Additional algorithms may be added by following the DNS extensibility naming convention outlined in [RFC4251]. MD5 is described in [RFC1321]. SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 are described in [FIPS-180-2]. [ISO.3309.1991] describes crc32, and is the same algorithm used in [RFC1510] start-offset The starting offset of the data to include in the hash. length The length of data to include in the hash. If length is zero, all the data from start-offset to the end-of-file should be included. block-size An independent hash MUST be computed over every block in the file. The size of blocks is specified by block-size. The block-size MUST NOT be smaller than 256 bytes. If the block-size is 0, then only one hash, over the entire range, MUST be made. The response is either a SSH_FXP_STATUS packet, indicating an error, or the following extended reply packet: This extension MUST be represented in the "supported2" extension as "check-file" and both version MUST either be support or neither. byte SSH_FXP_EXTENDED_REPLY uint32 request-id string hash-algo-used byte hash[n][block-count] hash-algo-used The hash algorithm that was actually used. hash The computed hashes. The hash algorithm used determines the size of n. The number of block-size chunks of data in the file determines block-count. The hashes are placed in the packet one after another, with no decoration. Note that if the length of the range is not an even multiple of block-size, the last hash will have been computed over only the remainder of the range instead of a full block. Galbraith & Saarenmaa Expires July 22, 2006 [Page 5] Internet-Draft SSH File Transfer Protocol January 2006 4. Querying Available Space The following extension provides a way to discover the available space for an arbitrary path. byte SSH_FXP_EXTENDED uint32 request-id string "space-available" string path [UTF-8] path 'path' for which the available space should be reported. This 'path' is not required to be the mount point path, but MAY be a directory or file contained within the mount. The reply to the request is as follows: byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint64 bytes-on-device uint64 unused-bytes-on-device uint64 bytes-available-to-user uint64 unused-bytes-available-to-user uint32 bytes-per-allocation-unit bytes-on-device The total number of bytes on the device which stores 'path', both used and unused, or 0 if unknown. unused-bytes-on-device The total number of unused bytes available on the device which stores 'path', or 0 if unknown. bytes-available-to-user The total number of bytes, both used and unused, available to the authenticated user on the device which stores 'path', or 0 if unknown. unused-bytes-available-to-user The total number of unused bytes available to the authenticated user on the device which stores 'path', or 0 if unknown. bytes-per-allocation-unit The number of bytes in each allocation unit on the device, or in other words, the minimum number of bytes that a file allocation size can grow or shrink by. If the server does not know this information, or the file-system in use does not use allocation blocks, this value MUST be 0. Galbraith & Saarenmaa Expires July 22, 2006 [Page 6] Internet-Draft SSH File Transfer Protocol January 2006 5. Querying User Home Directory Many users are used to being able to type '~' as an alias for their home directory, or ~username as an alias for another user's home directory. To support this feature, a server MAY support following extension. byte SSH_FXP_EXTENDED uint32 request-id string "home-directory" string username [UTF-8] username Username whose home directory path is being requested. An empty string implies the current user. The reply to the request is either a SSH_FXP_STATUS packet or a SSH_FXP_NAME packet containing the absolute real-path of the home directory. 6. Copying Remote Files byte SSH_FXP_EXTENDED uint32 request-id string "copy-file" string source-file string destination-file bool overwrite-destination This request copies a file from one location to another on the server. The server responds with SSH_FXP_STATUS. 7. Copying remote data byte SSH_FXP_EXTENDED uint32 request-id string "copy-data" string read-from-handle uint64 read-from-offset uint64 read-data-length string write-to-handle uint64 write-to-offset Copy data from one handle to another on the server. The server responds with SSH_FXP_STATUS. Galbraith & Saarenmaa Expires July 22, 2006 [Page 7] Internet-Draft SSH File Transfer Protocol January 2006 The server MUST copy the data exactly as if the client had issued a series of SSH_FXP_READ requests on the read-from-handle starting at read-from-offset and totaling read-data-length bytes, and issued a series of SSH_FXP_WRITE packets on the write-to-handle, starting at the write-from-offset, and totaling the total number of bytes read by the SSH_FXP_READ packets. If one of the files is open using SSH_FXF_TEXT_MODE, then operation on that handle honors all of the SSH_FXF_TEXT_MODE behaviors. The server SHOULD allow 'read-from-handle' and 'write-to-handle' to be the same handle as long as the range of data is not overlapping. This allows data to efficiently be moved within a file. The server MUST fail the request with a SSH_FX_INVALID_PARAMETER if the range is overlapping and it doesn't correctly handle this case. The server is not required to detect overlapping ranges if read-from-handle and write-to-handle are different handles referring to the same file. If 'data-length' is 0, this imples data should be read until EOF is encountered. There are no protocol restictions on this operation; however, the server MUST ensure that the user does not exceed quota, etc. The server is, as always, free to complete this operation out of order if it is too large to complete immediately, or to refuse a request that is too large. 8. Temporary files & directories byte SSH_FXP_EXTENDED uint32 request-id string "get-temp-folder" Retrieves the users preferred location for temporary files and folders. The server responds with SSH_FXP_STATUS or SSH_FXP_NAME containing the realpath of the preferred location. byte SSH_FXP_EXTENDED uint32 request-id string "make-temp-folder" Requests that the server create a folder in the users preferred location for temporary files and folders for use by the client. The server responds with SSH_FXP_STATUS or SSH_FXP_NAME containing the realpath of the new folder. It is the clients responsibility to cleanup and remove the folder Galbraith & Saarenmaa Expires July 22, 2006 [Page 8] Internet-Draft SSH File Transfer Protocol January 2006 when it is done with it. However, the server MAY remove the folder and it's contents when the client closes the connection. 9. Security Considerations The home directory extension could be used to discover whether a given user is valid; however, since users are assumed to be authenticated by the underlying protocol, this is probably not significant in most situations. If a server would not normally allow an authenticated user to query the existance of another user, the server MUST NOT allow the "home-directory" extension. 10. References 10.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [I-D.ietf-secsh-filexfer] Galbraith, J. and O. Saarenmaa, "SSH File Transfer Protocol", draft-ietf-secsh-filexfer-10 (work in progress), October 2005. [FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002. [ISO.3309.1991] International Organization for Standardization, "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", ISO Standard 3309, June 1991. 10.2. Informative References Trademark notice Galbraith & Saarenmaa Expires July 22, 2006 [Page 9] Internet-Draft SSH File Transfer Protocol January 2006 "ssh" is a registered trademark in the United States and/or other countries. Galbraith & Saarenmaa Expires July 22, 2006 [Page 10] Internet-Draft SSH File Transfer Protocol January 2006 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 Oskari Saarenmaa F-Secure Tammasaarenkatu 7 Helsinki 00180 FI Email: oskari.saarenmaa@f-secure.com Galbraith & Saarenmaa Expires July 22, 2006 [Page 11] Internet-Draft SSH File Transfer Protocol January 2006 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 (2006). 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 & Saarenmaa Expires July 22, 2006 [Page 12] --------------080704000606080003090906-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 18 12:36:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHEg-00053G-04 for secsh-archive@megatron.ietf.org; Wed, 18 Jan 2006 12:36:42 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06800 for ; Wed, 18 Jan 2006 12:35:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A729A63B333; Wed, 18 Jan 2006 17:36:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from foretec.com (furball.foretec.com [132.151.15.110]) by mail.netbsd.org (Postfix) with ESMTP id DDA1063B2A2 for ; Wed, 18 Jan 2006 17:36:34 +0000 (UTC) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=furball.foretec.com) by foretec.com with esmtp (Exim 4.30) id 1EzGbn-0004A9-C6; Wed, 18 Jan 2006 11:56:31 -0500 Received: from 10.31.30.38 (SquirrelMail authenticated user ids) by furball.foretec.com with HTTP; Wed, 18 Jan 2006 11:56:31 -0500 (EST) Message-ID: <1857.10.31.30.38.1137603391.squirrel@furball.foretec.com> In-Reply-To: <43CD1ADB.4010204@vandyke.com> References: <43CD1ADB.4010204@vandyke.com> Date: Wed, 18 Jan 2006 11:56:31 -0500 (EST) Subject: Re: Please publish the attached draft-galb-filexfer-extensions-00.txt From: internet-drafts@ietf.org To: "Joseph Galbraith" Cc: ietf-ssh@NetBSD.org Reply-To: internet-drafts@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit 7. Naming and Submitting Internet-Draft filenames have four parts, separated with hyphens and which may themselves contain hyphens: All Internet-Draft filenames begin with "draft" Document source: Individual The name of the submitter (one of the authors). This can be a surname, a given name, or an email address used by an author, as specified in the Authors' Addresses section of the draft. http://www.ietf.org/ietf/1id-guidelines.html. Please resubmit. Thank you. > Thanks, > > Joseph > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 18 12:39:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHHQ-0006kn-Sg for secsh-archive@megatron.ietf.org; Wed, 18 Jan 2006 12:39:33 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07328 for ; Wed, 18 Jan 2006 12:38:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A66EC63B2A2; Wed, 18 Jan 2006 17:39:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by mail.netbsd.org (Postfix) with ESMTP id E421363B123 for ; Wed, 18 Jan 2006 17:39:28 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by devonshire.cnchost.com id MAA24253; Wed, 18 Jan 2006 12:39:27 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: X-Mailer: Barca 2.0 (3350) - EVALUATION VERSION X-URL: http://www.pocosystems.com/ Date: Wed, 18 Jan 2006 18:39:26 +0100 Message-ID: <2006118183926.624832@nucleus> Subject: DH key exchange message numbers Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hi all, am I the only one who can't find KEXDH message numbers defined anywhere in= the now published SSH RFCs? Given that KEXDH is a required key exchange method, I'd expect those message= numbers to be defined in the Transport RFC. Yet, when I looked I couldn't= find the actual message numbers defined. Is this just my oversight or is it= everyone else's? :-) Best regards, denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 18 16:33:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKvZ-0004em-Kx for secsh-archive@megatron.ietf.org; Wed, 18 Jan 2006 16:33:13 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04768 for ; Wed, 18 Jan 2006 16:31:44 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A29DF63B193; Wed, 18 Jan 2006 21:33:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 972FF63B18E for ; Wed, 18 Jan 2006 21:33:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EzKFl-0007Ig-W7; Wed, 18 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-11.txt Message-Id: Date: Wed, 18 Jan 2006 15:50:01 -0500 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 : SSH File Transfer Protocol Author(s) : J. Galbraith, O. Saarenmaa Filename : draft-ietf-secsh-filexfer-11.txt Pages : 59 Date : 2006-1-18 The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-11.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-filexfer-11.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-filexfer-11.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: <2006-1-18123710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-18123710.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 18 17:41:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLzS-0000E2-W0 for secsh-archive@megatron.ietf.org; Wed, 18 Jan 2006 17:41:19 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17319 for ; Wed, 18 Jan 2006 17:39:51 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2988C63B190; Wed, 18 Jan 2006 22:41:14 +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 4FC9363B156 for ; Wed, 18 Jan 2006 22:41:12 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa20315; 18 Jan 2006 17:40 EST Date: Wed, 18 Jan 2006 17:40:34 -0500 From: Jeffrey Hutzelman To: denis bider , ietf-ssh@NetBSD.org Subject: Re: DH key exchange message numbers Message-ID: In-Reply-To: <2006118183926.624832@nucleus> References: <2006118183926.624832@nucleus> Originator-Info: login-token=Mulberry:01N+v416FTbUuDNnBYamkoRs5dLwK+H3GkYCY8bWs=; 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 Wednesday, January 18, 2006 06:39:26 PM +0100 denis bider wrote: > Hi all, > > am I the only one who can't find KEXDH message numbers defined anywhere > in the now published SSH RFCs? > > Given that KEXDH is a required key exchange method, I'd expect those > message numbers to be defined in the Transport RFC. Yet, when I looked I > couldn't find the actual message numbers defined. Is this just my > oversight or is it everyone else's? :-) Oops. Indeed, those numbers were removed during editing, as a result of what appears to have been some confusion. Someone commented during AUTH48 that they should be removed from assignednumbers (now RFC4250), because they were in the method-specific space and thus didn't need to be (and shouldn't be) in the message number registry. Unfortunately, they also got dropped from -transport, where the method is actually defined. As a result, these definitions are missing from the protocol suite entirely, which I expect makes it tricky to implement. :-) The correct numbers are these: > SSH_MSG_KEXDH_INIT 30 > SSH_MSG_KEXDH_REPLY 31 I think we need an RFC Errata on this one... :-( BTW, for those who've been looking for it and can't find it, the SSH paramaters registry is at http://www.iana.org/assignments/ssh-parameters. It seems the IANA hasn't yet published a link to that. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 20 11:42:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzLG-0004WU-Mx for secsh-archive@megatron.ietf.org; Fri, 20 Jan 2006 11:42:26 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28670 for ; Fri, 20 Jan 2006 11:40:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A36EF63B297; Fri, 20 Jan 2006 16:42:20 +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 156A763B10C for ; Fri, 20 Jan 2006 16:42:19 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 202AFE006A; Fri, 20 Jan 2006 11:42:19 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-publickeyfile is stuck From: Sam Hartman Message-Id: <20060120164219.202AFE006A@carter-zimmerman.mit.edu> Date: Fri, 20 Jan 2006 11:42:19 -0500 (EST) Sender: ietf-ssh-owner@NetBSD.org Precedence: list we are waiting for text to clear Russ's discuss comment. If there is no action on this draft by the end of February I will kill the draft and remove it from your work items as something the WG is clearly not interested in publishing. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 20 12:19:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzvT-0001QD-Po for secsh-archive@megatron.ietf.org; Fri, 20 Jan 2006 12:19:51 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01962 for ; Fri, 20 Jan 2006 12:18:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3799863B270; Fri, 20 Jan 2006 17:19:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.netbsd.org (Postfix) with ESMTP id 63D7963B10C for ; Fri, 20 Jan 2006 17:19:43 +0000 (UTC) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2006 09:19:43 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="250336092:sNHT31384996" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0KHJgc2008927 for ; Fri, 20 Jan 2006 09:19:42 -0800 (PST) Date: Fri, 20 Jan 2006 09:19:42 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: DH key exchange message numbers In-Reply-To: Message-ID: References: <2006118183926.624832@nucleus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Oops as well. :-( I'll propose the following errata: ---vvv--- RFC 4253 "The Secure Shell (SSH) Transport Layer Protocol" The table in Section 12. Current: SSH_MSG_DISCONNECT 1 SSH_MSG_IGNORE 2 SSH_MSG_UNIMPLEMENTED 3 SSH_MSG_DEBUG 4 SSH_MSG_SERVICE_REQUEST 5 SSH_MSG_SERVICE_ACCEPT 6 SSH_MSG_KEXINIT 20 SSH_MSG_NEWKEYS 21 Should be: SSH_MSG_DISCONNECT 1 SSH_MSG_IGNORE 2 SSH_MSG_UNIMPLEMENTED 3 SSH_MSG_DEBUG 4 SSH_MSG_SERVICE_REQUEST 5 SSH_MSG_SERVICE_ACCEPT 6 SSH_MSG_KEXINIT 20 SSH_MSG_NEWKEYS 21 SSH_MSG_KEXDH_INIT 30 SSH_MSG_KEXDH_REPLY 31 ---^^^--- Does this cover it? Thanks, Chris On Wed, 18 Jan 2006, Jeffrey Hutzelman wrote: > > > On Wednesday, January 18, 2006 06:39:26 PM +0100 denis bider > wrote: > >> Hi all, >> >> am I the only one who can't find KEXDH message numbers defined anywhere >> in the now published SSH RFCs? >> >> Given that KEXDH is a required key exchange method, I'd expect those >> message numbers to be defined in the Transport RFC. Yet, when I looked I >> couldn't find the actual message numbers defined. Is this just my >> oversight or is it everyone else's? :-) > > Oops. Indeed, those numbers were removed during editing, as a result of what > appears to have been some confusion. Someone commented during AUTH48 that > they should be removed from assignednumbers (now RFC4250), because they were > in the method-specific space and thus didn't need to be (and shouldn't be) in > the message number registry. > > Unfortunately, they also got dropped from -transport, where the method is > actually defined. As a result, these definitions are missing from the > protocol suite entirely, which I expect makes it tricky to implement. :-) > > The correct numbers are these: >> SSH_MSG_KEXDH_INIT 30 >> SSH_MSG_KEXDH_REPLY 31 > > I think we need an RFC Errata on this one... :-( > > > BTW, for those who've been looking for it and can't find it, the SSH > paramaters registry is at http://www.iana.org/assignments/ssh-parameters. > It seems the IANA hasn't yet published a link to that. > > -- Jeff > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 21 12:02:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0M85-0002BK-U9 for secsh-archive@megatron.ietf.org; Sat, 21 Jan 2006 12:02:22 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12973 for ; Sat, 21 Jan 2006 12:00:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2B94C63B1F0; Sat, 21 Jan 2006 17:02:14 +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 E736B63B134 for ; Sat, 21 Jan 2006 17:02:12 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1F0M7w-00055r-00 for ietf-ssh@netbsd.org; Sat, 21 Jan 2006 17:02:12 +0000 Date: Sat, 21 Jan 2006 17:02:12 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-publickeyfile is stuck Message-ID: <20060121170212.GA4583@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060120164219.202AFE006A@carter-zimmerman.mit.edu> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Sam Hartman writes: > we are waiting for text to clear Russ's discuss comment. which appears to be as follows: | Section 3.4 says: | > | > The body of a public key file consists of the public key blob as | > described in [I-D.ietf-secsh-transport], section 4.6, ... | > | There is no section 4.6 in the referenced document. I assume that | this should be a reference to section 6.6. (referring now to RFC 4253) I agree. | The examples in section 3.6 do not seem to match the key blob | description in [I-D.ietf-secsh-transport], section 6.6, which says: | > | > The key type MUST always be explicitly known (from algorithm | > negotiation or some other source). It is not normally included in | > the key blob. | > | But in this context, it is needed. This document should make this | clear with a MUST statement. Note that it is included in each of | the examples. I base64 decoded them and checked. There was a suggestion back in October that the above paragraph was misleading and should be stricken from the transport draft. However, nothing happened, and now it's in RFC 4253 so we'll have to live with it. I think the root cause of the confusion is that the term "blob" is poorly defined. publickeyfile says (section 3.4): : The body of a public key file consists of the public key blob as : described in [I-D.ietf-secsh-transport], section 4.6 [...] but the relevant section (6.6 as discussed above) does not define the term "public key blob" anywhere. It defines the encoding as : string certificate or public key format identifier : byte[n] key/certificate data In the absence of indications otherwise, I would have thought that "public key blob" referred to just the byte[n], not the format identifier -- especially as in the later definitions of signature formats, "blob" is defined that way. However, from the publickeyfile examples and existing practice, it is clearly intended that the publickeyfile body includes the format identifier. Sections 3.4 and 4 of publickeyfile should be amended to make this clear. I think that will address Russ' comment. (A further comment on RFC 4253 sec 6.6 -- rather late, I know: : The certificate part may be a zero length string, but a public key is : required. This is the public key that will be used for : authentication. The certificate sequence contained in the : certificate blob can be used to provide authorization. What is the "certificate part" referred to here? In the "ssh-rsa" and "ssh-dss" formats, I see no certificate, and no zero-length string replacing it. Going back through the list archives suggests that the first sentence has long been considered buggy. Oh well.) Further suggestions for publickeyfile-10, not related to Russ' DISCUSS: Neither the document title nor the abstract mention that this document defines a standard textual representation for public key fingerprints. This makes it harder than it could be to discover where the fingerprint format is defined. I suggest the following paragraph be added to the Abstract: In addition, this document defines a standard textual representation for SSH public key fingerprints. 2 (Introduction): typo: | This document describes a mechanism for creating a short text string | that that uniquely represents a particular public key, called ^^^^^ Remove duplicate "that". 3.2.2 (Comment Header): typo: | existing implementations fail if these quotation marks are omitted ^ Add full stop at end of sentence. 3.3.3 (New Headers): typo, imprecise text, IANA: | New headers that are of the from "x-" are considered experimental, ^^^^ | and may be used without IETF consensus. Suggested replacement text: Headers with header-tags beginning with "x-" are considered experimental, and may be used without IETF consensus. | All other headers are reserved for use only by IETF consensus. Doesn't this imply the existence of an IANA registry, contrary to what section 5 "IANA Considerations" says? 3.5 (Differences with RFC1421 PEM formats): typos: | Implemetors should take care to notice that while the format is ^^^^^^^^^^^ s/Implemetors/Implementers/ | o The other specifications use different BEGIN/END delimeters (five ^^^^^^^^^^ s/delimeters/delimiters/ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 21 14:24:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0OLJ-0006Ky-1x for secsh-archive@megatron.ietf.org; Sat, 21 Jan 2006 14:24:09 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20128 for ; Sat, 21 Jan 2006 14:22:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 77B6863B33D; Sat, 21 Jan 2006 19:24:04 +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 6E1E363B134 for ; Sat, 21 Jan 2006 19:24:03 +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 8404768 for ietf-ssh@netbsd.org; Sat, 21 Jan 2006 12:24:02 -0700 Message-ID: <43D28A77.4010300@vandyke.com> Date: Sat, 21 Jan 2006 12:24:39 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-publickeyfile is stuck References: <20060121170212.GA4583@chiark.greenend.org.uk> In-Reply-To: <20060121170212.GA4583@chiark.greenend.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Thank you for digging this up. I will make the edits suggested, probably Tuesday, and re-issue the draft. Thanks, Joseph Jacob Nevins wrote: > Sam Hartman writes: >> we are waiting for text to clear Russ's discuss comment. > > which appears to be as follows: > > | Section 3.4 says: > | > > | > The body of a public key file consists of the public key blob as > | > described in [I-D.ietf-secsh-transport], section 4.6, ... > | > > | There is no section 4.6 in the referenced document. I assume that > | this should be a reference to section 6.6. > > (referring now to RFC 4253) > I agree. > > | The examples in section 3.6 do not seem to match the key blob > | description in [I-D.ietf-secsh-transport], section 6.6, which says: > | > > | > The key type MUST always be explicitly known (from algorithm > | > negotiation or some other source). It is not normally included in > | > the key blob. > | > > | But in this context, it is needed. This document should make this > | clear with a MUST statement. Note that it is included in each of > | the examples. I base64 decoded them and checked. > > There was a suggestion back in October that the above paragraph was > misleading and should be stricken from the transport draft. However, > nothing happened, and now it's in RFC 4253 so we'll have to live with > it. > > I think the root cause of the confusion is that the term "blob" is > poorly defined. publickeyfile says (section 3.4): > > : The body of a public key file consists of the public key blob as > : described in [I-D.ietf-secsh-transport], section 4.6 [...] > > but the relevant section (6.6 as discussed above) does not define the > term "public key blob" anywhere. It defines the encoding as > > : string certificate or public key format identifier > : byte[n] key/certificate data > > In the absence of indications otherwise, I would have thought that > "public key blob" referred to just the byte[n], not the format > identifier -- especially as in the later definitions of signature > formats, "blob" is defined that way. > > However, from the publickeyfile examples and existing practice, it is > clearly intended that the publickeyfile body includes the format > identifier. > > Sections 3.4 and 4 of publickeyfile should be amended to make this > clear. I think that will address Russ' comment. > > > (A further comment on RFC 4253 sec 6.6 -- rather late, I know: > > : The certificate part may be a zero length string, but a public key is > : required. This is the public key that will be used for > : authentication. The certificate sequence contained in the > : certificate blob can be used to provide authorization. > > What is the "certificate part" referred to here? In the "ssh-rsa" and > "ssh-dss" formats, I see no certificate, and no zero-length string > replacing it. > > Going back through the list archives suggests that the first sentence > has long been considered buggy. Oh well.) > > > Further suggestions for publickeyfile-10, not related to Russ' DISCUSS: > > Neither the document title nor the abstract mention that this document > defines a standard textual representation for public key fingerprints. > This makes it harder than it could be to discover where the > fingerprint format is defined. > > I suggest the following paragraph be added to the Abstract: > > In addition, this document defines a standard textual > representation for SSH public key fingerprints. > > 2 (Introduction): typo: > | This document describes a mechanism for creating a short text string > | that that uniquely represents a particular public key, called > ^^^^^ > Remove duplicate "that". > > 3.2.2 (Comment Header): typo: > > | existing implementations fail if these quotation marks are omitted > ^ > Add full stop at end of sentence. > > 3.3.3 (New Headers): typo, imprecise text, IANA: > > | New headers that are of the from "x-" are considered experimental, > ^^^^ > | and may be used without IETF consensus. > > Suggested replacement text: > > Headers with header-tags beginning with "x-" are considered > experimental, and may be used without IETF consensus. > > | All other headers are reserved for use only by IETF consensus. > > Doesn't this imply the existence of an IANA registry, contrary to what > section 5 "IANA Considerations" says? > > 3.5 (Differences with RFC1421 PEM formats): typos: > | Implemetors should take care to notice that while the format is > ^^^^^^^^^^^ > s/Implemetors/Implementers/ > > | o The other specifications use different BEGIN/END delimeters (five > ^^^^^^^^^^ > s/delimeters/delimiters/ > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 25 19:21:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1utU-0001eI-Sg for secsh-archive@megatron.ietf.org; Wed, 25 Jan 2006 19:21:45 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15529 for ; Wed, 25 Jan 2006 19:20:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2876263B1FC; Thu, 26 Jan 2006 00:21:23 +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 D5CB263B1EF for ; Thu, 26 Jan 2006 00:21:19 +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 8423500; Wed, 25 Jan 2006 17:21:16 -0700 Message-ID: <43D8162F.6090304@vandyke.com> Date: Wed, 25 Jan 2006 17:22:07 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Internet-Drafts@ietf.org, ietf-ssh@NetBSD.org Subject: Please publish attached draft-ietf-secsh-filexfer-extensions-01 Content-Type: multipart/mixed; boundary="------------000002000402020108060200" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------000002000402020108060200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Joseph --------------000002000402020108060200 Content-Type: text/plain; name="draft-ietf-secsh-filexfer-extensions-01.txt" Content-Disposition: inline; filename="draft-ietf-secsh-filexfer-extensions-01.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: July 29, 2006 O. Saarenmaa F-Secure January 25, 2006 SSH File Transfer Protocol draft-ietf-secsh-filexfer-extensions-01.txt 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 July 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SSH File Transfer Protocol provides a rich infrastructure for sharing information about files. This document describes several optional extensions that build on this infrastructure. Galbraith & Saarenmaa Expires July 29, 2006 [Page 1] Internet-Draft SSH File Transfer Protocol January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Vendor Id . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. File Hashing . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Querying Available Space . . . . . . . . . . . . . . . . . . . 6 5. Querying User Home Directory . . . . . . . . . . . . . . . . . 7 6. Copying Remote Files . . . . . . . . . . . . . . . . . . . . . 7 7. Copying remote data . . . . . . . . . . . . . . . . . . . . . 7 8. Temporary files & directories . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Galbraith & Saarenmaa Expires July 29, 2006 [Page 2] Internet-Draft SSH File Transfer Protocol January 2006 1. Introduction This is a collection of optional extensions to the SSH File Transfer Protocol [I-D.ietf-secsh-filexfer]. This extensions make it possible for clients to query the server for additional information which may not be widely supported, but can increase the quality of the users experience when the server can support them. 2. Vendor Id It is often necessary to detect the version of the server so that bugs can be worked around. This extension allows the client to do so. string "vendor-id" string vendor-structure string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number vendor-name Arbitrary name identifying the maker of the product. product-name Arbitrary name identifying the product. product-name Arbitrary string identifying the version of the product. product-build-number A build-number for the product, such that if a bug is fixed in build-number 'x', it can be assumed that (barring regression in the product) it is fixed in all build-numbers > 'x'. This extension may also be sent by the client as a SSH_FXP_EXTENDED packet; in this case the contents of the vendor-structure become the extension-specific data: byte SSH_FXP_EXTENDED uint32 request-id string "vendor-id" string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number Galbraith & Saarenmaa Expires July 29, 2006 [Page 3] Internet-Draft SSH File Transfer Protocol January 2006 The server responds to this request with a SSH_FXP_STATUS message. The status SHOULD be SSH_FX_OK. 3. File Hashing This extension allows a client to easily check if a file (or portion thereof) that it already has matches what is on the server. byte SSH_FXP_EXTENDED uint32 request-id string "check-file-handle" / "check-file-name" string handle / name string hash-algorithm-list uint64 start-offset uint64 length uint32 block-size handle For "check-file-handle", 'handle' is an open file handle returned by SSH_FXP_OPEN. If 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST return SSH_FX_INVALID_HANDLE. If ACE4_READ_DATA was not included when the file was opened, the server MUST return STATUS_PERMISSION_DENIED. If this file handle was opened in SSH_FXF_ACCESS_TEXT_MODE mode, the check must be performed on the data as it would be sent on the wire. name For "check-file-name", 'name' is the path to the file to check. If 'check-file-name' is a directory, SSH_FX_FILE_IS_A_DIRECTORY SHOULD be returned. If 'check-file-name' refers to a SSH_FILEXFER_TYPE_SYMLINK, the target should be opened. The results are undefined file types other than SSH_FILEXFER_TYPE_REGULAR. The file MUST be opened without the SSH_FXF_ACCESS_TEXT_MODE access flag (in binary mode.) hash-algorithm-list A comma separated list of hash algorithms the client is willing to accept for this operation. The server MUST pick the first hash on the list that it supports. Galbraith & Saarenmaa Expires July 29, 2006 [Page 4] Internet-Draft SSH File Transfer Protocol January 2006 Currently defined algorithms are "md5", "sha1", "sha224", "sha256", "sha384", "sha512", and "crc32". Additional algorithms may be added by following the DNS extensibility naming convention outlined in [RFC4251]. MD5 is described in [RFC1321]. SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 are described in [FIPS-180-2]. [ISO.3309.1991] describes crc32, and is the same algorithm used in [RFC1510] start-offset The starting offset of the data to include in the hash. length The length of data to include in the hash. If length is zero, all the data from start-offset to the end-of-file should be included. block-size An independent hash MUST be computed over every block in the file. The size of blocks is specified by block-size. The block-size MUST NOT be smaller than 256 bytes. If the block-size is 0, then only one hash, over the entire range, MUST be made. The response is either a SSH_FXP_STATUS packet, indicating an error, or the following extended reply packet: This extension MUST be represented in the "supported2" extension as "check-file" and both version MUST either be support or neither. byte SSH_FXP_EXTENDED_REPLY uint32 request-id string hash-algo-used byte hash[n][block-count] hash-algo-used The hash algorithm that was actually used. hash The computed hashes. The hash algorithm used determines the size of n. The number of block-size chunks of data in the file determines block-count. The hashes are placed in the packet one after another, with no decoration. Note that if the length of the range is not an even multiple of block-size, the last hash will have been computed over only the remainder of the range instead of a full block. Galbraith & Saarenmaa Expires July 29, 2006 [Page 5] Internet-Draft SSH File Transfer Protocol January 2006 4. Querying Available Space The following extension provides a way to discover the available space for an arbitrary path. byte SSH_FXP_EXTENDED uint32 request-id string "space-available" string path [UTF-8] path 'path' for which the available space should be reported. This 'path' is not required to be the mount point path, but MAY be a directory or file contained within the mount. The reply to the request is as follows: byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint64 bytes-on-device uint64 unused-bytes-on-device uint64 bytes-available-to-user uint64 unused-bytes-available-to-user uint32 bytes-per-allocation-unit bytes-on-device The total number of bytes on the device which stores 'path', both used and unused, or 0 if unknown. unused-bytes-on-device The total number of unused bytes available on the device which stores 'path', or 0 if unknown. bytes-available-to-user The total number of bytes, both used and unused, available to the authenticated user on the device which stores 'path', or 0 if unknown. unused-bytes-available-to-user The total number of unused bytes available to the authenticated user on the device which stores 'path', or 0 if unknown. bytes-per-allocation-unit The number of bytes in each allocation unit on the device, or in other words, the minimum number of bytes that a file allocation size can grow or shrink by. If the server does not know this information, or the file-system in use does not use allocation blocks, this value MUST be 0. Galbraith & Saarenmaa Expires July 29, 2006 [Page 6] Internet-Draft SSH File Transfer Protocol January 2006 5. Querying User Home Directory Many users are used to being able to type '~' as an alias for their home directory, or ~username as an alias for another user's home directory. To support this feature, a server MAY support following extension. byte SSH_FXP_EXTENDED uint32 request-id string "home-directory" string username [UTF-8] username Username whose home directory path is being requested. An empty string implies the current user. The reply to the request is either a SSH_FXP_STATUS packet or a SSH_FXP_NAME packet containing the absolute real-path of the home directory. 6. Copying Remote Files byte SSH_FXP_EXTENDED uint32 request-id string "copy-file" string source-file string destination-file bool overwrite-destination ATTRS destination-attrib This request copies a file from one location to another on the server. The server responds with SSH_FXP_STATUS. 7. Copying remote data byte SSH_FXP_EXTENDED uint32 request-id string "copy-data" string read-from-handle uint64 read-from-offset uint64 read-data-length string write-to-handle uint64 write-to-offset Copy data from one handle to another on the server. The server responds with SSH_FXP_STATUS. Galbraith & Saarenmaa Expires July 29, 2006 [Page 7] Internet-Draft SSH File Transfer Protocol January 2006 The server MUST copy the data exactly as if the client had issued a series of SSH_FXP_READ requests on the read-from-handle starting at read-from-offset and totaling read-data-length bytes, and issued a series of SSH_FXP_WRITE packets on the write-to-handle, starting at the write-from-offset, and totaling the total number of bytes read by the SSH_FXP_READ packets. If one of the files is open using SSH_FXF_TEXT_MODE, then operation on that handle honors all of the SSH_FXF_TEXT_MODE behaviors. The server SHOULD allow 'read-from-handle' and 'write-to-handle' to be the same handle as long as the range of data is not overlapping. This allows data to efficiently be moved within a file. The server MUST fail the request with a SSH_FX_INVALID_PARAMETER if the range is overlapping and it doesn't correctly handle this case. The server is not required to detect overlapping ranges if read-from-handle and write-to-handle are different handles referring to the same file. If 'data-length' is 0, this imples data should be read until EOF is encountered. There are no protocol restictions on this operation; however, the server MUST ensure that the user does not exceed quota, etc. The server is, as always, free to complete this operation out of order if it is too large to complete immediately, or to refuse a request that is too large. 8. Temporary files & directories byte SSH_FXP_EXTENDED uint32 request-id string "get-temp-folder" Retrieves the users preferred location for temporary files and folders. The server responds with SSH_FXP_STATUS or SSH_FXP_NAME containing the realpath of the preferred location. byte SSH_FXP_EXTENDED uint32 request-id string "make-temp-folder" ATTRS attrib Requests that the server create a folder in the users preferred location for temporary files and folders for use by the client. The server responds with SSH_FXP_STATUS or SSH_FXP_NAME containing the realpath of the new folder. Galbraith & Saarenmaa Expires July 29, 2006 [Page 8] Internet-Draft SSH File Transfer Protocol January 2006 It is the clients responsibility to cleanup and remove the folder when it is done with it. However, the server MAY remove the folder and it's contents when the client closes the connection. 9. Security Considerations The home directory extension could be used to discover whether a given user is valid; however, since users are assumed to be authenticated by the underlying protocol, this is probably not significant in most situations. If a server would not normally allow an authenticated user to query the existance of another user, the server MUST NOT allow the "home-directory" extension. 10. References 10.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [I-D.ietf-secsh-filexfer] Galbraith, J. and O. Saarenmaa, "SSH File Transfer Protocol", draft-ietf-secsh-filexfer-11 (work in progress), January 2006. [FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002. [ISO.3309.1991] International Organization for Standardization, "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", ISO Standard 3309, June 1991. Galbraith & Saarenmaa Expires July 29, 2006 [Page 9] Internet-Draft SSH File Transfer Protocol January 2006 10.2. Informative References Trademark notice "ssh" is a registered trademark in the United States and/or other countries. Galbraith & Saarenmaa Expires July 29, 2006 [Page 10] Internet-Draft SSH File Transfer Protocol January 2006 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 Oskari Saarenmaa F-Secure Tammasaarenkatu 7 Helsinki 00180 FI Email: oskari.saarenmaa@f-secure.com Galbraith & Saarenmaa Expires July 29, 2006 [Page 11] Internet-Draft SSH File Transfer Protocol January 2006 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 (2006). 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 & Saarenmaa Expires July 29, 2006 [Page 12] --------------000002000402020108060200-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 25 19:41:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1vCo-0001hp-Ey for secsh-archive@megatron.ietf.org; Wed, 25 Jan 2006 19:41:42 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18040 for ; Wed, 25 Jan 2006 19:40:09 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CF8A063B125; Thu, 26 Jan 2006 00:41:37 +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 45C5D63B230 for ; Thu, 26 Jan 2006 00:41:35 +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 8423581; Wed, 25 Jan 2006 17:41:34 -0700 Message-ID: <43D81AF1.2090100@vandyke.com> Date: Wed, 25 Jan 2006 17:42:25 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ietf-ssh@NetBSD.org Subject: Please publish attached draft-ietf-secsh-publickeyfile-11.txt Content-Type: multipart/mixed; boundary="------------010604080500010302030004" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------010604080500010302030004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Joseph --------------010604080500010302030004 Content-Type: text/plain; name="draft-ietf-secsh-publickeyfile-11.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickeyfile-11.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: July 29, 2006 R. Thayer The Tillerman Group January 25, 2006 SSH Public Key File Format draft-ietf-secsh-publickeyfile-11.txt 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 July 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. Galbraith & Thayer Expires July 29, 2006 [Page 1] Internet-Draft SSH Public Key File Format January 2006 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 3.3.3. New Headers . . . . . . . . . . . . . . . . . . . . . 6 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Galbraith & Thayer Expires July 29, 2006 [Page 2] Internet-Draft SSH Public Key File Format January 2006 1. 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 [RFC2119]. Galbraith & Thayer Expires July 29, 2006 [Page 3] Internet-Draft SSH Public Key File Format January 2006 2. Introduction The SSH protocol supports the use of public/private key pairs in order to perform perform authentication based on public-key cryptography. However, in order to use public-key authentication in the SSH protocol, public keys must first be exchanged between client and server. This document formally describes an existing public-key file format which can be used with any of the common existing file transfer mechanisms in order to exchange public keys. The SSH protocol also uses public/private key pairs to authenticate the server. In this scenario, it is important to verify that the public key provided by the server is indeed the server's public-key. This document describes a mechanism for creating a short text string that uniquely represents a particular public key, called fingerprinting. Galbraith & Thayer Expires July 29, 2006 [Page 4] Internet-Draft SSH Public Key File Format January 2006 3. Key File Format In order to implement public key authentication, SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.1. Line Termination Characters Implementations SHOULD generate public key files using their system's local text file representation. In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of the common line termination sequence, , or . 3.2. Begin and End Markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- The last line of a conforming key file MUST be an end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3. Key File Header The key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value The Header-tag MUST NOT be more than 64 8-bit bytes, and is case- insensitive. The Header-value MUST NOT be more than 1024 8-bit bytes. Each line in the header MUST NOT be more than 72 8-bit bytes. A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of the line is formed by removing the '\' and the line termination characters, and appending the contents of the next line. The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be Galbraith & Thayer Expires July 29, 2006 [Page 5] Internet-Draft SSH Public Key File Format January 2006 encoded in UTF-8. [RFC3629] A line that is not a continuation line that has no ':' in it is the first line of the base 64 encoded body (See Section 3.4.) Compliant implementations MUST ignore unrecognized header fields. Implementations SHOULD preserve unrecognized header fields when manipulating the key file. 3.3.1. Subject Header This field is used to store the login-name that the key was generated under. For example: Subject: user 3.3.2. Comment Header The comment header contains a user specified comment. The comment SHOULD be displayed when using the key. It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: Comment: user@example.com Currently, common practice is to quote the Header-value of the Comment by prefixing and suffixing it with '"' characters, and some existing implementations fail if these quotation marks are omitted. Compliant implementations MUST function correctly if the quotation marks are omitted. Implementations MAY include the quotation marks. If the first and last characters of the Header-value are matching quotation marks, implementations SHOULD remove them before using the value. 3.3.3. New Headers Headers with header-tags beginning with "x-" are considered experimental, and may be used without IETF consensus. All other headers are reserved for use only by IETF consensus. 3.4. Public Key File Body The body of a public-key file is the base64 encoded ([RFC2045]) public-key data as specified by [RFC4253], section 6.6: Galbraith & Thayer Expires July 29, 2006 [Page 6] Internet-Draft SSH Public Key File Format January 2006 string certificate or public key format identifier byte[n] key/certificate data As with all other lines, each line in the body MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.5. Differences with RFC1421 PEM formats Implementers should take care to notice that while the format is superficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably: o The other specifications use different BEGIN/END delimiters (five dashes, no space rather than four dashes and a space). o There is no blank line before the start of the base64-encoded contents. o There is no CRC at the end of the base64-encoded block. o Header continuation uses a backslash at the end of the continued line rather then whitespace at the start of the next line. 3.6. Examples The following are some example public key files that are compliant (note that the examples all wrap before 72 bytes to meet ietf document requirements; however, they are still compliant.) ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by me@example.com" x-command: /home/galb/bin/lock-in-guest.sh AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires July 29, 2006 [Page 7] Internet-Draft SSH Public Key File Format January 2006 ---- BEGIN SSH2 PUBLIC KEY ---- Comment: This is my public key for use on \ servers which I don't like. AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Comment: DSA Public Key for use with MyIsp AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by me@example.com Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires July 29, 2006 [Page 8] Internet-Draft SSH Public Key File Format January 2006 4. Public Key Fingerprints The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This section formally describes the method of generating public key fingerprints that is in common use in the SSH community. The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC1321]. The input to the algorithm is the public-key data as specified by [RFC4253]. (This is the same data that is base64 encoded to form the body of the public-key file.) The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" Galbraith & Thayer Expires July 29, 2006 [Page 9] Internet-Draft SSH Public Key File Format January 2006 5. IANA Considerations An IANA registry needs to be created containing the defined header- tags. These are 'subject' and 'comment' Galbraith & Thayer Expires July 29, 2006 [Page 10] Internet-Draft SSH Public Key File Format January 2006 6. Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering with the data stored in such files. Given the potential of an adversarial tampering with this data, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files. Also, if the contents of these files are transferred it SHOULD be done over a trusted channel. The header data allowed by this file format could contain an unlimited range of information. While in many environments the information conveyed by this header data may be considered innocuous public information, it may constitute a channel through which information about a user, a key or its use may be disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, Home Phone:..."). The presence and use of this header data SHOULD be reviewed by sites that deploy this file format. The public-key fingerprint method presented here relies on the MD5 one-way hash function, which is known to have certain weaknesses regarding its collision resistance; however, the particular use made of MD5 here depends solely on its 2nd-preimage resistance, not on its collision resistance. MD5 is used here for historical reasons. Galbraith & Thayer Expires July 29, 2006 [Page 11] Internet-Draft SSH Public Key File Format January 2006 7. References 7.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. 7.2. Informative References [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. Galbraith & Thayer Expires July 29, 2006 [Page 12] Internet-Draft SSH Public Key File Format January 2006 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 Rodney Thayer The Tillerman Group 370 Altair Way, PMB 321 Sunnyvale, CA 94086 Phone: +1 408 757 9693 Email: rodney@tillerman.to Galbraith & Thayer Expires July 29, 2006 [Page 13] Internet-Draft SSH Public Key File Format January 2006 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 (2006). 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 & Thayer Expires July 29, 2006 [Page 14] --------------010604080500010302030004-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 25 19:42:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1vDF-0001lI-GT for secsh-archive@megatron.ietf.org; Wed, 25 Jan 2006 19:42:09 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18075 for ; Wed, 25 Jan 2006 19:40:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C44B063B224; Thu, 26 Jan 2006 00:42:03 +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 A31E063B1E2 for ; Thu, 26 Jan 2006 00:42:02 +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 8423584 for ietf-ssh@netbsd.org; Wed, 25 Jan 2006 17:42:01 -0700 Message-ID: <43D81B0D.2040907@vandyke.com> Date: Wed, 25 Jan 2006 17:42:53 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-publickeyfile is stuck References: <20060121170212.GA4583@chiark.greenend.org.uk> In-Reply-To: <20060121170212.GA4583@chiark.greenend.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I believe I have addressed Russ's and your comments now. Thanks, Joseph Jacob Nevins wrote: > Sam Hartman writes: >> we are waiting for text to clear Russ's discuss comment. > > which appears to be as follows: > > | Section 3.4 says: > | > > | > The body of a public key file consists of the public key blob as > | > described in [I-D.ietf-secsh-transport], section 4.6, ... > | > > | There is no section 4.6 in the referenced document. I assume that > | this should be a reference to section 6.6. > > (referring now to RFC 4253) > I agree. > > | The examples in section 3.6 do not seem to match the key blob > | description in [I-D.ietf-secsh-transport], section 6.6, which says: > | > > | > The key type MUST always be explicitly known (from algorithm > | > negotiation or some other source). It is not normally included in > | > the key blob. > | > > | But in this context, it is needed. This document should make this > | clear with a MUST statement. Note that it is included in each of > | the examples. I base64 decoded them and checked. > > There was a suggestion back in October that the above paragraph was > misleading and should be stricken from the transport draft. However, > nothing happened, and now it's in RFC 4253 so we'll have to live with > it. > > I think the root cause of the confusion is that the term "blob" is > poorly defined. publickeyfile says (section 3.4): > > : The body of a public key file consists of the public key blob as > : described in [I-D.ietf-secsh-transport], section 4.6 [...] > > but the relevant section (6.6 as discussed above) does not define the > term "public key blob" anywhere. It defines the encoding as > > : string certificate or public key format identifier > : byte[n] key/certificate data > > In the absence of indications otherwise, I would have thought that > "public key blob" referred to just the byte[n], not the format > identifier -- especially as in the later definitions of signature > formats, "blob" is defined that way. > > However, from the publickeyfile examples and existing practice, it is > clearly intended that the publickeyfile body includes the format > identifier. > > Sections 3.4 and 4 of publickeyfile should be amended to make this > clear. I think that will address Russ' comment. > > > (A further comment on RFC 4253 sec 6.6 -- rather late, I know: > > : The certificate part may be a zero length string, but a public key is > : required. This is the public key that will be used for > : authentication. The certificate sequence contained in the > : certificate blob can be used to provide authorization. > > What is the "certificate part" referred to here? In the "ssh-rsa" and > "ssh-dss" formats, I see no certificate, and no zero-length string > replacing it. > > Going back through the list archives suggests that the first sentence > has long been considered buggy. Oh well.) > > > Further suggestions for publickeyfile-10, not related to Russ' DISCUSS: > > Neither the document title nor the abstract mention that this document > defines a standard textual representation for public key fingerprints. > This makes it harder than it could be to discover where the > fingerprint format is defined. > > I suggest the following paragraph be added to the Abstract: > > In addition, this document defines a standard textual > representation for SSH public key fingerprints. > > 2 (Introduction): typo: > | This document describes a mechanism for creating a short text string > | that that uniquely represents a particular public key, called > ^^^^^ > Remove duplicate "that". > > 3.2.2 (Comment Header): typo: > > | existing implementations fail if these quotation marks are omitted > ^ > Add full stop at end of sentence. > > 3.3.3 (New Headers): typo, imprecise text, IANA: > > | New headers that are of the from "x-" are considered experimental, > ^^^^ > | and may be used without IETF consensus. > > Suggested replacement text: > > Headers with header-tags beginning with "x-" are considered > experimental, and may be used without IETF consensus. > > | All other headers are reserved for use only by IETF consensus. > > Doesn't this imply the existence of an IANA registry, contrary to what > section 5 "IANA Considerations" says? > > 3.5 (Differences with RFC1421 PEM formats): typos: > | Implemetors should take care to notice that while the format is > ^^^^^^^^^^^ > s/Implemetors/Implementers/ > > | o The other specifications use different BEGIN/END delimeters (five > ^^^^^^^^^^ > s/delimeters/delimiters/ > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 26 15:50:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2E4l-0004Ri-7Z for secsh-archive@megatron.ietf.org; Thu, 26 Jan 2006 15:50:39 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24091 for ; Thu, 26 Jan 2006 15:49:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4CD6263B380; Thu, 26 Jan 2006 20:50:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 51E7263B367 for ; Thu, 26 Jan 2006 20:50:05 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2E4A-0008Oy-KN; Thu, 26 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-12.txt Message-Id: Date: Thu, 26 Jan 2006 15:50:02 -0500 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 : SSH File Transfer Protocol Author(s) : J. Galbraith, O. Saarenmaa Filename : draft-ietf-secsh-filexfer-12.txt Pages : 59 Date : 2006-1-26 The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-12.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-filexfer-12.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-filexfer-12.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: <2006-1-26152437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-26152437.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 26 15:50:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2E4z-0004UZ-7L for secsh-archive@megatron.ietf.org; Thu, 26 Jan 2006 15:50:53 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24108 for ; Thu, 26 Jan 2006 15:49:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CA79163B385; Thu, 26 Jan 2006 20:50:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 4722263B35C for ; Thu, 26 Jan 2006 20:50:05 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2E4A-0008Oh-Gd; Thu, 26 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-11.txt Message-Id: Date: Thu, 26 Jan 2006 15:50:02 -0500 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 : SSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-11.txt Pages : 14 Date : 2006-1-26 This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-11.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-publickeyfile-11.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-publickeyfile-11.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: <2006-1-26151719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-26151719.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 26 16:28:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Ef5-0003SC-3T for secsh-archive@megatron.ietf.org; Thu, 26 Jan 2006 16:28:11 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04828 for ; Thu, 26 Jan 2006 16:26:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3082F63B354; Thu, 26 Jan 2006 21:28:07 +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 85EAF63B2C9 for ; Thu, 26 Jan 2006 21:28:06 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1F2Eez-0006dq-00 for ietf-ssh@netbsd.org; Thu, 26 Jan 2006 21:28:05 +0000 Date: Thu, 26 Jan 2006 21:28:05 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-publickeyfile is stuck Message-ID: <20060126212804.GA24194@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D81B0D.2040907@vandyke.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: > I believe I have addressed Russ's and your comments now. Yes, I'm happy that draft-ietf-secsh-publickeyfile-11 addresses my comments, thanks. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 27 18:50:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2dM2-0003ve-Er for secsh-archive@megatron.ietf.org; Fri, 27 Jan 2006 18:50:10 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27084 for ; Fri, 27 Jan 2006 18:48:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B798E63B22D; Fri, 27 Jan 2006 23:50:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id BDC1E63B152 for ; Fri, 27 Jan 2006 23:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2dLu-00068M-2W; Fri, 27 Jan 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-extensions-00.txt Message-Id: Date: Fri, 27 Jan 2006 18:50:02 -0500 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 : SSH File Transfer Protocol Author(s) : J. Galbraith, O. Saarenmaa Filename : draft-ietf-secsh-filexfer-extensions-00.txt Pages : 12 Date : 2006-1-27 The SSH File Transfer Protocol provides a rich infrastructure for sharing information about files. This document describes several optional extensions that build on this infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-extensions-00.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-filexfer-extensions-00.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-filexfer-extensions-00.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: <2006-1-27160404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-27160404.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 31 14:13:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40wZ-0008SZ-DQ for secsh-archive@megatron.ietf.org; Tue, 31 Jan 2006 14:13:35 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20280 for ; Tue, 31 Jan 2006 14:11:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3740B63B1A8; Tue, 31 Jan 2006 19:13:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 57E5263B10C for ; Tue, 31 Jan 2006 19:13:24 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2006 11:13:18 -0800 X-IronPort-AV: i="4.01,240,1136188800"; d="scan'208"; a="398829057:sNHT31577368" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0VJDHjt002320; Tue, 31 Jan 2006 11:13:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: URI Draft Date: Tue, 31 Jan 2006 11:19:49 -0800 Message-ID: <7210B31550AC934A8637D6619739CE69068C20A8@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: URI Draft Thread-Index: AcYXJ++nfAsc4FHYRs+fGZOlyK8U/QPchBog From: "Salowey, Joe" To: "Steve Suehring" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I agree with Steve, the SSH URI can progress more quickly apart from the SFTP URI. We will be submitting an update to the draft shortly that could easily be separated into and SSH URI draft and an SFTP URI draft. I think the SSH URI portion is pretty close to done. Joe =20 > -----Original Message----- > From: Steve Suehring [mailto:suehring@braingia.org]=20 > Sent: Wednesday, January 11, 2006 6:57 PM > To: ietf-ssh@NetBSD.org > Subject: URI Draft >=20 > Hi all, >=20 > I apologize if the following has already been discussed. I've been > somewhat away from the mailing list for a time and can't remember if > this was discussed here or elsewhere off-list.=20 >=20 > I, along with all of you, would like to get the URI draft wrapped up > asap. From what I've gathered from the comments and discussion, there > seems to be some disagreement on the formatting of scp and=20 > sftp URIs and > less so for the ssh URI. >=20 > Therefore, is it in the best interest of the community (and=20 > WG) to split > these drafts into three separate drafts, one for each of scp,=20 > sftp, and > ssh? The ssh draft might gain consensus from the WG leaving=20 > the other=20 > two to be discussed further. >=20 > Opinions? >=20 > Steve >=20 >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 31 20:43:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F471t-0005CU-K9 for secsh-archive@megatron.ietf.org; Tue, 31 Jan 2006 20:43:29 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24118 for ; Tue, 31 Jan 2006 20:41:44 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A64ED63B348; Wed, 1 Feb 2006 01:43:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by mail.netbsd.org (Postfix) with ESMTP id BBC8063B15C for ; Wed, 1 Feb 2006 01:43:10 +0000 (UTC) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.8/8.12.8) with ESMTP id k110p555020039; Tue, 31 Jan 2006 16:51:05 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.8/8.12.8/Submit) id k110p5tT020038; Tue, 31 Jan 2006 16:51:05 -0800 Date: Tue, 31 Jan 2006 16:51:05 -0800 Message-Id: <200602010051.k110p5tT020038@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4335 on The Secure Shell (SSH) Session Channel Break Extension From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=15efe2c35aaaf0f296dfeefe60f9c2e3 --15efe2c35aaaf0f296dfeefe60f9c2e3 Content-Type: text/plain Content-Transfer-Encoding: 8bit A new Request for Comments is now available in online RFC libraries. RFC 4335 Title: The Secure Shell SSH Session Channel Break Extension Author: J. Galbraith, P. Remaker Status: Standards Track Date: January 2006 Mailbox: galb-list@vandyke.com, remaker@cisco.com Pages: 6 Characters: 11370 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-break-04.txt URL: http://www.rfc-editor.org/rfc/rfc4335.txt The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS TRACK] This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the \"Internet Official Protocol Standards\" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... --15efe2c35aaaf0f296dfeefe60f9c2e3 A new Request for Comments is now available in online RFC libraries. RFC 4335 Title: The Secure Shell SSH Session Channel Break Extension Author: J. Galbraith, P. Remaker Status: Standards Track Date: January 2006 Mailbox: galb-list@vandyke.com, remaker@cisco.com Pages: 6 Characters: 11370 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-break-04.txt URL: http://www.rfc-editor.org/rfc/rfc4335.txt The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS TRACK] This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the \"Internet Official Protocol Standards\" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ...