From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 1 02:14:25 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21865 for ; Fri, 1 Oct 2004 02:14:24 -0400 (EDT) Received: (qmail 26051 invoked by uid 605); 1 Oct 2004 06:14:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26041 invoked from network); 1 Oct 2004 06:14:21 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 1 Oct 2004 06:14:21 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id F338E1F2952 for ; Fri, 1 Oct 2004 08:14:13 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 0C6036C007; Fri, 1 Oct 2004 08:14:16 +0200 (MEST) Date: Fri, 1 Oct 2004 08:14:13 +0200 (CEST) From: Martin Forssen Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft To: ietf-ssh@NetBSD.org Cc: rg@appgate.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20041001061416.0C6036C007@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 30 Sep, Jeffrey Hutzelman wrote: > Indeed. Imagine the scenario where a user has a Kerberos password and some > kind of challenge/response token. Now, suppose the user comes in to work > and leaves the token home. He wants to use Kerberos, so he sends a > submethod list containing "kerb5". The server doesn't support "kerb5", > because the method is called "krb5". > > Now, should the server > (a) fail the exchange, reporting that it can't support any of the methods > the user asked for > (b) continue by arbitrarily selecting the method that requires the > challenge/response token which the user left at home Well, there are a couple of options here. In (a) the server could tell the user (through kbdint or banner) which submethods it does support. There is also a third alternative (c) Ask the user (through kbdint) which method they want to use. I am not saying that either of these methods is perfect nor even good... If I were to redesign kbdint today I would probably move up the submethod one level. So the server should present the different submethods as different authentication methods. For example kbdint/krb5 and kbdint/securid, but in the client both of these could be handled by the same code. The advantage of this approach is that we reuse the authmethod presentation/negotiation already present in the protocol. The drawback is that it requires protocol changes. So implementations would, for a long time, need to support both the current kbdint and the new. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 1 02:15:46 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23062 for ; Fri, 1 Oct 2004 02:15:46 -0400 (EDT) Received: (qmail 27216 invoked by uid 605); 1 Oct 2004 06:15:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27205 invoked from network); 1 Oct 2004 06:15:45 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 1 Oct 2004 06:15:44 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 6E3161F2947; Fri, 1 Oct 2004 08:15:43 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 217F86C007; Fri, 1 Oct 2004 08:15:45 +0200 (MEST) Date: Fri, 1 Oct 2004 08:15:42 +0200 (CEST) From: Martin Forssen Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft To: pgut001@cs.auckland.ac.nz Cc: ietf-ssh@NetBSD.org, nisse@lysator.liu.se MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20041001061545.217F86C007@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 1 Oct, Peter Gutmann wrote: > Fair enough. Since it's now being used as a kitchen-sink authentication > mechanism though, it would be good to at least have an implementation- > considerations section on non-interactive auth I have no problem with this. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 1 06:33:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15249 for ; Fri, 1 Oct 2004 06:33:27 -0400 (EDT) Received: (qmail 25421 invoked by uid 605); 1 Oct 2004 10:33:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25412 invoked from network); 1 Oct 2004 10:33:23 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 1 Oct 2004 10:33:23 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 10F95190265; Fri, 1 Oct 2004 12:33:22 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 28E70173C9C; Fri, 1 Oct 2004 12:33:19 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i91AXIih022971; Fri, 1 Oct 2004 12:33:18 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i91AXB02022968; Fri, 1 Oct 2004 12:33:11 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Damien Miller Cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft References: <415BB4A1.1040102@mindrot.org> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 01 Oct 2004 12:33:09 +0200 In-Reply-To: <415BB4A1.1040102@mindrot.org> Message-ID: Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 3.0.0-lysator_lenin_1.0 (2004-09-13) on lenin.lysator.liu.se X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=failed version=3.0.0-lysator_lenin_1.0 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Damien Miller writes: > This isn't entirely true: you can specify "method1,method2,method3" and > sshd will allow authentication using method3 if the method1 and method2 > don't exist. > > I'm not sure what you would have us do: kbdint doesn't seem to provide a > way for a server to report supported methods to a client and I don't > think it is correct to just ignore what a client has specified and > continue with a random method that the server picks. I think the following three steps would improve the situation: 1. Require the names listed in the submethods field to be proper ssh names. I.e. standardized names without @, local/vendor stuff with @domain attached. Encourage documentation of the @domain things that implementations support. 2. Allow the server to use methods not on the client's list, in case none of the listed methods is implemented or configured for use by the server. (For methods that are implemented and acceptable for the server, the server should respect the client preferences). 3. Use the name field in the SSH_MSG_USERAUTH_INFO_REQUEST (or introduce a new field, if the "name" field is intended for the UI) to tell the client which method the server has selected. This way, the client can know if the server is about to ignore its submethods preferences, and can abort the keyboard-interactive if it so wishes. I'm not sure how well [1] fits with PAM, but I think the easiest way out for a PAM backend is to always ignore the submethods list. That is natural, since PAM, by design, refuses to expose any information whatsoever about the selection of underlying mechanisms. In step [3], the PAM backend could send the empty string as the method name, to indicate that it has no clue about which mechanism is actually used. (If it turns out that the above, which seems like a perfectly reasonable protocol design to me, is for some reason impossible to do with a PAM backend, and that is considered a show stopper, then I think I'd prefer to have two distinct methods, pam-over-ssh and keyboard-interactive, which each does its respective job well, than to have a compromise that sucks for all uses). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 1 20:23:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12847 for ; Fri, 1 Oct 2004 20:23:27 -0400 (EDT) Received: (qmail 10422 invoked by uid 605); 2 Oct 2004 00:23:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10411 invoked from network); 2 Oct 2004 00:23:26 -0000 Received: from repulse.concentric.net (HELO repulse.cnchost.com) (207.155.248.4) by mail.netbsd.org with SMTP; 2 Oct 2004 00:23:26 -0000 Received: from Nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by repulse.cnchost.com id SAA23166; Fri, 1 Oct 2004 18:23:10 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Subject: RE: SFTP v5... Date: Sat, 2 Oct 2004 00:23:04 +0200 Message-ID: <00ca01c4a805$3ae3b180$6302a8c0@Nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040929184930.GA20607@chiark.greenend.org.uk> Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Incidentally, is anyone interested in my proposal to give the server > the ability to advise the client whether opening in FXF_TEXT mode is > advisable? (<20030926223441.GA16719@chiark.greenend.org.uk> about a > year ago.) If so, I'm willing to dust it off. It is my and my colleagues' belief that the SFTP protocol very much lacks the ability for the client to inquire before downloading whether a file is textual or not. This makes it unnecessarily difficult to implement "automatic" mode transfers. The best a client can currently do is open the file, read an arbitrarily large block and decide if the file looks textual. This algorithm would be much better implemented at the server, in particular because some platforms may have specific formats for text files which will make the file seem binary when inspected in binary mode by a naive client implementation. If what you mention is a solution to this problem, then yes, I think it would be a very good idea. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 2 09:20:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15984 for ; Sat, 2 Oct 2004 09:20:13 -0400 (EDT) Received: (qmail 6307 invoked by uid 605); 2 Oct 2004 13:20:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6296 invoked from network); 2 Oct 2004 13:20:06 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 2 Oct 2004 13:20:06 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 523641EE00B; Sat, 2 Oct 2004 15:18:29 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id AA9BA1EDF9F for ; Sat, 2 Oct 2004 15:18:27 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i92DIQih008407 for ; Sat, 2 Oct 2004 15:18:26 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i92DIKap008404; Sat, 2 Oct 2004 15:18:20 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@NetBSD.org Subject: How to treat utf8 text with overlong utf8 sequences? Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 02 Oct 2004 15:18:19 +0200 Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 3.0.0-lysator_lenin_1.0 (2004-09-13) on lenin.lysator.liu.se X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=failed version=3.0.0-lysator_lenin_1.0 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit What do you think about sending overlong / "non-minimum form" utf8 sequences in various utf8 strings in the protocol? It matters the most for utf8 strings that are displayed to the user, e.g. the prompt strings in SSH_MSG_USERAUTH_INFO_REQUEST, where the specification recommends control character filtering. I prefer doing the control filtering before converting the data to the local character set, because it's pretty well defined which ucs4/unicode values are control characters (namely u0000-u001f, u007f-u009f). If we allow overlong control character sequences, then e .g. ESC can be represented in utf8 as 0x1b, (0xc0 0x9b), (0xe0 0x80 0x9b) ... or (0xfc 0x80 0x80 0x80 0x80 0x9b) Filtering gets easier if I can first check if the utf8 string contains overlong sequences at an early stage, and treat that as a protocol error. About the same question applies for the utf8 encoding of ud800-udfff (surrogates) and the non-characters ufffe and uffff, which are also not supposed to ever occur in valid utf8 text. RFC 2279 does not address these questions, as far as I can see. I'm tempted to treat any use of overlong or otherwise invalid utf8 strings that I receive from the remote end as a protocol error. * Do you think that is a reasonable thing to do? * Does it violate the ssh specification? * Will it cause any interoperability problems in practice? Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 2 10:53:05 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21377 for ; Sat, 2 Oct 2004 10:53:05 -0400 (EDT) Received: (qmail 29975 invoked by uid 605); 2 Oct 2004 14:53:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29966 invoked from network); 2 Oct 2004 14:53:03 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 2 Oct 2004 14:53:03 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1CDkwj-0002gc-00; Sat, 02 Oct 2004 15:33:13 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: Subject: Re: How to treat utf8 text with overlong utf8 sequences? Message-Id: Date: Sat, 02 Oct 2004 15:33:13 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Niels Möller wrote: > What do you think about sending overlong / "non-minimum form" utf8 > sequences in various utf8 strings in the protocol? Should be illegal, definitely. > RFC 2279 does not address these questions, as far as I can see. I think it does, if only obliquely. Section 2 says: | 1) Determine the number of octets required from the character value | and the first column of the table above. It is important to note | that the rows of the table are mutually exclusive, i.e. there is | only one valid way to encode a given UCS-4 character. I think that adequately justifies considering any overlong sequence to be completely invalid. > I'm tempted to treat any use of overlong or otherwise invalid utf8 > strings that I receive from the remote end as a protocol error. > > * Do you think that is a reasonable thing to do? Definitely. > * Does it violate the ssh specification? I don't think so. > * Will it cause any interoperability problems in practice? It _shouldn't_; but failure to disallow overlong sequences could cause security problems, therefore it's reasonable to consider any implementation currently generating them to require fixing. All IMO, of course. -- Simon Tatham "Happiness is having a large, warm, loving, caring, close-knit family in another city." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 2 13:00:38 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27076 for ; Sat, 2 Oct 2004 13:00:38 -0400 (EDT) Received: (qmail 14757 invoked by uid 605); 2 Oct 2004 17:00:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14748 invoked from network); 2 Oct 2004 17:00:37 -0000 Received: from main.gmane.org (80.91.229.2) by mail.netbsd.org with SMTP; 2 Oct 2004 17:00:36 -0000 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CDnFL-00009h-00 for ; Sat, 02 Oct 2004 19:00:35 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 19:00:34 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Oct 2004 19:00:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-ssh@NetBSD.org From: Simon Josefsson Subject: Re: How to treat utf8 text with overlong utf8 sequences? Date: Sat, 02 Oct 2004 18:55:46 +0200 Lines: 21 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:OaSxCCi+Y2FQkUQCpb4X2qs9/3Q= Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit nisse@lysator.liu.se (Niels Möller) writes: > What do you think about sending overlong / "non-minimum form" utf8 > sequences in various utf8 strings in the protocol? ... > RFC 2279 does not address these questions, as far as I can see. For what it's worth, RFC 2279 is obsoleted by RFC 3629, which include: Implementations of the decoding algorithm above MUST protect against decoding invalid sequences. For instance, a naive implementation may decode the overlong UTF-8 sequence C0 80 into the character U+0000, or the surrogate pair ED A1 8C ED BE B4 into U+233B4. Decoding invalid sequences may have security consequences or cause other problems. See Security Considerations (Section 10) below. I don't think it is evident that "MUST protect against" imply "reject", though. Thanks, Simon From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 2 21:53:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22850 for ; Sat, 2 Oct 2004 21:53:21 -0400 (EDT) Received: (qmail 15156 invoked by uid 605); 3 Oct 2004 01:53:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15142 invoked from network); 3 Oct 2004 01:53:15 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 3 Oct 2004 01:53:15 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org (return-path jacobn@chiark.greenend.org.uk) id 1CDvYo-00057Y-00; Sun, 03 Oct 2004 02:53:14 +0100 Date: Sun, 3 Oct 2004 02:53:14 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Text file type hint proposal for filexfer Message-ID: <20041003015314.GA10773@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN to allow the client to request that the server open a file in text mode. However, no means is provided for the server to advise the client on whether this transfer mode is appropriate. In all cases it is likely up to the user to manually specify which mode to use. In FTP, this has tended to lead to corrupted file transfers when unintentional translation took place, etc. Some FTP implementations have performed "automatic" conversions, e.g., using heuristics based on file contents; this is not reliable, and anyway rather defeats the point of having the server translate to a known representation. The following proposal allows the server to optionally communicate this information to the client via attributes. (Since it's an attribute, the client can also manipulate it on the server as far as is specified here if it corresponds to state there.) (This proposal is against draft-ietf-secsh-filexfer-05.) To section 5 "File Attributes", 2nd para, add between `attrib-bits' and `extended_count': byte content_type present only if flag CONTENT_TYPE To section 5.1 "Flags", add: #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000400 Add new section after section 5.8 "attrib-bits": 5.x Content type The `content_type' field, if present, indicates whether the file is known to be a text file, known _not_ to be a text file, or is of unknown content. When sent from server to client, it acts as a hint to the client as to whether a file should be opened in SSH_FXF_TEXT mode. The following values are defined: #define SSH_FILEXFER_CTYPE_UNKNOWN 0 #define SSH_FILEXFER_CTYPE_BINARY 1 #define SSH_FILEXFER_CTYPE_TEXT 2 To the end of the description of SSH_FXF_TEXT in section 6.3.1 "Opening a File", add: Clients MAY decide whether to use SSH_FXF_TEXT based on a previously seen `content_type' attribute; see Section 5.x. (Of course, this could all be easily reformulated as an extension attribute if desired.) A version of filexfer-05 marked up with this proposal can be found at or . Warts with this proposal: It's unfortunate that this can't be made atomic within the existing protocol design; it requires participating clients to do a STAT or similar before OPEN. (In fact, perhaps there should be some guidance on which of STAT or LSTAT to do in this case.) I don't know whether the non-atomicity would be a problem in practice. It's perhaps tempting to use the IETF's usual content-type notation, "MIME types" (RFCs 2045-9 and related standards). However: - I don't know of any real filesystems which use it. - Consider "multipart/mixed" and friends. - Does everything in "text/*" want to be opened FXF_TEXT? - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? (Excluding composite types like multipart.) - It risks adding further to SFTP's bloat if not specified carefully. We don't want to end up accidentally requiring implementations to contain entire MIME implementations (or more likely, ill-defined subsets thereof with poor interoperability). From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 3 19:44:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27935 for ; Sun, 3 Oct 2004 19:44:21 -0400 (EDT) Received: (qmail 29787 invoked by uid 605); 3 Oct 2004 11:01:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29778 invoked from network); 3 Oct 2004 11:01:00 -0000 Received: from av11-1-sn2.hy.skanova.net (81.228.8.183) by mail.netbsd.org with SMTP; 3 Oct 2004 11:01:00 -0000 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 241953801B; Sun, 3 Oct 2004 13:00:59 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 1306637FCE for ; Sun, 3 Oct 2004 13:00:59 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 0162D37E46 for ; Sun, 3 Oct 2004 13:00:58 +0200 (CEST) Message-ID: <415FDB6E.1060702@streamsec.se> Date: Sun, 03 Oct 2004 12:58:54 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: SFTP version negotiation References: <415ACA8A.4000504@vandyke.com> <415FD603.2070009@mindrot.org> In-Reply-To: <415FD603.2070009@mindrot.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Just a thought... What happens if a SFTP server supports v3 and v4, and a client that supports v3 and v6 only connects? According to the latest draft, they are supposed to start v4, since the client will send v6 and the server supports at most v4, and v4 is the least of these two numbers. Quoted from draft 05: 4. Protocol Initialization When the file transfer protocol starts, the client first sends a SSH_FXP_INIT (including its version number) packet to the server. The server responds with a SSH_FXP_VERSION packet, supplying the lowest of its own and the client's version number. Both parties should from then on adhere to particular version of the protocol. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 3 20:20:40 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29858 for ; Sun, 3 Oct 2004 20:20:39 -0400 (EDT) Received: (qmail 23005 invoked by uid 605); 3 Oct 2004 10:54:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22994 invoked from network); 3 Oct 2004 10:53:58 -0000 Received: from chisai.mindrot.org (HELO baragon.mindrot.org) (203.217.30.86) by mail.netbsd.org with SMTP; 3 Oct 2004 10:53:57 -0000 Received: from mindrot.org (djm@localhost.mindrot.org [127.0.0.1]) by baragon.mindrot.org (8.13.1/8.13.0) with ESMTP id i93AZmcD016088; Sun, 3 Oct 2004 20:35:48 +1000 (EST) Message-ID: <415FD603.2070009@mindrot.org> Date: Sun, 03 Oct 2004 20:35:47 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20041003) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith CC: ietf-ssh@NetBSD.org Subject: Re: SFTP v5... References: <415ACA8A.4000504@vandyke.com> In-Reply-To: <415ACA8A.4000504@vandyke.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > Is anyone implementing v5 right now? > > I'm getting ready to ship an refresh, but if people have > implemented v5, I'll need to change the version. OpenSSH isn't. I definitely won't until a new version is out, hopefully resolving the open/symlink issue I mentioned in: Message-ID: <405F65BA.3020102@mindrot.org> -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 4 09:45:18 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05332 for ; Mon, 4 Oct 2004 09:45:17 -0400 (EDT) Received: (qmail 525 invoked by uid 605); 4 Oct 2004 13:45:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 508 invoked from network); 4 Oct 2004 13:45:13 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 4 Oct 2004 13:45:13 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 09:29:42 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8B6@lespaul.process.com> From: Richard Whalen To: =?iso-8859-1?Q?=27Henrick_Hellstr=F6m=27?= , ietf-ssh@NetBSD.org Subject: RE: SFTP version negotiation Date: Mon, 4 Oct 2004 09:29:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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 I think that this would be very unusual, as each new version has been a superset of protocol of the previous version. One option that the client could take would be to send an SSH_MSG_CHANNEL_CLOSE, which will close the SFTP server, then go back = to the sequence of SSH_MSG_CHANNEL_OPEN, SSH_MSG_CHANNEL_REQUEST for the = subsystem, but this time drop the version of SFTP requested to 3 in the = SSH_FXP_INIT packet. This method of negotiation may not be possible in all implementations. Another option, would be to add language to the draft specifying that = an implementation must be able to support all lower version numbers. This would require that the draft continue to include sufficient history to = allow developers to keep track of what was added in the various versions. -----Original Message----- From: Henrick Hellstr=F6m [mailto:henrick@streamsec.se] Sent: Sunday, October 03, 2004 6:59 AM To: ietf-ssh@netbsd.org Subject: SFTP version negotiation Just a thought... What happens if a SFTP server supports v3 and v4, and a client that=20 supports v3 and v6 only connects? According to the latest draft, they are supposed to start v4, since the = client will send v6 and the server supports at most v4, and v4 is the=20 least of these two numbers. Quoted from draft 05: 4. Protocol Initialization When the file transfer protocol starts, the client first sends a SSH_FXP_INIT (including its version number) packet to the server. = The server responds with a SSH_FXP_VERSION packet, supplying the lowest of its own and the client's version number. Both parties should = from then on adhere to particular version of the protocol. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 4 09:45:30 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05357 for ; Mon, 4 Oct 2004 09:45:29 -0400 (EDT) Received: (qmail 831 invoked by uid 605); 4 Oct 2004 13:45:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 612 invoked from network); 4 Oct 2004 13:45:17 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 4 Oct 2004 13:45:17 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 09:31:26 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8B7@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Text file type hint proposal for filexfer Date: Mon, 4 Oct 2004 09:31:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list As one who has argued for text transfers in the past, I support this, or an equivalent method for the server to communicate this file characteristic to the client. -----Original Message----- From: Jacob Nevins [mailto:jacobn+secsh@chiark.greenend.org.uk] Sent: Saturday, October 02, 2004 9:53 PM To: ietf-ssh@netbsd.org Subject: Text file type hint proposal for filexfer SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN to allow the client to request that the server open a file in text mode. However, no means is provided for the server to advise the client on whether this transfer mode is appropriate. In all cases it is likely up to the user to manually specify which mode to use. In FTP, this has tended to lead to corrupted file transfers when unintentional translation took place, etc. Some FTP implementations have performed "automatic" conversions, e.g., using heuristics based on file contents; this is not reliable, and anyway rather defeats the point of having the server translate to a known representation. The following proposal allows the server to optionally communicate this information to the client via attributes. (Since it's an attribute, the client can also manipulate it on the server as far as is specified here if it corresponds to state there.) (This proposal is against draft-ietf-secsh-filexfer-05.) To section 5 "File Attributes", 2nd para, add between `attrib-bits' and `extended_count': byte content_type present only if flag CONTENT_TYPE To section 5.1 "Flags", add: #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000400 Add new section after section 5.8 "attrib-bits": 5.x Content type The `content_type' field, if present, indicates whether the file is known to be a text file, known _not_ to be a text file, or is of unknown content. When sent from server to client, it acts as a hint to the client as to whether a file should be opened in SSH_FXF_TEXT mode. The following values are defined: #define SSH_FILEXFER_CTYPE_UNKNOWN 0 #define SSH_FILEXFER_CTYPE_BINARY 1 #define SSH_FILEXFER_CTYPE_TEXT 2 To the end of the description of SSH_FXF_TEXT in section 6.3.1 "Opening a File", add: Clients MAY decide whether to use SSH_FXF_TEXT based on a previously seen `content_type' attribute; see Section 5.x. (Of course, this could all be easily reformulated as an extension attribute if desired.) A version of filexfer-05 marked up with this proposal can be found at or . Warts with this proposal: It's unfortunate that this can't be made atomic within the existing protocol design; it requires participating clients to do a STAT or similar before OPEN. (In fact, perhaps there should be some guidance on which of STAT or LSTAT to do in this case.) I don't know whether the non-atomicity would be a problem in practice. It's perhaps tempting to use the IETF's usual content-type notation, "MIME types" (RFCs 2045-9 and related standards). However: - I don't know of any real filesystems which use it. - Consider "multipart/mixed" and friends. - Does everything in "text/*" want to be opened FXF_TEXT? - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? (Excluding composite types like multipart.) - It risks adding further to SFTP's bloat if not specified carefully. We don't want to end up accidentally requiring implementations to contain entire MIME implementations (or more likely, ill-defined subsets thereof with poor interoperability). From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 4 10:43:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10427 for ; Mon, 4 Oct 2004 10:43:55 -0400 (EDT) Received: (qmail 12895 invoked by uid 605); 4 Oct 2004 14:43:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12881 invoked from network); 4 Oct 2004 14:43:54 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 4 Oct 2004 14:43:53 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 241411F1541; Mon, 4 Oct 2004 16:43:52 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 3B9071F1553 for ; Mon, 4 Oct 2004 16:43:48 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i94Ehjih020596 for ; Mon, 4 Oct 2004 16:43:46 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i94EhbAN020593; Mon, 4 Oct 2004 16:43:38 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer References: <20041003015314.GA10773@chiark.greenend.org.uk> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 04 Oct 2004 16:43:31 +0200 In-Reply-To: <20041003015314.GA10773@chiark.greenend.org.uk> Message-ID: Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jacob Nevins writes: > It's perhaps tempting to use the IETF's usual content-type notation, > "MIME types" (RFCs 2045-9 and related standards). However: I think a MIME content-type makes perfect sense as an extension, but I agree it shouldn't be in the sftp spec proper. Therefore, I think it is a little confusing to use the name "CONTENT_TYPE" for the attribute you propose. Perhaps something like FILE_MODE, OPEN_MODE, FILE_TYPE might work? One other observation: If you have this attribute, *and* there is some way of knowing the server's line end convention, then it would be possible for a client to use the following strategy: Always SFTP_OPEN files in binary mode. Use FSTAT to ask the server if it's a text or binary file. Next, figure out what are the server's and the client's native line ending convention. Then convert the file as it is read. As far as I can see, this simple scheme will work just right for servers where your new attribute is fully supported (i.e it is always correct, and never returns "unknown"). It will of course always fail on servers on operating systems that * differentiate between text and binary files * doesn't provide a reliable way for an application, e.g. the sftp server, to find out if a given file name refers to a text or binary file. However, I don't see any way to get things right automatically in this case; there's no reliable information anywhere that says definitely if the file is text or binary, so it must be guessed, either by the user, or by the client or by the server. And whenever that guess is wrong, file corruption can be expected. Is this problematic case common? To me, it seems so fundamentally broken that I don't think we should work very hard to try to fix it. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 4 12:24:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19754 for ; Mon, 4 Oct 2004 12:24:20 -0400 (EDT) Received: (qmail 3126 invoked by uid 605); 4 Oct 2004 16:24:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3115 invoked from network); 4 Oct 2004 16:24:20 -0000 Received: from ams-iport-1.cisco.com (144.254.224.140) by mail.netbsd.org with SMTP; 4 Oct 2004 16:24:19 -0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2004 18:34:39 +0200 X-BrightmailFiltered: true Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i94GOFV8016708 for ; Mon, 4 Oct 2004 18:24:16 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA07314 for ietf-ssh@NetBSD.org; Mon, 4 Oct 2004 17:24:14 +0100 (BST) Date: Mon, 4 Oct 2004 17:24:12 +0100 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: How to treat utf8 text with overlong utf8 sequences? Message-ID: <20041004172412.A23297@edinburgh.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: ; from nisse@lysator.liu.se on Sat, Oct 02, 2004 at 03:18:19PM +0200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit On Sat, Oct 02, 2004 at 03:18:19PM +0200, Niels Möller wrote: > What do you think about sending overlong / "non-minimum form" utf8 > sequences in various utf8 strings in the protocol? Don't do it. > I'm tempted to treat any use of overlong or otherwise invalid utf8 > strings that I receive from the remote end as a protocol error. Agreed. > * Do you think that is a reasonable thing to do? Yes. > * Does it violate the ssh specification? No. > * Will it cause any interoperability problems in practice? No. If so, if the other end. I happe to agree with the comment that it could lead to security problems; if not immediately, then eventually, simply by the fact that the 'unexpected' form may violate some assumptions. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 4 17:36:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28008 for ; Mon, 4 Oct 2004 17:36:01 -0400 (EDT) Received: (qmail 9126 invoked by uid 605); 4 Oct 2004 21:36:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9111 invoked from network); 4 Oct 2004 21:35:59 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 4 Oct 2004 21:35:59 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org (return-path jacobn@chiark.greenend.org.uk) id 1CEaUv-0004qh-00; Mon, 04 Oct 2004 22:35:57 +0100 Date: Mon, 4 Oct 2004 22:35:57 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer Message-ID: <20041004213557.GA8750@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Thanks for the feedback. Niels Möller writes: > I think a MIME content-type makes perfect sense as an extension, but I > agree it shouldn't be in the sftp spec proper. Therefore, I think it > is a little confusing to use the name "CONTENT_TYPE" for the attribute > you propose. Perhaps something like FILE_MODE, OPEN_MODE, FILE_TYPE > might work? Fair point. How about `textmode_hint'? (Updated proposal: or .) > One other observation: > > If you have this attribute, *and* there is some way of knowing the > server's line end convention, Well, there's the rub, really. How do you do that? You can't rely on the "newline" extension being present, or if it is, corresponding with what the server will send in binary mode. Also: I'm not familiar with VMS, but the impression I have is that line breaks there are not represented by a byte sequence at all, but rather by something that it's not possible to squirt down an SFTP "binary" connection. Hence our having an explicit text mode in SFTP in the first place. My intended semantics for the flag are purely "it's a good idea to open this file in FXF_TEXT mode", not "if you open this file in binary mode you can assume a certain line ending delimiter". > then it would be possible for a client to use the following strategy: > > Always SFTP_OPEN files in binary mode. Use FSTAT to ask the server if > it's a text or binary file. Next, figure out what are the server's and > the client's native line ending convention. Then convert the file as it > is read. This proposal sounds like an entirely different approach to that supported by SFTP currently. If my understanding of the VMS issue is correct, it runs into trouble with that. Anyway, I think we've argued this one enough on this WG already, and we should stick with the current mechanism. (Are you proposing this to get round the atomicity issue I mentioned?) > As far as I can see, this simple scheme will work just right for > servers where your new attribute is fully supported (i.e it is always > correct, and never returns "unknown"). It will of course always fail > on servers on operating systems that > > * differentiate between text and binary files > > * doesn't provide a reliable way for an application, e.g. the sftp > server, to find out if a given file name refers to a text or binary > file. > > However, I don't see any way to get things right automatically in this > case; there's no reliable information anywhere that says definitely if > the file is text or binary, so it must be guessed, either by the user, > or by the client or by the server. And whenever that guess is wrong, > file corruption can be expected. Of course. I don't think there's anything the SFTP protocol can do to mitigate the latter possibility. The former (which could be said to include VMS, if my understanding's correct), we can and should support. (An SFTP server in the latter situation is of course at liberty to populate this flag by guessing based on file contents, for instance; I'd say that was a quality-of-implementation issue and outside the scope of the spec.) > Is this problematic case common? Endemic, I think; probably more the rule than the exception. No OS I use frequently has the ability to reliably distinguish text and non-text files (Unix, DOS/Windows). That shouldn't stop us providing the facility in the protocol. > To me, it seems so fundamentally broken that I don't think we should > work very hard to try to fix it. Agree that we can't magic the information out of nowhere, which is why I provide UNKNOWN. Personally, I wasn't too sure about having SFTP deal with text file semantics in the first place; but given that the WG has decided to do so (and it is a frequent feature request from users), we should provide a complete set of operations for our chosen abstraction, so that we are not the link that prevents reliable transfer of text files. Let's learn something from FTP... From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 4 20:55:50 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15457 for ; Mon, 4 Oct 2004 20:55:49 -0400 (EDT) Received: (qmail 4982 invoked by uid 605); 5 Oct 2004 00:55:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4971 invoked from network); 5 Oct 2004 00:55:47 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO liandra.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 5 Oct 2004 00:55:47 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa04993; 4 Oct 2004 16:25 EDT Date: Mon, 04 Oct 2004 16:25:01 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Damien Miller cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Message-ID: <42430000.1096921501@liandra.pc.cs.cmu.edu> In-Reply-To: References: <415BB4A1.1040102@mindrot.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Friday, October 01, 2004 12:33:09 +0200 Niels M=F6ller=20 wrote: > Damien Miller writes: > >> This isn't entirely true: you can specify "method1,method2,method3" and >> sshd will allow authentication using method3 if the method1 and method2 >> don't exist. >> >> I'm not sure what you would have us do: kbdint doesn't seem to provide a >> way for a server to report supported methods to a client and I don't >> think it is correct to just ignore what a client has specified and >> continue with a random method that the server picks. > > I think the following three steps would improve the situation: > > 1. Require the names listed in the submethods field to be proper ssh > names. I.e. standardized names without @, local/vendor stuff with > @domain attached. Encourage documentation of the @domain things > that implementations support. Good. > 2. Allow the server to use methods not on the client's list, in case > none of the listed methods is implemented or configured for use by > the server. (For methods that are implemented and acceptable for > the server, the server should respect the client preferences). Hrm. I guess I'd prefer to do this only when the client sends an empty=20 list, indicating "any method is OK". This is particularly useful if the=20 client wants to mix other methods in with the kbd-interactive ones in its=20 list of things to try. For example, the client might want to try=20 mechanisms in this order: external-gssapi gssapi-with-mic/kerberos kbd-interactive/challenge-response-token public-key(*) kbd-interactive/one-time-password kbd-interactive/pam password (*) The key pair actually resides on a smart card, and we want to try the=20 token they can look at before the one they have to insert into the machine. > 3. Use the name field in the SSH_MSG_USERAUTH_INFO_REQUEST (or > introduce a new field, if the "name" field is intended for the UI) > to tell the client which method the server has selected. This way, > the client can know if the server is about to ignore its submethods > preferences, and can abort the keyboard-interactive if it so > wishes. Good. I agree the approach you describe would improve the situation. It is=20 entirely possible that a PAM-based implementation will not in reality be=20 able to tell what the backend is really doing or assign different method=20 names to different backend modules. This is particularly complex as it may = be the case that multiple modules will be used in the same conversation,=20 and it is sometimes fuzzy where the line is (for example, a module may use=20 a password answer collected by a previous module). IMHO the solution to this would be for PAM-based implementations to use a=20 single submethod name to refer to the whole PAM mess. That way, the server = can say to the client "I'm using PAM, but I can't tell you more than that". In addition to the changes you propose, I think further improvement can be=20 had by providing a mechanism by which the client can request from the=20 server a list of supported submethods. This is necessary if the client=20 wants the user to select which methods should be tried and in which order. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 07:47:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18098 for ; Tue, 5 Oct 2004 07:47:31 -0400 (EDT) Received: (qmail 27838 invoked by uid 605); 5 Oct 2004 11:47:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27767 invoked from network); 5 Oct 2004 11:47:18 -0000 Received: from av7-2-sn3.vrr.skanova.net (81.228.9.182) by mail.netbsd.org with SMTP; 5 Oct 2004 11:47:18 -0000 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id D240F3829F; Tue, 5 Oct 2004 14:07:03 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id BDC7338063 for ; Tue, 5 Oct 2004 14:07:03 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4984F37E42 for ; Tue, 5 Oct 2004 13:25:00 +0200 (CEST) Message-ID: <416284B1.50608@streamsec.se> Date: Tue, 05 Oct 2004 13:25:37 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <63D30D6E10CFD11190A90000F805FE86051AC8B6@lespaul.process.com> In-Reply-To: <63D30D6E10CFD11190A90000F805FE86051AC8B6@lespaul.process.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Richard Whalen wrote: > I think that this would be very unusual, as each new version has been a > superset of protocol of the previous version. Nope. For instance, version 3 and version 5 are incompatible, since they use different status response formats and different attribute structs. > One option that the client could take would be to send an > SSH_MSG_CHANNEL_CLOSE, which will close the SFTP server, then go back to the > sequence of SSH_MSG_CHANNEL_OPEN, SSH_MSG_CHANNEL_REQUEST for the subsystem, > but this time drop the version of SFTP requested to 3 in the SSH_FXP_INIT > packet. This method of negotiation may not be possible in all > implementations. It is at least consistent with the specification, and appears to be the way to go. I was mostly interested in (a) if there was a "better" way that didn't require the SFTP sub system to be closed and re-opened, plus (b) why this version negotiation mechanism was selected to begin with, and not e.g. one in which the client would send a list of each supported version (which is more or less how the rest of SSH works). > Another option, would be to add language to the draft specifying that an > implementation must be able to support all lower version numbers. This > would require that the draft continue to include sufficient history to allow > developers to keep track of what was added in the various versions. This might not be the options. Consider, for example, the possibility that an addition to the SFTP protocol made in one version turns out to introduce a security flaw that is later fixed in the next version. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 10:49:40 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04934 for ; Tue, 5 Oct 2004 10:49:39 -0400 (EDT) Received: (qmail 15182 invoked by uid 605); 5 Oct 2004 13:37:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15168 invoked from network); 5 Oct 2004 13:37:02 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Oct 2004 13:37:02 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 09:36:17 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8BB@lespaul.process.com> From: Richard Whalen To: "'nisse@lysator.liu.se'" , Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: RE: Text file type hint proposal for filexfer Date: Tue, 5 Oct 2004 09:36:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list Yes, it is possible for a VMS application to reliably report on whether or not a given file is a text file or not. This information is stored in the file header (inode in Unix speak). Our current SFTP implementation uses the file header information to do on the fly conversion of the various VMS text file formats to a stream of characters format when transferring text file to a non-VMS system. This conversion is controlled by an environment variable, so it can be disabled, though the environment variable can not be set from within the SFTP session. The down side of the on the fly conversion is that we can only provide an estimate of the file size for many of the formats. -------------- Richard Whalen > -----Original Message----- > From: nisse@lysator.liu.se [mailto:nisse@lysator.liu.se] > Sent: Tuesday, October 05, 2004 9:19 AM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: Re: Text file type hint proposal for filexfer > > > Richard Whalen writes: > > > Your impression is correct. Many text files on VMS do not > store the line > > break sequence. > > Is it possible for a VMS application (in particular, an sftp server on > VMS), to reliably figure out wether or not given file is a "text file" > using this record format, or a binary file (whatever that means on > VMS)? > > That is, can the proposed file mode hint be reliably supported on VMS? > > /Niels > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 11:20:19 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07087 for ; Tue, 5 Oct 2004 11:20:19 -0400 (EDT) Received: (qmail 28558 invoked by uid 605); 5 Oct 2004 15:20:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28507 invoked from network); 5 Oct 2004 15:20:14 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 15:20:14 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6689508; Tue, 05 Oct 2004 09:20:12 -0600 Message-ID: <4162BBAC.3070306@vandyke.com> Date: Tue, 05 Oct 2004 09:20:12 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= CC: ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <415ACA8A.4000504@vandyke.com> <415FD603.2070009@mindrot.org> <415FDB6E.1060702@streamsec.se> In-Reply-To: <415FDB6E.1060702@streamsec.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Henrick Hellström wrote: > Just a thought... > > What happens if a SFTP server supports v3 and v4, and a client that > supports v3 and v6 only connects? > > According to the latest draft, they are supposed to start v4, since the > client will send v6 and the server supports at most v4, and v4 is the > least of these two numbers. > > Quoted from draft 05: > > 4. Protocol Initialization > > When the file transfer protocol starts, the client first sends a > SSH_FXP_INIT (including its version number) packet to the server. The > server responds with a SSH_FXP_VERSION packet, supplying the lowest > of its own and the client's version number. Both parties should from > then on adhere to particular version of the protocol. This has been a concern of mine for a while. The best solution I've been able to come up with (better than closing channel, I think) is this: > If the client supports non-contigous version, for example, > versions 2,3, and 6, then the INIT/VERSION negotiation > is insufficient. In order to gaurentee a successful > connection, the MUST send the highest version for which > it supports all previos version (because the server > might pick the version the client sends or any > previous version.) > > However, in order to work around this limit in the > deployed protocol implementations, after the > INIT/VERSION exchange is complete, if the version > negotiated is at least 3, the version where extensions was > introduced, the client MAY send the following extension > to attempt to negotiate a higher version: > > byte SSH_FXP_EXTENDED > uint32 request-id > string "version-negotiate" > uint32 highest version-supported > uint32 2nd highest version-supported > ... > uint32 lowest version-supported > > The client must not send any other packets after sending > this extension until it recieves the response. The server > responds with a similar response: > > The server then responds with: > > byte SSH_FXP_EXTENDED_REPLY > uint32 request-id > uint32 highest version-supported > uint32 2nd highest version-supported > ... > uint32 lowest version-supported > > The new negotiated version to use is the > first value that appears on both list, or, > in other words, the highest version supported > by both the client and the server. This > version MUST be at least as high as the > previous negotiated version. > > The next packet sent after the "version-negotiate" > request by the client, and the next packet sent > by the server after the reply will conform to > the new version. > > The server includes it's entire list of supported > versions rather than just the negotiated version > in order to assist in trouble shooting on the > client side. I believe this mechanism maintains backwards compatibility and gives us the version exchange we now wish we'd had originally :-) Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 11:31:57 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07875 for ; Tue, 5 Oct 2004 11:31:56 -0400 (EDT) Received: (qmail 9956 invoked by uid 605); 5 Oct 2004 12:45:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9945 invoked from network); 5 Oct 2004 12:45:15 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Oct 2004 12:45:15 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 5B93014E99F; Tue, 5 Oct 2004 14:42:27 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 2DAF2D282C for ; Tue, 5 Oct 2004 14:42:16 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i95CgFih005065 for ; Tue, 5 Oct 2004 14:42:15 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i95Cg8jL005062; Tue, 5 Oct 2004 14:42:08 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@NetBSD.org Subject: Re: How to treat utf8 text with overlong utf8 sequences? References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 05 Oct 2004 14:42:07 +0200 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,TW_XB autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I wrote: > What do you think about sending overlong / "non-minimum form" utf8 > sequences in various utf8 strings in the protocol? Thanks to all those who answered (Simon, Simon and Derek). Unicode-3.0 (the version I have on paper) is a little vague, decoders are appearantly expected to decode overlong utf8 sequences, although implementations are not allowed to generate them. Unicode-3.2 is more explicit, see http://www.unicode.org/reports/tr28/, in particular "Table 3.1B. Legal UTF-8 Byte Sequences". This table explicitly excludes overlong utf8 sequences, and utf8-encodings of unicode/utf16 surrogate characters. So it seems fairly safe to treat use of such utf8 sequences as protocol errors in ssh. Also RFC 3629 spells this out quite clearly. Neither the table in tr28 nor RFC 3629 explicitly forbids the unicode "non-characters" ufffe and uffff, and the corresponding utf8 sequences (0xef 0xbf 0xbe) and (0xef 0xbf 0xbf), but in the ssh context, I think it makes sense to treat them too as protocol errors. I hope we don't need to clarify this explicitly in the ssh specification, as its a general utf8 issue. However, I think we should update our utf-8 references to refer to RFC 3629. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 11:32:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07968 for ; Tue, 5 Oct 2004 11:32:28 -0400 (EDT) Received: (qmail 9909 invoked by uid 605); 5 Oct 2004 15:32:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9626 invoked from network); 5 Oct 2004 15:32:16 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Oct 2004 15:32:16 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 16F571E0D63; Tue, 5 Oct 2004 17:32:07 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 02E53198715; Tue, 5 Oct 2004 17:32:03 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i95FW2ih007025; Tue, 5 Oct 2004 17:32:02 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i95FVtix007021; Tue, 5 Oct 2004 17:31:55 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Text file type hint proposal for filexfer References: <63D30D6E10CFD11190A90000F805FE86051AC8BB@lespaul.process.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 05 Oct 2004 17:31:54 +0200 In-Reply-To: <63D30D6E10CFD11190A90000F805FE86051AC8BB@lespaul.process.com> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Richard Whalen writes: > Yes, it is possible for a VMS application to reliably report on whether > or not a given file is a text file or not. This information is stored > in the file header (inode in Unix speak). Nice. > Our current SFTP implementation uses the file header information to do > on the fly conversion of the various VMS text file formats to a stream > of characters format when transferring text file to a non-VMS > system. Out of curiosity, what happens if the sftp client tries to open these files in binary mode? /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 11:34:40 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08136 for ; Tue, 5 Oct 2004 11:34:40 -0400 (EDT) Received: (qmail 4896 invoked by uid 605); 5 Oct 2004 13:19:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4886 invoked from network); 5 Oct 2004 13:19:38 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Oct 2004 13:19:38 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 7573017BB13; Tue, 5 Oct 2004 15:19:37 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 817E516FC9B; Tue, 5 Oct 2004 15:19:33 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i95DJWih005464; Tue, 5 Oct 2004 15:19:32 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i95DJP7M005461; Tue, 5 Oct 2004 15:19:25 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Text file type hint proposal for filexfer References: <63D30D6E10CFD11190A90000F805FE86051AC8BA@lespaul.process.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 05 Oct 2004 15:19:24 +0200 In-Reply-To: <63D30D6E10CFD11190A90000F805FE86051AC8BA@lespaul.process.com> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Richard Whalen writes: > Your impression is correct. Many text files on VMS do not store the line > break sequence. Is it possible for a VMS application (in particular, an sftp server on VMS), to reliably figure out wether or not given file is a "text file" using this record format, or a binary file (whatever that means on VMS)? That is, can the proposed file mode hint be reliably supported on VMS? /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 11:35:09 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08208 for ; Tue, 5 Oct 2004 11:35:09 -0400 (EDT) Received: (qmail 3453 invoked by uid 605); 5 Oct 2004 13:17:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3205 invoked from network); 5 Oct 2004 13:17:02 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 5 Oct 2004 13:17:02 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id E9CD9433FB; Tue, 5 Oct 2004 14:59:43 +0200 (CEST) Message-ID: <41629DE4.9010608@siliconcircus.com> Date: Tue, 05 Oct 2004 15:13:08 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@NetBSD.org Subject: Re: How to treat utf8 text with overlong utf8 sequences? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > > I hope we don't need to clarify this explicitly in the ssh > specification, as its a general utf8 issue. However, I think we should > update our utf-8 references to refer to RFC 3629. Mentioning this issue in the Security Considerations section would seem like a good idea, though I agree that nothing further is necessary. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 11:47:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09011 for ; Tue, 5 Oct 2004 11:47:13 -0400 (EDT) Received: (qmail 9084 invoked by uid 605); 5 Oct 2004 12:43:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9070 invoked from network); 5 Oct 2004 12:43:27 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Oct 2004 12:43:26 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 08:43:26 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8BA@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Text file type hint proposal for filexfer Date: Tue, 5 Oct 2004 08:43:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list > From: Jacob Nevins [mailto:jacobn+secsh@chiark.greenend.org.uk] > Sent: Monday, October 04, 2004 5:36 PM > To: ietf-ssh@netbsd.org > Subject: Re: Text file type hint proposal for filexfer > > > > One other observation: > > > > If you have this attribute, *and* there is some way of knowing the > > server's line end convention, > > Well, there's the rub, really. How do you do that? You can't > rely on the > "newline" extension being present, or if it is, corresponding > with what > the server will send in binary mode. > > Also: I'm not familiar with VMS, but the impression I have is > that line > breaks there are not represented by a byte sequence at all, but rather > by something that it's not possible to squirt down an SFTP "binary" > connection. Hence our having an explicit text mode in SFTP in > the first > place. Your impression is correct. Many text files on VMS do not store the line break sequence. Files created with a text editor are often stored as records with a 2 byte count at the start of each record and file attributes that state that a carriage-return, linefeed sequence will follow each line when it is displayed on a terminal or printed. It is also possible for VMS to store a text file as a stream of bytes (equivalent to the way that Unix does), with a more complex record structure that includes carriage control with each record, or as fixed length records in which no carriage control characters are stored as they can be inferred by the file organization. This is the basis behind the argument for requesting the server to open a file in text mode and present it in a canonical way as has been done with FTP. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 11:52:16 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09360 for ; Tue, 5 Oct 2004 11:52:15 -0400 (EDT) Received: (qmail 27233 invoked by uid 605); 5 Oct 2004 15:52:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27116 invoked from network); 5 Oct 2004 15:52:06 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Oct 2004 15:52:06 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id E3BF111FE8F; Tue, 5 Oct 2004 17:48:26 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 8010F118175; Tue, 5 Oct 2004 17:48:22 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i95FmJih007200; Tue, 5 Oct 2004 17:48:21 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i95FmDHi007197; Tue, 5 Oct 2004 17:48:13 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: =?iso-8859-1?q?Henrick_Hellstr=F6m?= Cc: ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <63D30D6E10CFD11190A90000F805FE86051AC8B6@lespaul.process.com> <416284B1.50608@streamsec.se> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 05 Oct 2004 17:48:13 +0200 In-Reply-To: <416284B1.50608@streamsec.se> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Henrick Hellström writes: > I was mostly interested in (a) if there was a "better" way that didn't > require the SFTP sub system to be closed and re-opened, plus (b) why > this version negotiation mechanism was selected to begin with, and not As for b), my guess is that it was expected that 1. version updates would mostly be backwards compatible, and that 2. the number of versions in use at any given time would be small, typically one old version and one newer. I think these are reasonable assumptions, once the sftp spec matures. > e.g. one in which the client would send a list of each supported > version (which is more or less how the rest of SSH works). The ssh version exchange (section 4.2 of the transport draft) does't work the way you describe. To me, it makes a lot of sense to treat version exchange and algorithm negotiation (which I suspect is what you're referring to) quite differently. I don't think it is motivated to introduce any more complex version negotiation at this time. If I were to read a protocol specification with two different version negotiation mechanism in it, my immediate reaction would be that the spec must be a bloated comittee product. Let's keep things simple. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 12:54:45 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14057 for ; Tue, 5 Oct 2004 12:54:45 -0400 (EDT) Received: (qmail 8902 invoked by uid 605); 5 Oct 2004 16:54:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8547 invoked from network); 5 Oct 2004 16:54:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 16:54:36 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6689714; Tue, 05 Oct 2004 10:23:43 -0600 Message-ID: <4162CA8F.1020602@vandyke.com> Date: Tue, 05 Oct 2004 10:23:43 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-filexfer-05.txt References: <405F086A.80101@klomp.org> <405F2E5F.5090501@vandyke.com> <405F65BA.3020102@mindrot.org> In-Reply-To: <405F65BA.3020102@mindrot.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller wrote: > Another comment/query on the filexfer draft: > > I think that SSH_FXP_OPEN should support a flag to stop it from > following symlinks, like O_NOFOLLOW on some Unices. > > Without something like this, I believe that SSH_FXP_FSTAT isn't very > useful as a race-free means to collect attributes. One could end up > following a symlink unless one checks it first - which opens another race. > > Even using the hypothetical nofollow isn't entirely race-free, but it > enables a server to not chase symlinks (e.g. to /dev/st0) if it doesn't > want to. If no one else has any thoughts or objections to this, I will add it to the draft as follows: New flag to open command: SSH_FXF_NOFOLLOW = 0x00000200 SSH_FXF_NOFOLLOW If the final component of the path is a symlink, the link file itself should be opened instead of the the target. What should the behavior be if a symlink file is opened and then read or written to? Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 12:54:56 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14084 for ; Tue, 5 Oct 2004 12:54:56 -0400 (EDT) Received: (qmail 8974 invoked by uid 605); 5 Oct 2004 16:54:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8568 invoked from network); 5 Oct 2004 16:54:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 16:54:36 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6689713; Tue, 05 Oct 2004 10:33:13 -0600 Message-ID: <4162CCC9.8040806@vandyke.com> Date: Tue, 05 Oct 2004 10:33:13 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= , ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <63D30D6E10CFD11190A90000F805FE86051AC8B6@lespaul.process.com> <416284B1.50608@streamsec.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Henrick Hellström writes: > > >>I was mostly interested in (a) if there was a "better" way that didn't >>require the SFTP sub system to be closed and re-opened, plus (b) why >>this version negotiation mechanism was selected to begin with, and not > > > As for b), my guess is that it was expected that > > 1. version updates would mostly be backwards compatible, and that > > 2. the number of versions in use at any given time would be small, > typically one old version and one newer. > > I think these are reasonable assumptions, once the sftp spec matures. > > > >>e.g. one in which the client would send a list of each supported >>version (which is more or less how the rest of SSH works). > > > The ssh version exchange (section 4.2 of the transport draft) does't > work the way you describe. To me, it makes a lot of sense to treat > version exchange and algorithm negotiation (which I suspect is what > you're referring to) quite differently. > > I don't think it is motivated to introduce any more complex version > negotiation at this time. If I were to read a protocol specification > with two different version negotiation mechanism in it, my immediate > reaction would be that the spec must be a bloated comittee product. > > Let's keep things simple. On the other hand, I was thinking we might have more people adopt the next version if they didn't have to support version 4 and 5 in addition to 6. And since documents describing version 4 and 5 are not longer available (at least from IETF) and I don't want to drag cruft documenting older version in the current version of the draft, it seems prudent to allow people to skip a version while implementing. This unfortunate situation is mostly my fault... because it has taken so long to finish the spec, we have implementations that are well entrenched at version 3. Unfortunately, I'm afraid that the two different version negotiations is the sign of a protocol specification period that has lasted too long. I think it will be simplier in the long run to have the double version negotiation than to have popular servers/clients that never move off of version 3 because version 4 & 5 specifications aren't available, and they can't maintain backwards compatibility without those specs. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 12:55:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14128 for ; Tue, 5 Oct 2004 12:55:13 -0400 (EDT) Received: (qmail 9101 invoked by uid 605); 5 Oct 2004 16:54:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8619 invoked from network); 5 Oct 2004 16:54:37 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 16:54:37 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6689779 for ietf-ssh@netbsd.org; Tue, 05 Oct 2004 10:48:02 -0600 Message-ID: <4162D042.3010305@vandyke.com> Date: Tue, 05 Oct 2004 10:48:02 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: SFTP and unicode file names... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Okay, I've been forced to face up to the unfortunate truth: Unix directories can contain files encoded in multiple different char-sets and the server has no way to tell what these multiple char-sets are and translate them to UTF-8. Because the transformation is one way, once the server has mistranslated the filename, there is no way for the client to get back to the original data. So, for these file-systems, the best possible thing to do is send the filename raw and let the client (with help from the user decode it.) On the other hand, maximum possible interoperability between different language and regions is obtained through use of UTF-8 where available. I haven't been able to come up with a solution I really like. Here are some possibilities: 1. Let the server say what it is going to use, UTF-8 or 'undefined-raw' at the beginning of the sftp session. pro: simple. really simple. con: Doesn't address cases where the server might be able to do utf-8 for some file systems (ext-3 under fedora, I think is one example) but not others. 2. Allow the filename to be prefixed by a flag byte saying it is raw. For example, the byte 0xFF is an invalid UTF-8 lead byte. If the first byte of the filename is 0xFF, then the 0xFF is discarded, and the rest of string is the 'raw, undefined' filename data. pro: It handles the real life complexity of being able to tell sometimes, but not others. con: It is a little more complex, and a bit icky. 3. Give the filename structure. Filenames are always specified in the following structure: uint32 length of the structure boolean utf-8 byte filename[length-1] pro: This also handles being able to give UTF-8 sometimes, but not all the time. pro: This isn't icky. con: This is a bit more complex. 4. Use the high order bit of the length field to flag raw more. In practice, no file name will ever be more than 2 gig long :-) We can safely borrow that bit for other purposes. pro: This also handles being able to give UTF-8 sometimes, but not all the time. con: Slightly icky, a little more complex. Can anyone think of a better solution? I think I prefer solution three, I could live with 2 or 4; I'd really rather not go with 1. What do others think? Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 13:11:34 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16405 for ; Tue, 5 Oct 2004 13:11:33 -0400 (EDT) Received: (qmail 20778 invoked by uid 605); 5 Oct 2004 17:11:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20743 invoked from network); 5 Oct 2004 17:11:32 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 17:11:32 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6689861 for ietf-ssh@netbsd.org; Tue, 05 Oct 2004 11:11:31 -0600 Message-ID: <4162D5C4.2040103@vandyke.com> Date: Tue, 05 Oct 2004 11:11:32 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Have you got a pet peeve with the sftp draft? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit (Other than the fact that you can't find on the ietf site because it is expired and it isn't done.) Now is the time to speak up and raise your issue. Next week will be to late :-) Or at least I hope it will. Once again, I'm trying to publish ASAP. I hope to post a preliminary copy tomorrow or thrusday, so lets get your issues resolved. Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 13:31:20 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18515 for ; Tue, 5 Oct 2004 13:31:20 -0400 (EDT) Received: (qmail 7841 invoked by uid 605); 5 Oct 2004 17:31:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7820 invoked from network); 5 Oct 2004 17:31:16 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Oct 2004 17:31:16 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 19DA91E3150; Tue, 5 Oct 2004 19:31:15 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 82E481D8C5D; Tue, 5 Oct 2004 19:31:10 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i95HV6ih012209; Tue, 5 Oct 2004 19:31:06 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i95HUveO012189; Tue, 5 Oct 2004 19:30:57 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@sun.com Cc: ietf-ssh@NetBSD.org Subject: What's the conclusion of the Straw Poll on group name? References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 05 Oct 2004 19:30:49 +0200 In-Reply-To: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > At the end of this message, you'll find a summary from Tero Kivinen of > the usage by other protocols of the common MODP groups on the saag > list; I think it conclusively demonstrates that every user of the MODP > groups is doing something different. > > That only leaves > > straw poll: > [A] we should use small integers to refer to common groups > [sample] diffie-hellman-group2-sha1 > > [B] we should refer to groups by size: > [sample] diffie-hellman-group2048-sha1 > > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 > > In your response to the poll, please: > a) explain the one you prefer and why. > b) list any options you find unacceptable and explain why. > > I'll use this to gauge consensus. This poll was initiated August 26. There were nine answers, quite different. Bill, what is your conclusion? I'd like to see this question properly resolved. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 13:33:06 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18611 for ; Tue, 5 Oct 2004 13:33:06 -0400 (EDT) Received: (qmail 8959 invoked by uid 605); 5 Oct 2004 17:33:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8949 invoked from network); 5 Oct 2004 17:33:06 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Oct 2004 17:33:06 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 13:33:05 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8BD@lespaul.process.com> From: Richard Whalen To: "'nisse@lysator.liu.se'" , Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: RE: Text file type hint proposal for filexfer Date: Tue, 5 Oct 2004 13:33:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list If the conversion is being performed, then the file can not be opened in binary mode, as a request to open a file for read access that does not specify text mode will automatically be checked to see if it can be converted. Which files are converted is controlled by an environment variable that can be set on the server (outside of the SFTP server), or set by the client with an SSH_FXP_EXTENDED command with a command name of TRANSLATE_VMS@PROCESS.COM and an integer parameter that is a bit mask of the types files to be converted. 0 (zero) is none. Bit 0 (little endian) is fixed length files, bit 1 is variable length record files, and bit 2 is files with variable length records and fixed carriage control information. Legal values are between 0 and 7. Richard Whalen -----Original Message----- From: nisse@lysator.liu.se [mailto:nisse@lysator.liu.se] Sent: Tuesday, October 05, 2004 11:32 AM To: Richard Whalen Cc: 'ietf-ssh@netbsd.org' Subject: Re: Text file type hint proposal for filexfer > Our current SFTP implementation uses the file header information to do > on the fly conversion of the various VMS text file formats to a stream > of characters format when transferring text file to a non-VMS > system. Out of curiosity, what happens if the sftp client tries to open these files in binary mode? /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 15:12:20 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27503 for ; Tue, 5 Oct 2004 15:12:20 -0400 (EDT) Received: (qmail 14856 invoked by uid 605); 5 Oct 2004 19:12:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14845 invoked from network); 5 Oct 2004 19:12:18 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Oct 2004 19:12:18 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 1F30A19576B; Tue, 5 Oct 2004 21:12:17 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 32C005E595; Tue, 5 Oct 2004 21:12:15 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i95JCEih003019; Tue, 5 Oct 2004 21:12:14 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i95JCAA5003013; Tue, 5 Oct 2004 21:12:10 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: =?iso-8859-1?q?Henrick_Hellstr=F6m?= , ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <63D30D6E10CFD11190A90000F805FE86051AC8B6@lespaul.process.com> <416284B1.50608@streamsec.se> <4162CCC9.8040806@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 05 Oct 2004 21:12:02 +0200 In-Reply-To: <4162CCC9.8040806@vandyke.com> Message-ID: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > This unfortunate situation is mostly my fault... because > it has taken so long to finish the spec, we have > implementations that are well entrenched at version 3. The situation is somewhat unfortunate, but I do *not* think we have a sufficient motivation for introducing a new version negotiating mechanism in the spec. Implementations that want to support version 3 and 6, but no version in between, can do that in several ways; an explicit command line option, or the "try version 6, if the server supports only 4 or five, disconnect and try again with 3". That's a little kludgy, true. But if we have to choose between 1. Kludges in the implementations, which will live only until version 6 is sufficiently widespread that version 3 support can be dropped (I think all serious sftp implementations should get version 6 support within a year, or at most, say, three years), 2. Kludges in the spec, which will live forever and affect every implementation that is ever written, I'll choose 1 every time. Please. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 15:21:03 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28709 for ; Tue, 5 Oct 2004 15:21:02 -0400 (EDT) Received: (qmail 20798 invoked by uid 605); 5 Oct 2004 19:21:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20786 invoked from network); 5 Oct 2004 19:21:00 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 19:20:59 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6690232 for ietf-ssh@netbsd.org; Tue, 05 Oct 2004 13:20:58 -0600 Message-ID: <4162F41B.5060900@vandyke.com> Date: Tue, 05 Oct 2004 13:20:59 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer References: <20041003015314.GA10773@chiark.greenend.org.uk> In-Reply-To: <20041003015314.GA10773@chiark.greenend.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit How about this alternative-- sftpv5 has (and naturally v6 will have) an 'attrib-bits' field in the attrib structure which describes various bit attributes, such as case-sensitivity, if the file is encrypted on disk, compressed on disk, advisory readonly, a hidden file, a system file, etc. What if we add two bits there: #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT 0x00000800 The server is reasonably certain that the file contains textual data, and therefore the file should be opened in text mode. This flag MUST NOT be present during a setstat operation. If this flag is present during an fsetstat operation, the file handle is converted to a text-mode handle, as if it had been opened with SSH_FXF_ACCESS_TEXT_MODE. The server MUST NOT set this bit unless it is reasonably certain the file should be transfered in text-mode because many clients will use this flag to initiate automatic text-mode translation. If the server sets this flag in error, data corruption will result. #define SSH_FILEXFER_ATTR_FLAGS_BIN_HINT 0x00001000 The server is reasonably certain that the file contents are binary and should not be opened with SSH_FXF_ACCESS_TEXT_MODE. This gets around your atomicity issue (I think.) The client can open sans SSH_FXF_ACCESS_TEXT_MODE, do an fstat, and then, if the server comes back with SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT in the attrib.attrib-bits, it can do a fsetstat to put the handle into text mode. mime types have come up enough times that I think I'm going to add a field for them; anybody that doesn't want shouldn't need to implement them though. (I know of at least one filesystem that does know the mime-type information though.) - Joseph Jacob Nevins wrote: > SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN > to allow the client to request that the server open a file in text > mode. > > However, no means is provided for the server to advise the client on > whether this transfer mode is appropriate. In all cases it is likely > up to the user to manually specify which mode to use. > > In FTP, this has tended to lead to corrupted file transfers when > unintentional translation took place, etc. Some FTP implementations > have performed "automatic" conversions, e.g., using heuristics based > on file contents; this is not reliable, and anyway rather defeats the > point of having the server translate to a known representation. > > The following proposal allows the server to optionally communicate > this information to the client via attributes. (Since it's an > attribute, the client can also manipulate it on the server as far as > is specified here if it corresponds to state there.) > > (This proposal is against draft-ietf-secsh-filexfer-05.) > > To section 5 "File Attributes", 2nd para, add between `attrib-bits' and > `extended_count': > > byte content_type present only if flag CONTENT_TYPE > > To section 5.1 "Flags", add: > > #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000400 > > Add new section after section 5.8 "attrib-bits": > > 5.x Content type > > The `content_type' field, if present, indicates whether the file is > known to be a text file, known _not_ to be a text file, or is of > unknown content. When sent from server to client, it acts as a > hint to the client as to whether a file should be opened in > SSH_FXF_TEXT mode. The following values are defined: > > #define SSH_FILEXFER_CTYPE_UNKNOWN 0 > #define SSH_FILEXFER_CTYPE_BINARY 1 > #define SSH_FILEXFER_CTYPE_TEXT 2 > > To the end of the description of SSH_FXF_TEXT in section 6.3.1 > "Opening a File", add: > > Clients MAY decide whether to use SSH_FXF_TEXT based on a > previously seen `content_type' attribute; see Section 5.x. > > (Of course, this could all be easily reformulated as an extension > attribute if desired.) > > A version of filexfer-05 marked up with this proposal can be found at > > or . > > Warts with this proposal: > > It's unfortunate that this can't be made atomic within the existing > protocol design; it requires participating clients to do a STAT or > similar before OPEN. > (In fact, perhaps there should be some guidance on which of STAT or > LSTAT to do in this case.) > I don't know whether the non-atomicity would be a problem in practice. > > It's perhaps tempting to use the IETF's usual content-type notation, > "MIME types" (RFCs 2045-9 and related standards). However: > - I don't know of any real filesystems which use it. > - Consider "multipart/mixed" and friends. > - Does everything in "text/*" want to be opened FXF_TEXT? > - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? > (Excluding composite types like multipart.) > - It risks adding further to SFTP's bloat if not specified carefully. > We don't want to end up accidentally requiring implementations to > contain entire MIME implementations (or more likely, ill-defined > subsets thereof with poor interoperability). > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 15:43:05 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01130 for ; Tue, 5 Oct 2004 15:43:04 -0400 (EDT) Received: (qmail 5687 invoked by uid 605); 5 Oct 2004 19:43:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5678 invoked from network); 5 Oct 2004 19:43:01 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Oct 2004 19:43:01 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 15:43:00 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8C2@lespaul.process.com> From: Richard Whalen To: ietf-ssh@NetBSD.org Subject: RE: Text file type hint proposal for filexfer Date: Tue, 5 Oct 2004 15:42:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list I don't think that this scheme will work for VMS. Though we can report on the format of the file, the idea of opening it in an unspecified mode, then specifying that you really want text mode may not be possible without sacrificing the atomicity that some want. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Tuesday, October 05, 2004 3:21 PM To: ietf-ssh@netbsd.org Subject: Re: Text file type hint proposal for filexfer How about this alternative-- sftpv5 has (and naturally v6 will have) an 'attrib-bits' field in the attrib structure which describes various bit attributes, such as case-sensitivity, if the file is encrypted on disk, compressed on disk, advisory readonly, a hidden file, a system file, etc. What if we add two bits there: #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT 0x00000800 The server is reasonably certain that the file contains textual data, and therefore the file should be opened in text mode. This flag MUST NOT be present during a setstat operation. If this flag is present during an fsetstat operation, the file handle is converted to a text-mode handle, as if it had been opened with SSH_FXF_ACCESS_TEXT_MODE. The server MUST NOT set this bit unless it is reasonably certain the file should be transfered in text-mode because many clients will use this flag to initiate automatic text-mode translation. If the server sets this flag in error, data corruption will result. #define SSH_FILEXFER_ATTR_FLAGS_BIN_HINT 0x00001000 The server is reasonably certain that the file contents are binary and should not be opened with SSH_FXF_ACCESS_TEXT_MODE. This gets around your atomicity issue (I think.) The client can open sans SSH_FXF_ACCESS_TEXT_MODE, do an fstat, and then, if the server comes back with SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT in the attrib.attrib-bits, it can do a fsetstat to put the handle into text mode. mime types have come up enough times that I think I'm going to add a field for them; anybody that doesn't want shouldn't need to implement them though. (I know of at least one filesystem that does know the mime-type information though.) - Joseph Jacob Nevins wrote: > SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN > to allow the client to request that the server open a file in text > mode. > > However, no means is provided for the server to advise the client on > whether this transfer mode is appropriate. In all cases it is likely > up to the user to manually specify which mode to use. > > In FTP, this has tended to lead to corrupted file transfers when > unintentional translation took place, etc. Some FTP implementations > have performed "automatic" conversions, e.g., using heuristics based > on file contents; this is not reliable, and anyway rather defeats the > point of having the server translate to a known representation. > > The following proposal allows the server to optionally communicate > this information to the client via attributes. (Since it's an > attribute, the client can also manipulate it on the server as far as > is specified here if it corresponds to state there.) > > (This proposal is against draft-ietf-secsh-filexfer-05.) > > To section 5 "File Attributes", 2nd para, add between `attrib-bits' and > `extended_count': > > byte content_type present only if flag CONTENT_TYPE > > To section 5.1 "Flags", add: > > #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000400 > > Add new section after section 5.8 "attrib-bits": > > 5.x Content type > > The `content_type' field, if present, indicates whether the file is > known to be a text file, known _not_ to be a text file, or is of > unknown content. When sent from server to client, it acts as a > hint to the client as to whether a file should be opened in > SSH_FXF_TEXT mode. The following values are defined: > > #define SSH_FILEXFER_CTYPE_UNKNOWN 0 > #define SSH_FILEXFER_CTYPE_BINARY 1 > #define SSH_FILEXFER_CTYPE_TEXT 2 > > To the end of the description of SSH_FXF_TEXT in section 6.3.1 > "Opening a File", add: > > Clients MAY decide whether to use SSH_FXF_TEXT based on a > previously seen `content_type' attribute; see Section 5.x. > > (Of course, this could all be easily reformulated as an extension > attribute if desired.) > > A version of filexfer-05 marked up with this proposal can be found at > > or . > > Warts with this proposal: > > It's unfortunate that this can't be made atomic within the existing > protocol design; it requires participating clients to do a STAT or > similar before OPEN. > (In fact, perhaps there should be some guidance on which of STAT or > LSTAT to do in this case.) > I don't know whether the non-atomicity would be a problem in practice. > > It's perhaps tempting to use the IETF's usual content-type notation, > "MIME types" (RFCs 2045-9 and related standards). However: > - I don't know of any real filesystems which use it. > - Consider "multipart/mixed" and friends. > - Does everything in "text/*" want to be opened FXF_TEXT? > - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? > (Excluding composite types like multipart.) > - It risks adding further to SFTP's bloat if not specified carefully. > We don't want to end up accidentally requiring implementations to > contain entire MIME implementations (or more likely, ill-defined > subsets thereof with poor interoperability). > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 15:52:48 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01816 for ; Tue, 5 Oct 2004 15:52:47 -0400 (EDT) Received: (qmail 11421 invoked by uid 605); 5 Oct 2004 19:52:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11380 invoked from network); 5 Oct 2004 19:52:43 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 19:52:42 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6690314; Tue, 05 Oct 2004 13:52:40 -0600 Message-ID: <4162FB87.8040808@vandyke.com> Date: Tue, 05 Oct 2004 13:52:39 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Whalen CC: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer References: <63D30D6E10CFD11190A90000F805FE86051AC8C2@lespaul.process.com> In-Reply-To: <63D30D6E10CFD11190A90000F805FE86051AC8C2@lespaul.process.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ahhh... do you actually open the file differently at the OS level for text mode? That hadn't occured to me. Still, for VMS, this proposal isn't any worse than the previous one, and this proposal is a little more compact. VMS would not set the TEXT_HINT bit in it's supported-attrib field, and clients would know they can't switch into text-mode. I'm not sure atomicity is a really that big deal... maybe I should just bag the switch to text mode anyway. I do still prefer adding a couple of bits to the attrib-bits field to adding a whole new field. Thanks, Joseph Richard Whalen wrote: > I don't think that this scheme will work for VMS. > Though we can report on the format of the file, the idea of opening it in an > unspecified mode, then specifying that you really want text mode may not be > possible without sacrificing the atomicity that some want. > > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, October 05, 2004 3:21 PM > To: ietf-ssh@netbsd.org > Subject: Re: Text file type hint proposal for filexfer > > > How about this alternative-- sftpv5 has (and naturally v6 will have) > an 'attrib-bits' field in the attrib structure which describes > various bit attributes, such as case-sensitivity, if the file > is encrypted on disk, compressed on disk, advisory readonly, > a hidden file, a system file, etc. > > What if we add two bits there: > > #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT 0x00000800 > > The server is reasonably certain that the file > contains textual data, and therefore the file > should be opened in text mode. > > This flag MUST NOT be present during a setstat operation. > If this flag is present during an fsetstat operation, > the file handle is converted to a text-mode handle, as > if it had been opened with SSH_FXF_ACCESS_TEXT_MODE. > > The server MUST NOT set this bit unless it is reasonably > certain the file should be transfered in text-mode because > many clients will use this flag to initiate automatic > text-mode translation. If the server sets this flag > in error, data corruption will result. > > #define SSH_FILEXFER_ATTR_FLAGS_BIN_HINT 0x00001000 > The server is reasonably certain that the file > contents are binary and should not be opened > with SSH_FXF_ACCESS_TEXT_MODE. > > This gets around your atomicity issue (I think.) The client > can open sans SSH_FXF_ACCESS_TEXT_MODE, do an fstat, and then, > if the server comes back with SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT > in the attrib.attrib-bits, it can do a fsetstat to put the > handle into text mode. > > mime types have come up enough times that I think I'm > going to add a field for them; anybody that doesn't > want shouldn't need to implement them though. > > (I know of at least one filesystem that does know the > mime-type information though.) > > - Joseph > > Jacob Nevins wrote: > >>SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN >>to allow the client to request that the server open a file in text >>mode. >> >>However, no means is provided for the server to advise the client on >>whether this transfer mode is appropriate. In all cases it is likely >>up to the user to manually specify which mode to use. >> >>In FTP, this has tended to lead to corrupted file transfers when >>unintentional translation took place, etc. Some FTP implementations >>have performed "automatic" conversions, e.g., using heuristics based >>on file contents; this is not reliable, and anyway rather defeats the >>point of having the server translate to a known representation. >> >>The following proposal allows the server to optionally communicate >>this information to the client via attributes. (Since it's an >>attribute, the client can also manipulate it on the server as far as >>is specified here if it corresponds to state there.) >> >>(This proposal is against draft-ietf-secsh-filexfer-05.) >> >>To section 5 "File Attributes", 2nd para, add between `attrib-bits' and >>`extended_count': >> >> byte content_type present only if flag CONTENT_TYPE >> >>To section 5.1 "Flags", add: >> >> #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000400 >> >>Add new section after section 5.8 "attrib-bits": >> >>5.x Content type >> >> The `content_type' field, if present, indicates whether the file is >> known to be a text file, known _not_ to be a text file, or is of >> unknown content. When sent from server to client, it acts as a >> hint to the client as to whether a file should be opened in >> SSH_FXF_TEXT mode. The following values are defined: >> >> #define SSH_FILEXFER_CTYPE_UNKNOWN 0 >> #define SSH_FILEXFER_CTYPE_BINARY 1 >> #define SSH_FILEXFER_CTYPE_TEXT 2 >> >>To the end of the description of SSH_FXF_TEXT in section 6.3.1 >>"Opening a File", add: >> >> Clients MAY decide whether to use SSH_FXF_TEXT based on a >> previously seen `content_type' attribute; see Section 5.x. >> >>(Of course, this could all be easily reformulated as an extension >>attribute if desired.) >> >>A version of filexfer-05 marked up with this proposal can be found at >> > > /draft-ietf-secsh-filexfer-05-plus-filetype.txt.diff?r1=1.3&r2=1.4&f=H> > >>or . >> >>Warts with this proposal: >> >>It's unfortunate that this can't be made atomic within the existing >>protocol design; it requires participating clients to do a STAT or >>similar before OPEN. >>(In fact, perhaps there should be some guidance on which of STAT or >>LSTAT to do in this case.) >>I don't know whether the non-atomicity would be a problem in practice. >> >>It's perhaps tempting to use the IETF's usual content-type notation, >>"MIME types" (RFCs 2045-9 and related standards). However: >> - I don't know of any real filesystems which use it. >> - Consider "multipart/mixed" and friends. >> - Does everything in "text/*" want to be opened FXF_TEXT? >> - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? >> (Excluding composite types like multipart.) >> - It risks adding further to SFTP's bloat if not specified carefully. >> We don't want to end up accidentally requiring implementations to >> contain entire MIME implementations (or more likely, ill-defined >> subsets thereof with poor interoperability). >> > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 16:01:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03180 for ; Tue, 5 Oct 2004 16:01:26 -0400 (EDT) Received: (qmail 16841 invoked by uid 605); 5 Oct 2004 20:01:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16831 invoked from network); 5 Oct 2004 20:01:24 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Oct 2004 20:01:24 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 16:01:22 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8C3@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" Cc: ietf-ssh@NetBSD.org Subject: RE: Text file type hint proposal for filexfer Date: Tue, 5 Oct 2004 16:01:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list Yes, the file is opened differently depending upon whether it is a binary or text transfer. I might be able to change on the fly if I avoid the C run time library and go directly to the system calls, but that would mean more programming work in the end too. I don't understand the demand for atomicity, but if some feel that it will improve the suability of implementations, then I'm not going to fight the idea. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Tuesday, October 05, 2004 3:53 PM To: Richard Whalen Cc: ietf-ssh@netbsd.org Subject: Re: Text file type hint proposal for filexfer Ahhh... do you actually open the file differently at the OS level for text mode? That hadn't occured to me. Still, for VMS, this proposal isn't any worse than the previous one, and this proposal is a little more compact. VMS would not set the TEXT_HINT bit in it's supported-attrib field, and clients would know they can't switch into text-mode. I'm not sure atomicity is a really that big deal... maybe I should just bag the switch to text mode anyway. I do still prefer adding a couple of bits to the attrib-bits field to adding a whole new field. Thanks, Joseph Richard Whalen wrote: > I don't think that this scheme will work for VMS. > Though we can report on the format of the file, the idea of opening it in an > unspecified mode, then specifying that you really want text mode may not be > possible without sacrificing the atomicity that some want. > > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, October 05, 2004 3:21 PM > To: ietf-ssh@netbsd.org > Subject: Re: Text file type hint proposal for filexfer > > > How about this alternative-- sftpv5 has (and naturally v6 will have) > an 'attrib-bits' field in the attrib structure which describes > various bit attributes, such as case-sensitivity, if the file > is encrypted on disk, compressed on disk, advisory readonly, > a hidden file, a system file, etc. > > What if we add two bits there: > > #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT 0x00000800 > > The server is reasonably certain that the file > contains textual data, and therefore the file > should be opened in text mode. > > This flag MUST NOT be present during a setstat operation. > If this flag is present during an fsetstat operation, > the file handle is converted to a text-mode handle, as > if it had been opened with SSH_FXF_ACCESS_TEXT_MODE. > > The server MUST NOT set this bit unless it is reasonably > certain the file should be transfered in text-mode because > many clients will use this flag to initiate automatic > text-mode translation. If the server sets this flag > in error, data corruption will result. > > #define SSH_FILEXFER_ATTR_FLAGS_BIN_HINT 0x00001000 > The server is reasonably certain that the file > contents are binary and should not be opened > with SSH_FXF_ACCESS_TEXT_MODE. > > This gets around your atomicity issue (I think.) The client > can open sans SSH_FXF_ACCESS_TEXT_MODE, do an fstat, and then, > if the server comes back with SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT > in the attrib.attrib-bits, it can do a fsetstat to put the > handle into text mode. > > mime types have come up enough times that I think I'm > going to add a field for them; anybody that doesn't > want shouldn't need to implement them though. > > (I know of at least one filesystem that does know the > mime-type information though.) > > - Joseph > > Jacob Nevins wrote: > >>SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN >>to allow the client to request that the server open a file in text >>mode. >> >>However, no means is provided for the server to advise the client on >>whether this transfer mode is appropriate. In all cases it is likely >>up to the user to manually specify which mode to use. >> >>In FTP, this has tended to lead to corrupted file transfers when >>unintentional translation took place, etc. Some FTP implementations >>have performed "automatic" conversions, e.g., using heuristics based >>on file contents; this is not reliable, and anyway rather defeats the >>point of having the server translate to a known representation. >> >>The following proposal allows the server to optionally communicate >>this information to the client via attributes. (Since it's an >>attribute, the client can also manipulate it on the server as far as >>is specified here if it corresponds to state there.) >> >>(This proposal is against draft-ietf-secsh-filexfer-05.) >> >>To section 5 "File Attributes", 2nd para, add between `attrib-bits' and >>`extended_count': >> >> byte content_type present only if flag CONTENT_TYPE >> >>To section 5.1 "Flags", add: >> >> #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000400 >> >>Add new section after section 5.8 "attrib-bits": >> >>5.x Content type >> >> The `content_type' field, if present, indicates whether the file is >> known to be a text file, known _not_ to be a text file, or is of >> unknown content. When sent from server to client, it acts as a >> hint to the client as to whether a file should be opened in >> SSH_FXF_TEXT mode. The following values are defined: >> >> #define SSH_FILEXFER_CTYPE_UNKNOWN 0 >> #define SSH_FILEXFER_CTYPE_BINARY 1 >> #define SSH_FILEXFER_CTYPE_TEXT 2 >> >>To the end of the description of SSH_FXF_TEXT in section 6.3.1 >>"Opening a File", add: >> >> Clients MAY decide whether to use SSH_FXF_TEXT based on a >> previously seen `content_type' attribute; see Section 5.x. >> >>(Of course, this could all be easily reformulated as an extension >>attribute if desired.) >> >>A version of filexfer-05 marked up with this proposal can be found at >> > > /draft-ietf-secsh-filexfer-05-plus-filetype.txt.diff?r1=1.3&r2=1.4&f=H> > >>or . >> >>Warts with this proposal: >> >>It's unfortunate that this can't be made atomic within the existing >>protocol design; it requires participating clients to do a STAT or >>similar before OPEN. >>(In fact, perhaps there should be some guidance on which of STAT or >>LSTAT to do in this case.) >>I don't know whether the non-atomicity would be a problem in practice. >> >>It's perhaps tempting to use the IETF's usual content-type notation, >>"MIME types" (RFCs 2045-9 and related standards). However: >> - I don't know of any real filesystems which use it. >> - Consider "multipart/mixed" and friends. >> - Does everything in "text/*" want to be opened FXF_TEXT? >> - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? >> (Excluding composite types like multipart.) >> - It risks adding further to SFTP's bloat if not specified carefully. >> We don't want to end up accidentally requiring implementations to >> contain entire MIME implementations (or more likely, ill-defined >> subsets thereof with poor interoperability). >> > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 16:02:48 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03527 for ; Tue, 5 Oct 2004 16:02:47 -0400 (EDT) Received: (qmail 18800 invoked by uid 605); 5 Oct 2004 20:02:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18508 invoked from network); 5 Oct 2004 20:02:38 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Oct 2004 20:02:38 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 16:02:37 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC8C4@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" Cc: "'ietf-ssh@netbsd.org'" Subject: RE: Text file type hint proposal for filexfer Date: Tue, 5 Oct 2004 16:02:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list "suability" should have been "usability" - I clicked too fast to the spell checker! -----Original Message----- From: Richard Whalen Sent: Tuesday, October 05, 2004 4:01 PM To: 'Joseph Galbraith' Cc: ietf-ssh@netbsd.org Subject: RE: Text file type hint proposal for filexfer Yes, the file is opened differently depending upon whether it is a binary or text transfer. I might be able to change on the fly if I avoid the C run time library and go directly to the system calls, but that would mean more programming work in the end too. I don't understand the demand for atomicity, but if some feel that it will improve the suability of implementations, then I'm not going to fight the idea. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Tuesday, October 05, 2004 3:53 PM To: Richard Whalen Cc: ietf-ssh@netbsd.org Subject: Re: Text file type hint proposal for filexfer Ahhh... do you actually open the file differently at the OS level for text mode? That hadn't occured to me. Still, for VMS, this proposal isn't any worse than the previous one, and this proposal is a little more compact. VMS would not set the TEXT_HINT bit in it's supported-attrib field, and clients would know they can't switch into text-mode. I'm not sure atomicity is a really that big deal... maybe I should just bag the switch to text mode anyway. I do still prefer adding a couple of bits to the attrib-bits field to adding a whole new field. Thanks, Joseph Richard Whalen wrote: > I don't think that this scheme will work for VMS. > Though we can report on the format of the file, the idea of opening it in an > unspecified mode, then specifying that you really want text mode may not be > possible without sacrificing the atomicity that some want. > > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, October 05, 2004 3:21 PM > To: ietf-ssh@netbsd.org > Subject: Re: Text file type hint proposal for filexfer > > > How about this alternative-- sftpv5 has (and naturally v6 will have) > an 'attrib-bits' field in the attrib structure which describes > various bit attributes, such as case-sensitivity, if the file > is encrypted on disk, compressed on disk, advisory readonly, > a hidden file, a system file, etc. > > What if we add two bits there: > > #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT 0x00000800 > > The server is reasonably certain that the file > contains textual data, and therefore the file > should be opened in text mode. > > This flag MUST NOT be present during a setstat operation. > If this flag is present during an fsetstat operation, > the file handle is converted to a text-mode handle, as > if it had been opened with SSH_FXF_ACCESS_TEXT_MODE. > > The server MUST NOT set this bit unless it is reasonably > certain the file should be transfered in text-mode because > many clients will use this flag to initiate automatic > text-mode translation. If the server sets this flag > in error, data corruption will result. > > #define SSH_FILEXFER_ATTR_FLAGS_BIN_HINT 0x00001000 > The server is reasonably certain that the file > contents are binary and should not be opened > with SSH_FXF_ACCESS_TEXT_MODE. > > This gets around your atomicity issue (I think.) The client > can open sans SSH_FXF_ACCESS_TEXT_MODE, do an fstat, and then, > if the server comes back with SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT > in the attrib.attrib-bits, it can do a fsetstat to put the > handle into text mode. > > mime types have come up enough times that I think I'm > going to add a field for them; anybody that doesn't > want shouldn't need to implement them though. > > (I know of at least one filesystem that does know the > mime-type information though.) > > - Joseph > > Jacob Nevins wrote: > >>SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN >>to allow the client to request that the server open a file in text >>mode. >> >>However, no means is provided for the server to advise the client on >>whether this transfer mode is appropriate. In all cases it is likely >>up to the user to manually specify which mode to use. >> >>In FTP, this has tended to lead to corrupted file transfers when >>unintentional translation took place, etc. Some FTP implementations >>have performed "automatic" conversions, e.g., using heuristics based >>on file contents; this is not reliable, and anyway rather defeats the >>point of having the server translate to a known representation. >> >>The following proposal allows the server to optionally communicate >>this information to the client via attributes. (Since it's an >>attribute, the client can also manipulate it on the server as far as >>is specified here if it corresponds to state there.) >> >>(This proposal is against draft-ietf-secsh-filexfer-05.) >> >>To section 5 "File Attributes", 2nd para, add between `attrib-bits' and >>`extended_count': >> >> byte content_type present only if flag CONTENT_TYPE >> >>To section 5.1 "Flags", add: >> >> #define SSH_FILEXFER_ATTR_CONTENT_TYPE 0x00000400 >> >>Add new section after section 5.8 "attrib-bits": >> >>5.x Content type >> >> The `content_type' field, if present, indicates whether the file is >> known to be a text file, known _not_ to be a text file, or is of >> unknown content. When sent from server to client, it acts as a >> hint to the client as to whether a file should be opened in >> SSH_FXF_TEXT mode. The following values are defined: >> >> #define SSH_FILEXFER_CTYPE_UNKNOWN 0 >> #define SSH_FILEXFER_CTYPE_BINARY 1 >> #define SSH_FILEXFER_CTYPE_TEXT 2 >> >>To the end of the description of SSH_FXF_TEXT in section 6.3.1 >>"Opening a File", add: >> >> Clients MAY decide whether to use SSH_FXF_TEXT based on a >> previously seen `content_type' attribute; see Section 5.x. >> >>(Of course, this could all be easily reformulated as an extension >>attribute if desired.) >> >>A version of filexfer-05 marked up with this proposal can be found at >> > > /draft-ietf-secsh-filexfer-05-plus-filetype.txt.diff?r1=1.3&r2=1.4&f=H> > >>or . >> >>Warts with this proposal: >> >>It's unfortunate that this can't be made atomic within the existing >>protocol design; it requires participating clients to do a STAT or >>similar before OPEN. >>(In fact, perhaps there should be some guidance on which of STAT or >>LSTAT to do in this case.) >>I don't know whether the non-atomicity would be a problem in practice. >> >>It's perhaps tempting to use the IETF's usual content-type notation, >>"MIME types" (RFCs 2045-9 and related standards). However: >> - I don't know of any real filesystems which use it. >> - Consider "multipart/mixed" and friends. >> - Does everything in "text/*" want to be opened FXF_TEXT? >> - Does everything outside "text/*" _not_ want to be opened FXF_TEXT? >> (Excluding composite types like multipart.) >> - It risks adding further to SFTP's bloat if not specified carefully. >> We don't want to end up accidentally requiring implementations to >> contain entire MIME implementations (or more likely, ill-defined >> subsets thereof with poor interoperability). >> > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 17:37:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14413 for ; Tue, 5 Oct 2004 17:37:28 -0400 (EDT) Received: (qmail 23845 invoked by uid 605); 5 Oct 2004 21:37:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23836 invoked from network); 5 Oct 2004 21:37:27 -0000 Received: from av9-1-sn3.vrr.skanova.net (81.228.9.185) by mail.netbsd.org with SMTP; 5 Oct 2004 21:37:26 -0000 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id E68393805A; Tue, 5 Oct 2004 23:17:28 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D776C37EFB; Tue, 5 Oct 2004 23:17:28 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BCED137E45; Tue, 5 Oct 2004 23:17:28 +0200 (CEST) Message-ID: <41630FE2.5000906@streamsec.se> Date: Tue, 05 Oct 2004 23:19:30 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <415ACA8A.4000504@vandyke.com> <415FD603.2070009@mindrot.org> <415FDB6E.1060702@streamsec.se> <4162BBAC.3070306@vandyke.com> In-Reply-To: <4162BBAC.3070306@vandyke.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > > If the client supports non-contigous version, for example, > > versions 2,3, and 6, then the INIT/VERSION negotiation > > is insufficient. In order to gaurentee a successful > > connection, the MUST send the highest version for which > > it supports all previos version (because the server > > might pick the version the client sends or any > > previous version.) > > > > However, in order to work around this limit in the > > deployed protocol implementations, after the > > INIT/VERSION exchange is complete, if the version > > negotiated is at least 3, the version where extensions was > > introduced, the client MAY send the following extension > > to attempt to negotiate a higher version: [snip] > I believe this mechanism maintains backwards compatibility > and gives us the version exchange we now wish we'd had > originally :-) I think it is good. Mostly because it serves as a statement that an implementation does not have to support all versions. I am not sure it will be of any practical benefit in our case, though. While there might be a performance penalty opening and closing and reopening a SFTP sub system if the SFTP server is implemented as a separate executable, this is typically not a concern if the SSH server and the SFTP server run in the same process. Our server implementation does not launch the SFTP server as a separate process, but either compiles it into the SSH server or uses dynamic loading (dll or so depending on platform). This means that there is only a marginal difference between the two approaches (open-close-reopen vs. open-extended renegotiation) w.r.t. both performance and code size on both the client side and the server side. My only concern is that server owners who run SSH server software that launches SFTP as a separate executable might not be thrilled about getting a lot of clients that execute the SFTP application twice instead of once in order to get the right protocol version. As I said, it is not a big thing, but bad design choices tend to sum up in the end... From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 17:53:16 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15117 for ; Tue, 5 Oct 2004 17:53:16 -0400 (EDT) Received: (qmail 3531 invoked by uid 605); 5 Oct 2004 21:53:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3522 invoked from network); 5 Oct 2004 21:53:15 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 5 Oct 2004 21:53:15 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1CExFC-00039L-00 for ietf-ssh@netbsd.org; Tue, 05 Oct 2004 22:53:14 +0100 Date: Tue, 5 Oct 2004 22:53:14 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer Message-ID: <20041005215314.GA10246@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: <4162F41B.5060900@vandyke.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: > How about this alternative-- sftpv5 has (and naturally v6 will have) > an 'attrib-bits' field in the attrib structure which describes various > bit attributes, such as case-sensitivity, if the file is encrypted on > disk, compressed on disk, advisory readonly, a hidden file, a system > file, etc. Yes, that's fair enough. I just recycled my proposal from SFTP v4 without taking account the new attrib-bits field. This information is probably better there. It might be worth spelling out that in the absence of either of these bits being set, the client SHOULD NOT automatically assume anything about the textiness or otherwise of the file. (The user can tell it, of course.) > What if we add two bits there: > > #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT 0x00000800 > > The server is reasonably certain that the file > contains textual data, and therefore the file > should be opened in text mode. > > This flag MUST NOT be present during a setstat operation. > If this flag is present during an fsetstat operation, > the file handle is converted to a text-mode handle, as > if it had been opened with SSH_FXF_ACCESS_TEXT_MODE. (Hmm. I deliberately hadn't ruled out the possibility that the "text flag" corresponded to some state on the server that you might want to be able to set with setstat. However, I'm not strongly wedded to that idea; it's probably a bit kludgy when you consider a filesystem that can represent a range of file types but only has this single distinction exposed over SFTP.) It seems a bit kludgy to override fsetstat's semantics in this way, when all other attributes correspond to state on disc. I think I'd prefer some new freopen()-like operation to change the file open mode. This however doesn't get round Richard Whalen's VMS concerns, except that perhaps being able to say SSH_FX_OP_UNSUPPORTED without ambiguity as to _what_ precisely is unsupported might be helpful (unlike setstat, where any of the attributes could have upset the server)? Perhaps the new `reopen' operation could be an extension, so that its lack on servers like VMS will be obvious up front via the "supported" extension, rather than the client not finding out until halfway through an operation? (I don't feel strongly about the atomicity issue, but I thought there might be people who did, perhaps including my future self.) [snip] > mime types have come up enough times that I think I'm going to add a > field for them; anybody that doesn't want shouldn't need to implement > them though. > > (I know of at least one filesystem that does know the mime-type > information though.) Which one is that, out of interest? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 18:16:05 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17330 for ; Tue, 5 Oct 2004 18:16:04 -0400 (EDT) Received: (qmail 17820 invoked by uid 605); 5 Oct 2004 22:16:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17811 invoked from network); 5 Oct 2004 22:16:03 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Oct 2004 22:16:03 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6690646 for ietf-ssh@netbsd.org; Tue, 05 Oct 2004 16:16:02 -0600 Message-ID: <41631D22.6010904@vandyke.com> Date: Tue, 05 Oct 2004 16:16:02 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer References: <20041005215314.GA10246@chiark.greenend.org.uk> In-Reply-To: <20041005215314.GA10246@chiark.greenend.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jacob Nevins wrote: > Joseph Galbraith writes: > >>How about this alternative-- sftpv5 has (and naturally v6 will have) >>an 'attrib-bits' field in the attrib structure which describes various >>bit attributes, such as case-sensitivity, if the file is encrypted on >>disk, compressed on disk, advisory readonly, a hidden file, a system >>file, etc. > > > Yes, that's fair enough. I just recycled my proposal from SFTP v4 > without taking account the new attrib-bits field. This information is > probably better there. > > It might be worth spelling out that in the absence of either of these > bits being set, the client SHOULD NOT automatically assume anything > about the textiness or otherwise of the file. (The user can tell it, of > course.) All right; I'll do that. >>What if we add two bits there: >> >> #define SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT 0x00000800 >> >> The server is reasonably certain that the file >> contains textual data, and therefore the file >> should be opened in text mode. >> >> This flag MUST NOT be present during a setstat operation. >> If this flag is present during an fsetstat operation, >> the file handle is converted to a text-mode handle, as >> if it had been opened with SSH_FXF_ACCESS_TEXT_MODE. > > [snip] > This however doesn't get round Richard Whalen's VMS concerns, except > that perhaps being able to say SSH_FX_OP_UNSUPPORTED without ambiguity > as to _what_ precisely is unsupported might be helpful (unlike setstat, > where any of the attributes could have upset the server)? Well, in theory, a VMS server would not set SSH_FILEXFER_ATTR_FLAGS_TEXT_HINT and hence the client would know that it can't send the attribute. However, unless someone speaks up at least moderately in favor of the atomicity issue, I think I'm going to drop that and forbid both flags during any kind of setstat operation. (Which I'd prefer to do rather than have some kind of poorly defined result when setting the flags.) > Perhaps the new `reopen' operation could be an extension, so that its > lack on servers like VMS will be obvious up front via the "supported" > extension, rather than the client not finding out until halfway through > an operation? > > (I don't feel strongly about the atomicity issue, but I thought there > might be people who did, perhaps including my future self.) I think if we decide to try and address atomicity issues that is a fine idea. I will probably go that route. > > [snip] > >>mime types have come up enough times that I think I'm going to add a >>field for them; anybody that doesn't want shouldn't need to implement >>them though. >> >>(I know of at least one filesystem that does know the mime-type >>information though.) > > > Which one is that, out of interest? I believe BeFS (from BeOS) supported mime types as it's native typing mechanism. There is at least a small movement creating an open source clone, so it isn't completely dead. A MS Windows based server that wanted to provide the information could query the registry from the file extension as well. (I doubt we will, but it is possible, and someone else might decide to do it.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 19:22:23 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22843 for ; Tue, 5 Oct 2004 19:22:22 -0400 (EDT) Received: (qmail 29694 invoked by uid 605); 5 Oct 2004 23:22:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29684 invoked from network); 5 Oct 2004 23:22:20 -0000 Received: from relais.videotron.ca (24.201.245.36) by mail.netbsd.org with SMTP; 5 Oct 2004 23:22:19 -0000 Received: from xoxoxo ([69.157.206.251]) by VL-MO-MR001.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I540065YWX1EH@VL-MO-MR001.ip.videotron.ca> for ietf-ssh@netbsd.org; Tue, 05 Oct 2004 19:22:19 -0400 (EDT) Date: Tue, 05 Oct 2004 19:22:16 -0400 From: P4P5 Tester Subject: P4 P5 Update Adapters Get Going PriceRising Fast Fast 219$ Today To: P4 And P5 Subscribers Reply-to: P4P5 Tester Message-id: <38874-220041025232216388@xoxoxo> Organization: P4P5 Tester MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7BIT The P400 Universal P4/P5 Adapter All Channel Opener 219$ and rising Package includes 1 Universal IRD P400 Unit and A step by step 4 Page Simple Setup Guide Unit Packs ask about them and save on A bundle for family or friends Call us now to order 1-888-252-8508 or 1-888-252-8509 or 1-800-462-9791 We would like to express our deepest thanks to the Henseng P400 Crew for making it possible for this long wait to happen.Due to the ever so popular High demand for our units weare making it possible for you to take advantage of our specials that are happening right now.Incase you were left out on the last email The P400 is the Ultimate solution in All channels open on Your DirecTv Systems.In plain english the unit will open all your PPV stations open as well as Your favourite channels.The Idea is to have a basic Subscription With DTV and you are all set.There is a step by step guide that any 4 year old child can figure out so please be minimul on your questions,This booklet is included with Purchase Unit Packs ask about them and save on A bundle for family or friends The P400 Universal P4/P5 Adapter All Channel Opener 219$ Call us now to order 1-888-252-8508 or 1-888-252-8509 or 1-800-462-9791 Steps are as Follows 1.Unplug COAXIAL cable from back of your DTV reciever 2.Simply Plug in the back of your NEW P400 Adapter 3.Plug P400 directly in the satellite IN on your recievers backing 4.Make sure that your Telephone wire is UNHOOKED before using. 5.Power on Recievers power and begin watching your favourite channels Remember that we are open Until 12am Western Time Zone For those who are behind on hours.Act now and take full advantage of our The P400 Universal P4/P5 Adapter All Channel Opener and Sales Reps and Staff.Thanks for the testers that made it possible for this to happen. Special Thanks To- Knight_Rider401,UltraDssCrackCrew,Romprotectuur,and last but not least the IRC crew P4ChannelHackerzTeam For making this so Awesome Unit Packs ask about them and save on A bundle for family or friends Call us now to order 1-888-252-8508 or 1-888-252-8509 or 1-800-462-9791 Hensang Imports P400 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 20:21:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29947 for ; Tue, 5 Oct 2004 20:21:00 -0400 (EDT) Received: (qmail 14720 invoked by uid 605); 6 Oct 2004 00:21:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14708 invoked from network); 6 Oct 2004 00:20:59 -0000 Received: from dsl-61-95-66-138.request.com.au (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 6 Oct 2004 00:20:58 -0000 Received: from mindrot.org (85.195.20.10.dhcp.netstarnetworks.com [10.20.195.85] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id i960Kpe07219; Wed, 6 Oct 2004 10:20:51 +1000 Message-ID: <41633A58.5040108@mindrot.org> Date: Wed, 06 Oct 2004 10:20:40 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20041003) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith CC: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= , ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <415ACA8A.4000504@vandyke.com> <415FD603.2070009@mindrot.org> <415FDB6E.1060702@streamsec.se> <4162BBAC.3070306@vandyke.com> In-Reply-To: <4162BBAC.3070306@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith wrote: > Henrick Hellström wrote: > >>Just a thought... >> >>What happens if a SFTP server supports v3 and v4, and a client that >>supports v3 and v6 only connects? >> >>According to the latest draft, they are supposed to start v4, since the >>client will send v6 and the server supports at most v4, and v4 is the >>least of these two numbers. >> >>Quoted from draft 05: >> >>4. Protocol Initialization >> >> When the file transfer protocol starts, the client first sends a >> SSH_FXP_INIT (including its version number) packet to the server. The >> server responds with a SSH_FXP_VERSION packet, supplying the lowest >> of its own and the client's version number. Both parties should from >> then on adhere to particular version of the protocol. > > > This has been a concern of mine for a while. The best solution I've > been able to come up with (better than closing channel, I think) is this: > > > If the client supports non-contigous version, for example, > > versions 2,3, and 6, then the INIT/VERSION negotiation > > is insufficient. In order to gaurentee a successful > > connection, the MUST send the highest version for which > > it supports all previos version (because the server > > might pick the version the client sends or any > > previous version.) > > > > However, in order to work around this limit in the > > deployed protocol implementations, after the > > INIT/VERSION exchange is complete, if the version > > negotiated is at least 3, the version where extensions was > > introduced, the client MAY send the following extension > > to attempt to negotiate a higher version: > > > > byte SSH_FXP_EXTENDED > > uint32 request-id > > string "version-negotiate" > > uint32 highest version-supported > > uint32 2nd highest version-supported > > ... > > uint32 lowest version-supported I'm in two minds about this: we need some way to negotiate versions, but this effectively eliminates the usefulness of the version sent at protocol start, which is going to have to negotiate to 3 for the foreseeable future. As far as the protocol itself, we could use the extended data in the SSH_FXP_INIT packet to indicate protocol support. e.g. byte SSH_FXP_INIT uint32 version string "version-negotiate" string highest-version-supported,2nd-highest-version,... The return SSH_FXP_VERSION packet can do the same. The client and server then pick the first common item from the lists. Every SSH implementation is going to have code for matching this sorts of list of comma separated strings, so I think it makes sense to reuse it. This also saves a round-trip at protocol start. Another alternative would be to do a new protocol start message with proper version negotiation and rename the subsystem (e.g. "sftp2"), but I think that this is overkill. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 5 20:40:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01699 for ; Tue, 5 Oct 2004 20:40:21 -0400 (EDT) Received: (qmail 28015 invoked by uid 605); 6 Oct 2004 00:40:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28006 invoked from network); 6 Oct 2004 00:40:18 -0000 Received: from dsl-61-95-66-138.request.com.au (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 6 Oct 2004 00:40:15 -0000 Received: from mindrot.org (85.195.20.10.dhcp.netstarnetworks.com [10.20.195.85] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id i95NwXe02661; Wed, 6 Oct 2004 09:58:33 +1000 Message-ID: <4163351E.70009@mindrot.org> Date: Wed, 06 Oct 2004 09:58:22 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20041003) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith CC: ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-filexfer-05.txt References: <405F086A.80101@klomp.org> <405F2E5F.5090501@vandyke.com> <405F65BA.3020102@mindrot.org> <4162CA8F.1020602@vandyke.com> In-Reply-To: <4162CA8F.1020602@vandyke.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > If no one else has any thoughts or objections to this, > I will add it to the draft as follows: > > New flag to open command: > > SSH_FXF_NOFOLLOW = 0x00000200 > > SSH_FXF_NOFOLLOW > If the final component of the path is a symlink, the link > file itself should be opened instead of the the target. > > What should the behavior be if a symlink file is opened and > then read or written to? I think that the open() should fail when NOFOLLOW is set and the target is a symlink. This is what the open(2) flag in Linux/BSD does, returning errno == ELOOP. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 6 14:40:17 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21279 for ; Wed, 6 Oct 2004 14:40:17 -0400 (EDT) Received: (qmail 12585 invoked by uid 605); 6 Oct 2004 18:40:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12565 invoked from network); 6 Oct 2004 18:40:14 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 6 Oct 2004 18:40:14 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6693287; Wed, 06 Oct 2004 12:40:12 -0600 Message-ID: <41643C0C.90602@vandyke.com> Date: Wed, 06 Oct 2004 12:40:12 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller CC: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= , ietf-ssh@NetBSD.org Subject: Re: SFTP version negotiation References: <415ACA8A.4000504@vandyke.com> <415FD603.2070009@mindrot.org> <415FDB6E.1060702@streamsec.se> <4162BBAC.3070306@vandyke.com> <41633A58.5040108@mindrot.org> In-Reply-To: <41633A58.5040108@mindrot.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Damien Miller wrote: > Joseph Galbraith wrote: > >>Henrick Hellström wrote: >> >> >>>Just a thought... >>> >>>What happens if a SFTP server supports v3 and v4, and a client that >>>supports v3 and v6 only connects? >>> >>>According to the latest draft, they are supposed to start v4, since the >>>client will send v6 and the server supports at most v4, and v4 is the >>>least of these two numbers. >>> >>>Quoted from draft 05: >>> >>>4. Protocol Initialization >>> >>> When the file transfer protocol starts, the client first sends a >>> SSH_FXP_INIT (including its version number) packet to the server. The >>> server responds with a SSH_FXP_VERSION packet, supplying the lowest >>> of its own and the client's version number. Both parties should from >>> then on adhere to particular version of the protocol. >> >> >>This has been a concern of mine for a while. The best solution I've >>been able to come up with (better than closing channel, I think) is this: >> >> > If the client supports non-contigous version, for example, >> > versions 2,3, and 6, then the INIT/VERSION negotiation >> > is insufficient. In order to gaurentee a successful >> > connection, the MUST send the highest version for which >> > it supports all previos version (because the server >> > might pick the version the client sends or any >> > previous version.) >> > >> > However, in order to work around this limit in the >> > deployed protocol implementations, after the >> > INIT/VERSION exchange is complete, if the version >> > negotiated is at least 3, the version where extensions was >> > introduced, the client MAY send the following extension >> > to attempt to negotiate a higher version: >> > >> > byte SSH_FXP_EXTENDED >> > uint32 request-id >> > string "version-negotiate" >> > uint32 highest version-supported >> > uint32 2nd highest version-supported >> > ... >> > uint32 lowest version-supported > > > I'm in two minds about this: we need some way to negotiate versions, but > this effectively eliminates the usefulness of the version sent at > protocol start, which is going to have to negotiate to 3 for the > foreseeable future. > > As far as the protocol itself, we could use the extended data in the > SSH_FXP_INIT packet to indicate protocol support. e.g. > > byte SSH_FXP_INIT > uint32 version > string "version-negotiate" > string highest-version-supported,2nd-highest-version,... Unfortunately, we were forced to remove SSH_FXP_INIT extension data because it broke compatibility with down-level servers. (I.e., the client has to send the INIT packet before it knows that the server is a mature enough version to understand about extensions.) > The return SSH_FXP_VERSION packet can do the same. The client and server > then pick the first common item from the lists. We could have the server send it's list of supported versions as part of the FXP_VERSION packet and then allow the client to request that the server switch to one of the listed versions... but that doesn't save the round trip, since the client still has to do the switch as an extension w/ a round trip. > Every SSH implementation > is going to have code for matching this sorts of list of comma separated > strings, so I think it makes sense to reuse it. This also saves a > round-trip at protocol start. I considered the string version, and I'm definitely not opposed to going that route. It was really just a flip of a coin for me... - Joseph I thought about using the string version of this... and I didn't The server could > > Another alternative would be to do a new protocol start message with > proper version negotiation and rename the subsystem (e.g. "sftp2"), but > I think that this is overkill. > > -d > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 6 15:37:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26978 for ; Wed, 6 Oct 2004 15:37:21 -0400 (EDT) Received: (qmail 20991 invoked by uid 605); 6 Oct 2004 19:37:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20981 invoked from network); 6 Oct 2004 19:37:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 6 Oct 2004 19:37:19 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6693447; Wed, 06 Oct 2004 13:37:18 -0600 Message-ID: <4164496E.3040807@vandyke.com> Date: Wed, 06 Oct 2004 13:37:18 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller CC: ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-filexfer-05.txt References: <405F086A.80101@klomp.org> <405F2E5F.5090501@vandyke.com> <405F65BA.3020102@mindrot.org> <4162CA8F.1020602@vandyke.com> <4163351E.70009@mindrot.org> In-Reply-To: <4163351E.70009@mindrot.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller wrote: > Joseph Galbraith wrote: > > >>If no one else has any thoughts or objections to this, >>I will add it to the draft as follows: >> >>New flag to open command: >> >> SSH_FXF_NOFOLLOW = 0x00000200 >> >>SSH_FXF_NOFOLLOW >> If the final component of the path is a symlink, the link >> file itself should be opened instead of the the target. >> >>What should the behavior be if a symlink file is opened and >>then read or written to? > > > I think that the open() should fail when NOFOLLOW is set and the target > is a symlink. This is what the open(2) flag in Linux/BSD does, returning > errno == ELOOP. Okay, I've changed the description to read: If the final component of the path is a symlink, the open must fail, with the error SSH_FX_SYMLINK. And added the error code SSH_FX_SYMLINK, with the following description: The file could not be opened because it is a symbolic link and the NOFOLLOW flag was specified. Does that sound right? Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 6 15:38:42 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27140 for ; Wed, 6 Oct 2004 15:38:41 -0400 (EDT) Received: (qmail 21777 invoked by uid 605); 6 Oct 2004 19:38:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21767 invoked from network); 6 Oct 2004 19:38:40 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 6 Oct 2004 19:38:40 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6693460; Wed, 06 Oct 2004 13:38:38 -0600 Message-ID: <416449BF.8050907@vandyke.com> Date: Wed, 06 Oct 2004 13:38:39 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Galbraith CC: Damien Miller , ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-filexfer-05.txt References: <405F086A.80101@klomp.org> <405F2E5F.5090501@vandyke.com> <405F65BA.3020102@mindrot.org> <4162CA8F.1020602@vandyke.com> <4163351E.70009@mindrot.org> <4164496E.3040807@vandyke.com> In-Reply-To: <4164496E.3040807@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > Damien Miller wrote: > >> Joseph Galbraith wrote: >> >> >>> If no one else has any thoughts or objections to this, >>> I will add it to the draft as follows: >>> >>> New flag to open command: >>> >>> SSH_FXF_NOFOLLOW = 0x00000200 >>> >>> SSH_FXF_NOFOLLOW >>> If the final component of the path is a symlink, the link >>> file itself should be opened instead of the the target. >>> >>> What should the behavior be if a symlink file is opened and >>> then read or written to? >> >> >> >> I think that the open() should fail when NOFOLLOW is set and the target >> is a symlink. This is what the open(2) flag in Linux/BSD does, returning >> errno == ELOOP. > > > Okay, I've changed the description to read: > > If the final component of the path is a symlink, > the open must fail, with the error SSH_FX_SYMLINK. > > And added the error code SSH_FX_SYMLINK, with the > following description: > > The file could not be opened because it is a symbolic link > and the NOFOLLOW flag was specified. I take that back... if the OS is return ELOOP, I have the error be SSH_FX_LINK_LOOP, and get rid of SSH_FX_SYMLINK. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 6 19:20:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28585 for ; Wed, 6 Oct 2004 19:20:36 -0400 (EDT) Received: (qmail 25588 invoked by uid 605); 6 Oct 2004 23:20:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25579 invoked from network); 6 Oct 2004 23:20:36 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 6 Oct 2004 23:20:35 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1CFL5H-0006t0-00 for ietf-ssh@netbsd.org; Thu, 07 Oct 2004 00:20:35 +0100 Date: Thu, 7 Oct 2004 00:20:35 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... Message-ID: <20041006232035.GA18904@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: <4162D042.3010305@vandyke.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: > Unix directories can contain files encoded in multiple different > char-sets and the server has no way to tell what these multiple > char-sets are and translate them to UTF-8. Because the transformation > is one way, once the server has mistranslated the filename, there is > no way for the client to get back to the original data. > > So, for these file-systems, the best possible thing to do is send the > filename raw and let the client (with help from the user decode it.) I support this. While it would be nice for all filenames to be in UTF-8 or reliably convertible to/from it, it is beyond the power of this working group to cause this to happen, so this requirement simply won't be implemented. (We've pinched stuff from NFS before. Do they have any views on this issue?) > On the other hand, maximum possible interoperability between different > language and regions is obtained through use of UTF-8 where available. > > I haven't been able to come up with a solution I really like. > > Here are some possibilities: > > 1. Let the server say what it is going to use, UTF-8 or > 'undefined-raw' at the beginning of the sftp session. > > pro: simple. really simple. > con: Doesn't address cases where the server might be able to do > utf-8 for some file systems (ext-3 under fedora, I think is > one example) but not others. It's true that this is rather limiting. But if your directory tree has heterogenous UTF-8-ness, don't you run into problems with having some path components "raw" and others UTF-8? Given our approach of paths being rather opaque things, I can't think of a way round this. Therefore, I suspect that something like this simple approach may have to be taken... > 2. Allow the filename to be prefixed by a flag byte saying it is raw. > For example, the byte 0xFF is an invalid UTF-8 lead byte. If the > first byte of the filename is 0xFF, then the 0xFF is discarded, > and the rest of string is the 'raw, undefined' filename data. > > pro: It handles the real life complexity of being able to tell > sometimes, but not others. > con: It is a little more complex, and a bit icky. > > 3. Give the filename structure. Filenames are always specified in the > following structure: > > uint32 length of the structure > boolean utf-8 > byte filename[length-1] > > pro: This also handles being able to give UTF-8 sometimes, but not > all the time. > pro: This isn't icky. > con: This is a bit more complex. In particular, backwards-compatible implementations now need two sets of filename-handling code. > 4. Use the high order bit of the length field to flag raw more. In > practice, no file name will ever be more than 2 gig long :-) We > can safely borrow that bit for other purposes. > > pro: This also handles being able to give UTF-8 sometimes, but not > all the time. > con: Slightly icky, a little more complex. > > Can anyone think of a better solution? > > I think I prefer solution three, I could live with 2 or 4; I'd really > rather not go with 1. I think I slightly prefer 2 to 4, if the issue I mention above can be got round. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 7 22:32:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28261 for ; Thu, 7 Oct 2004 22:32:21 -0400 (EDT) Received: (qmail 13656 invoked by uid 605); 8 Oct 2004 02:32:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13647 invoked from network); 8 Oct 2004 02:32:14 -0000 Received: from ajax.cnchost.com (207.155.248.31) by mail.netbsd.org with SMTP; 8 Oct 2004 02:32:14 -0000 Received: from Nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by ajax.cnchost.com id WAA20560; Thu, 7 Oct 2004 22:32:11 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Joseph Galbraith'" , Subject: RE: Text file type hint proposal for filexfer Date: Fri, 8 Oct 2004 04:32:03 +0200 Message-ID: <000001c4acdf$002f97a0$6302a8c0@Nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <41631D22.6010904@vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > > It might be worth spelling out that in the absence of=20 > > either of these bits being set, the client SHOULD NOT > > automatically assume anything about the textiness or > > otherwise of the file. (The user can tell it, of > > course.) >=20 > All right; I'll do that. I would like to note that checking whether the file is textual or not is = a cheap operation only on VMS. Defining the text/binary hint as a file attribute makes it less likely = that Unix and Windows servers will implement this. I think we would benefit if it were possible for a client to query the = likely textual or binary state of a file independently of anything else. In = other words, without obliging the server to either show this possibly = expensive information as part of regular easily-obtainable attrib-bits, or not = support this feature at all. I think the attribute hints are a nice idea and will work for VMS. = However for Unix and Windows servers, we might also benefit from a way for the = client to prompt the server to determine on the fly whether the file is textual or binary, if the server has not indicated the file type in attrib-bits. = This query would be done right before downloading the file. If the spec does not provide for this, and only defines the text hints = in attrib-bits, then a complete client implementation wishing to implement automatic file type conversion will look as follows: - if server gives text hint, open file in text mode and download; - if server gives binary hint, open file in binary mode and download; - if server gives no hint, open in binary mode, then scan bytes = received, see if the file can be recognized as textual, and do conversion on the fly. Granted, this is much better than what we have now. However if there was widespread server-side support for a query to = determine file type, the detection and conversion algorithms could be entirely = removed from the client. The spec already requires servers to implement text file -> canonical = format conversion (the SSH_FXF_TEXT flag). But this feature is useless if the = client cannot query the server for the file type. The attrib-bits hint does not = solve this for Unix and Windows servers because they are unlikely to be able = to give this information as part of attrib-bits. It requires a dedicated = request. My thinking is, either we require Unix and Windows servers to implement = both (a) conversion - SSH_FXF_TEXT flag, AND (b) file type detection; or we = should require them to do neither. The corresponding solutions are: (a) Specify attrib-bits as you propose, but also a dedicated file type = query request in case this determination is more expensive. (b) Say in the spec that SSH_FXF_TEXT need not be supported by servers = that don't send the text hint. The binary hint in this case is also not = necessary. No text hint -> open the file in binary, detect and convert if you = please. The idea is, let's be consistent, and let's not specify things halfway = through. denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 7 23:18:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00633 for ; Thu, 7 Oct 2004 23:18:35 -0400 (EDT) Received: (qmail 22268 invoked by uid 605); 8 Oct 2004 03:18:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22258 invoked from network); 8 Oct 2004 03:18:33 -0000 Received: from ajax.cnchost.com (207.155.248.31) by mail.netbsd.org with SMTP; 8 Oct 2004 03:18:33 -0000 Received: from Nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by ajax.cnchost.com id VAA03729; Thu, 7 Oct 2004 21:54:37 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Joseph Galbraith'" , "'Damien Miller'" Cc: "=?iso-8859-1?Q?'Henrick_Hellstr=F6m'?=" , Subject: RE: SFTP version negotiation Date: Fri, 8 Oct 2004 03:54:29 +0200 Message-ID: <000001c4acd9$c155c180$6302a8c0@Nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <41643C0C.90602@vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > We could have the server send it's list of supported versions > as part of the FXP_VERSION packet and then allow the client > to request that the server switch to one of the listed > versions... but that doesn't save the round trip, since the > client still has to do the switch as an extension w/ a round > trip. It does save a round trip because if the server includes a "versions" = extension and the client elects to send a request for one of those higher = versions, the client can fire-and-forget that request and proceed with other requests immediately. The spec could mandate that the server MUST always respond positively to a well-formed client request for a higher version if that = version was advertised by the server in the extensions of SSH_FXP_VERSION. It could look something like this: -> SSH_FXP_INIT version: x <- SSH_FXP_VERSION version: x ext name: "versions" ext data: "x+3,x+1" -> SSH_FXP_SELECTVERSION version: x+3 -> SSH_FXP_REALPATH request id: 0 path: "." <- SSH_FXP_VERSIONSELECTED <- SSH_FXP_NAME request id: 0 count: 1 filename attributes The spec would mandate: - The highest version number that a client should ever send is "x" (the = last version number before this 2nd mechanism was introduced - say 5 at this = point if the extension is introduced in SFTP v6). - A server supporting versions >x MUST send the "versions" extension enumerating the versions higher than x that it supports. Mentioning = versions <=3Dx is pointless, we should recommend people not do it lest someone = overeager populate this with 4,3,2,1. The "versions" extension should be sent whenever the version sent by = the client indicates that the client supports SSH_FXP_VERSION extensions. = So, this should be sent even if the client advertises e.g. version 3. This is so = that a client supporting 3 and 6 can advertise 3 and get 3 against version 5 = servers, but select 6 when the server is 6+. - If the client wishes to do so, it can switch protocol version to one = of the higher versions advertised by the server by a direct reply to the = server's SSH_FXP_VERSION message. This can be done with SSH_FXP_SELECTVERSION = (newly invented). There is no request ID because it is not necessary, the = message can only appear in immediate response to SSH_FXP_VERSION, cannot appear = multiple times. - The server replies to that with SSH_FXP_VERSIONSELECTED. This is just = to maintain the request-reply dynamic of the SFTP protocol and is not = really necessary. If the client's request was faulty, the server cannot do much = but close the channel anyway. If the client's request was alright, the = server must honor it. We could just as well do without this response message in fact = - unless someone has something to say for it, I propose we might even drop = this response. - The client need not wait for SSH_FXP_VERSIONSELECTED, and when this = message arrives it can be ignored. The client can pipeline requests immediately = after sending SSH_FXP_SELECTVERSION. Seems like an OK solution to me - no roundtrip problem, and has = immediate benefit of solving the issue of the client supporting only versions 3 = and 6. Votes? denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 8 07:29:07 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15753 for ; Fri, 8 Oct 2004 07:29:06 -0400 (EDT) Received: (qmail 10492 invoked by uid 605); 8 Oct 2004 11:29:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10483 invoked from network); 8 Oct 2004 11:29:02 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Oct 2004 11:29:02 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 8ABAF182DFD; Fri, 8 Oct 2004 13:29:00 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 77D3018258D; Fri, 8 Oct 2004 13:28:56 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i98BStih012163; Fri, 8 Oct 2004 13:28:55 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i98BSnrV012160; Fri, 8 Oct 2004 13:28:49 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... References: <4162D042.3010305@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 08 Oct 2004 13:28:45 +0200 In-Reply-To: <4162D042.3010305@vandyke.com> Message-ID: Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > Here are some possibilities: > > 1. Let the server say what it is going to use, > UTF-8 or 'undefined-raw' at the beginning > of the sftp session. > > pro: simple. really simple. > con: Doesn't address cases where the server > might be able to do utf-8 for some file > systems (ext-3 under fedora, I think is > one example) but not others. I'd much prefer the simple way. Just let the server say what character set it uses, and do no conversions at the server end (a server that really knows what it is doing MAY handle a file system with mixed character sets by converting them to and from utf-8, and use utf-8 exclusively on the wire, but I don't think that is very practical). Some possible values are "unknown", "usascii", "iso-8859-1", "utf-8", and "utf-8-with-normalization-form-c". (Note that utf-8 with undefined normalization is suboptimal for filenames and for identifiers in general). This approach should work fine for systems that uses utf-8 consistently in the filesystem (I think windows-ce does that, not sure about more regular windows versions). I think the typical unix filesystem uses usascii for all "system files", and then has some home directories with iso-8859-x names, some with utf-8 names, which all include usascii. (I admit that I don't have any experience with asian unix installations). Then it will work reasonably to set the advertised charset from the user's $LC_CTYPE. There will naturally be some difficulties if different parts of the filesystem tree uses different character sets, or if there are single pathnames that use components (directory names) with different character sets. However, those difficulties are precisely the same with *local* access to the file system, so it makes absolutely no sense to try to solve them in the sftp spec. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 8 12:06:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07529 for ; Fri, 8 Oct 2004 12:06:11 -0400 (EDT) Received: (qmail 9999 invoked by uid 605); 8 Oct 2004 16:06:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9989 invoked from network); 8 Oct 2004 16:06:05 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 8 Oct 2004 16:06:05 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa09751; 8 Oct 2004 12:05 EDT Date: Fri, 08 Oct 2004 12:05:30 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Joseph Galbraith cc: ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... Message-ID: <467630000.1097251530@minbar.fac.cs.cmu.edu> In-Reply-To: References: <4162D042.3010305@vandyke.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Friday, October 08, 2004 13:28:45 +0200 Niels M=F6ller=20 wrote: > Joseph Galbraith writes: > >> Here are some possibilities: >> >> 1. Let the server say what it is going to use, >> UTF-8 or 'undefined-raw' at the beginning >> of the sftp session. >> >> pro: simple. really simple. >> con: Doesn't address cases where the server >> might be able to do utf-8 for some file >> systems (ext-3 under fedora, I think is >> one example) but not others. > > I'd much prefer the simple way. Just let the server say what character > set it uses, and do no conversions at the server end (a server that > really knows what it is doing MAY handle a file system with mixed > character sets by converting them to and from utf-8, and use utf-8 > exclusively on the wire, but I don't think that is very practical). > Some possible values are "unknown", "usascii", "iso-8859-1", "utf-8", > and "utf-8-with-normalization-form-c". So far, so good. Note that the appropriate set of possible values is that=20 contained in the IANA Character Set registry=20 (http://www.iana.org/assignments/character-sets). When a character set in=20 that registry has more than one name or alias, the alias designated as=20 "preferred MIME name" SHOULD be used. But see below... > (Note that utf-8 with undefined normalization is suboptimal for > filenames and for identifiers in general). Yes. I'd normally argue that in any case where UTF-8 will be used on the=20 wire, it probably ought to be normalized. However, the key issue here is=20 not really normalization of names sent by the server but of those sent by=20 the client, which refer to the names in the filesystem. Unfortunately,=20 there are filesystems that use unnormalized Unicode, so the server would be = required to do path processing itself, normalizing all the names in each=20 directory until it found one matching what the user requested. That's=20 going to get unwieldy real fast, I think. > I think the typical unix filesystem uses usascii for all "system > files", and then has some home directories with iso-8859-x names, some > with utf-8 names, which all include usascii. (I admit that I don't > have any experience with asian unix installations). Then it will work > reasonably to set the advertised charset from the user's $LC_CTYPE. I would expect this to be more or less the case. In fact, I'd expect that=20 on most systems, most users will be using the _same_ character set. > There will naturally be some difficulties if different parts of the > filesystem tree uses different character sets, or if there are single > pathnames that use components (directory names) with different > character sets. However, those difficulties are precisely the same > with *local* access to the file system, so it makes absolutely no > sense to try to solve them in the sftp spec. I agree -- solving that problem is beyond our ability, and I do not think=20 it is worth the effort to try. There is one thing I'd do differently. Whenever possible, I'd prefer that=20 the server not just advertise the character set but actually do the=20 conversions. The theory here is that the server is likely to have at its=20 disposal the tools needed to convert between Unicode and any other=20 character set in use on the server. The _client_, on the other hand, can=20 only reasonably be expected to have those tools for character sets in use=20 on the client. When these sets are disjoint, interoperability demands the=20 use on the wire of a common character set (i.e. Unicode). Let the server advertise the character set it thinks is in use. Let the client decide whether it wants UTF-8 or raw bytes. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 8 13:41:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14497 for ; Fri, 8 Oct 2004 13:41:20 -0400 (EDT) Received: (qmail 17147 invoked by uid 605); 8 Oct 2004 17:41:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17137 invoked from network); 8 Oct 2004 17:41:17 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 8 Oct 2004 17:41:17 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2004 10:46:40 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i98HfDIC029499 for ; Fri, 8 Oct 2004 10:41:13 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA08821 for ; Fri, 8 Oct 2004 10:41:15 -0700 (PDT) Date: Fri, 8 Oct 2004 10:41:15 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, I'm working-in the text for this and need some clarification. In [CONNECT], we describe the opening of a channel. This message has the format of: byte SSH_MSG_CHANNEL_OPEN string channel type in US-ASCII only uint32 sender channel uint32 initial window size uint32 maximum packet size ... channel type specific data follows where the 'channel type' "is a name as described in [SSH-ARCH] and [SSH-NUMBERS], with similar extension mechanisms." (Not much to go on there.) Further in the document, we say, "Many 'channel type' values have extensions that are specific to that particular 'channel type'. An example is requesting a pty (pseudo terminal) for an interactive session." And still further in the document, we define "pty-req" as a specific 'channel type'. As it is, we need to have the IANA set up a registry for 'channel type' values with the only current entry being "pty-req". We also need to tell the IANA that additional 'channel type' values may be added through some mechanism. I'll suggest that the mechanism be the IETF CONSENSUS method [RFC 2434] but plese let me know if it should be "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", or "STANDARDS ACTION". This is the IANA controlled namespace which, as Jeffrey notes below, may contain the "@example.com" extension space if they are defined through an appropriate method. Having the method be IETF CONSENSUS allows an Informational RFC to add an entry to the IANA Registry. Most importantly, are there any other 'channel type' values that need to be defined in this initial registry? Thanks, Chris On Mon, 27 Sep 2004, Jeffrey Hutzelman wrote: > > > On Monday, September 27, 2004 13:45:59 +0200 Niels M=F6ller > wrote: > > > Chris Lonvick writes: > > > >> > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > >> > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, > >> > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way > > > >> Are there any objections to this allocation scheme? If not, I'll use = it > >> for the Disconnection Code 'reason code's and as the model for other > >> uint32 ranges. > > > > Note that the above scheme is applicable only to the reason codes in > > SSH_MSG_CHANNEL_OPEN_FAILURE. > > Right; the channel-type-specific range makes sense only for messages whic= h > occur in the context of a particular channel. Global mesasges like > SSH_MSG_DISCONNECT cannot be associated with any particular channel, and > should not define this range. > > > Note that there is no reason to restrict the use of the 0xFE range to > privately-defined channel types. It is IMHO entirely reasonable for a > standards-track channel type to defined a channel-type-specifc code. Suc= h > a code would be specified in the document defining the channel type and > would be drawn from the 0xFE range, without regard to use of codes in tha= t > range by other channel types. > > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 8 13:53:35 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15688 for ; Fri, 8 Oct 2004 13:53:35 -0400 (EDT) Received: (qmail 26835 invoked by uid 605); 8 Oct 2004 17:53:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26824 invoked from network); 8 Oct 2004 17:53:32 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Oct 2004 17:53:32 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 0A53C1D8878; Fri, 8 Oct 2004 19:46:44 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 08C6313D06; Fri, 8 Oct 2004 19:46:39 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i98Hkcih003436; Fri, 8 Oct 2004 19:46:38 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i98HkXTF003432; Fri, 8 Oct 2004 19:46:33 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 08 Oct 2004 19:46:30 +0200 In-Reply-To: <467630000.1097251530@minbar.fac.cs.cmu.edu> Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > On Friday, October 08, 2004 13:28:45 +0200 Niels Möller > wrote: > > > (Note that utf-8 with undefined normalization is suboptimal for > > filenames and for identifiers in general). > > Yes. I'd normally argue that in any case where UTF-8 will be used on > the wire, it probably ought to be normalized. However, the key issue > here is not really normalization of names sent by the server but of > those sent by the client, which refer to the names in the > filesystem. There's actually one important use case where normalization doesn't matter. That is if the client first requests a directory listing, and then presents those names to the user, via some graphical file dialog, or via TAB-completion. In this case, the only important thing is that the client doesn't modify the coding when a name is copied from the directory listing to the open request. > Unfortunately, there are filesystems that use unnormalized Unicode, That's going to be painful. Examples? > There is one thing I'd do differently. Whenever possible, I'd prefer > that the server not just advertise the character set but actually do > the conversions. [...] > Let the server advertise the character set it thinks is in use. > Let the client decide whether it wants UTF-8 or raw bytes. Good idea. I agree it makes sense to give clients that choice. I'm not so sure I share your preference, though; I'm afraid subtle problems may occur when file names are converted to utf-8, processed by client ui code, and back. One interesting case: When converting from the local charset to utf-8, it is natural to require that the server uses normalized utf-8, right? (With canonical normalization, not compatibility normalization). However, if the server's local character set happens to be utf-8, and some file names are unnormalized, then having the server normalize the data for transmission is likely to break things. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 8 14:22:11 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18134 for ; Fri, 8 Oct 2004 14:22:10 -0400 (EDT) Received: (qmail 11103 invoked by uid 605); 8 Oct 2004 18:22:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11094 invoked from network); 8 Oct 2004 18:22:08 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 8 Oct 2004 18:22:08 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa10119; 8 Oct 2004 14:21 EDT Date: Fri, 08 Oct 2004 14:21:37 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= cc: Jeffrey Hutzelman , Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... Message-ID: <498740000.1097259697@minbar.fac.cs.cmu.edu> In-Reply-To: References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Friday, October 08, 2004 19:46:30 +0200 Niels M=F6ller=20 wrote: > Jeffrey Hutzelman writes: > >> On Friday, October 08, 2004 13:28:45 +0200 Niels M=F6ller >> wrote: >> >> > (Note that utf-8 with undefined normalization is suboptimal for >> > filenames and for identifiers in general). >> >> Yes. I'd normally argue that in any case where UTF-8 will be used on >> the wire, it probably ought to be normalized. However, the key issue >> here is not really normalization of names sent by the server but of >> those sent by the client, which refer to the names in the >> filesystem. > > There's actually one important use case where normalization doesn't > matter. That is if the client first requests a directory listing, and > then presents those names to the user, via some graphical file dialog, > or via TAB-completion. In this case, the only important thing is that > the client doesn't modify the coding when a name is copied from the > directory listing to the open request. Correct. >> Unfortunately, there are filesystems that use unnormalized Unicode, > > That's going to be painful. Examples? I don't believe Windows normalizes anything. > Good idea. I agree it makes sense to give clients that choice. > > I'm not so sure I share your preference, though; I'm afraid subtle > problems may occur when file names are converted to utf-8, processed > by client ui code, and back. > > One interesting case: When converting from the local charset to utf-8, > it is natural to require that the server uses normalized utf-8, right? > (With canonical normalization, not compatibility normalization). > > However, if the server's local character set happens to be utf-8, and > some file names are unnormalized, then having the server normalize the > data for transmission is likely to break things. Yes. If the server's local character set is UTF-8, it SHOULD NOT=20 normalize. It it's something else, then the server should convert to UTF-8 = using whatever rules it deems appropriate, and should accept any reasonable = representation from the client (particularly, it SHOULD NOT require=20 normalized input). From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 9 18:48:24 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15175 for ; Sat, 9 Oct 2004 18:48:24 -0400 (EDT) Received: (qmail 16273 invoked by uid 605); 9 Oct 2004 22:48:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16260 invoked from network); 9 Oct 2004 22:48:18 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Oct 2004 22:48:18 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6700140; Sat, 09 Oct 2004 16:48:17 -0600 Message-ID: <41686AB6.60302@vandyke.com> Date: Sat, 09 Oct 2004 16:48:22 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> In-Reply-To: <467630000.1097251530@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman wrote: > > > On Friday, October 08, 2004 13:28:45 +0200 Niels Möller > wrote: > >> Joseph Galbraith writes: >> >>> Here are some possibilities: >>> >>> 1. Let the server say what it is going to use, >>> UTF-8 or 'undefined-raw' at the beginning >>> of the sftp session. >>> >>> pro: simple. really simple. >>> con: Doesn't address cases where the server >>> might be able to do utf-8 for some file >>> systems (ext-3 under fedora, I think is >>> one example) but not others. >> >> >> I'd much prefer the simple way. Just let the server say what character >> set it uses, and do no conversions at the server end (a server that >> really knows what it is doing MAY handle a file system with mixed >> character sets by converting them to and from utf-8, and use utf-8 >> exclusively on the wire, but I don't think that is very practical). >> Some possible values are "unknown", "usascii", "iso-8859-1", "utf-8", >> and "utf-8-with-normalization-form-c". > > > So far, so good. Note that the appropriate set of possible values is > that contained in the IANA Character Set registry > (http://www.iana.org/assignments/character-sets). When a character set > in that registry has more than one name or alias, the alias designated > as "preferred MIME name" SHOULD be used. > > But see below... > > > >> (Note that utf-8 with undefined normalization is suboptimal for >> filenames and for identifiers in general). > > > Yes. I'd normally argue that in any case where UTF-8 will be used on > the wire, it probably ought to be normalized. However, the key issue > here is not really normalization of names sent by the server but of > those sent by the client, which refer to the names in the filesystem. > Unfortunately, there are filesystems that use unnormalized Unicode, so > the server would be required to do path processing itself, normalizing > all the names in each directory until it found one matching what the > user requested. That's going to get unwieldy real fast, I think. > > >> I think the typical unix filesystem uses usascii for all "system >> files", and then has some home directories with iso-8859-x names, some >> with utf-8 names, which all include usascii. (I admit that I don't >> have any experience with asian unix installations). Then it will work >> reasonably to set the advertised charset from the user's $LC_CTYPE. > > > I would expect this to be more or less the case. In fact, I'd expect > that on most systems, most users will be using the _same_ character set. > > >> There will naturally be some difficulties if different parts of the >> filesystem tree uses different character sets, or if there are single >> pathnames that use components (directory names) with different >> character sets. However, those difficulties are precisely the same >> with *local* access to the file system, so it makes absolutely no >> sense to try to solve them in the sftp spec. > > > I agree -- solving that problem is beyond our ability, and I do not > think it is worth the effort to try. > > > > There is one thing I'd do differently. Whenever possible, I'd prefer > that the server not just advertise the character set but actually do the > conversions. The theory here is that the server is likely to have at > its disposal the tools needed to convert between Unicode and any other > character set in use on the server. The _client_, on the other hand, > can only reasonably be expected to have those tools for character sets > in use on the client. When these sets are disjoint, interoperability > demands the use on the wire of a common character set (i.e. Unicode). I would definitely prefer to see the server do the translation when it can... that's why we went to UTF-8 in the first place. If the server knows the charset, it should just do the conversion. For example, Windows systems don't know about EUC-JIS (for Japanese encoding), they use an alternate encoding call Shift-JIS. So the server can easily translate from EUC-JIS to UTF-8, using built-in os support (if it is using EUC-JIS anyway.) There has to be custom code written on the client side though to do the conversion. That is yucky. So it really is better for the server to do the translation. The problem is if the server doesn't (really) know the charset, and tries to do the conversion anyway (as would happen, for example, using the users LC_TYPE). In this case, the conversion loses data, and can not be reversed. This means that the client not only can't display a meaningful filename, but it can't even open the file by sending back the garbage name (because the server can't reverse the conversion.) So, what I'd like is a way for the server to convert what it can, and to give the client something that can be used to open files even if it can't convert them. So... how about the following-- 1. A extension the server sends to advise of the charset it thinks is most likely in use (probably from the users LC_CTYPE under unix, windows will probably just always send UTF-8.) By the way, how does one get a charset out of the iana registry from the users NLS environment under most unixes? Is it a simple thing to do? 2. An extension the client can use to control the translation on the server; something like translation-mask: SSH_TRANSLATE_KNOWN 0x00000001 Translate files with a known charset. If the translation fails, use the rawname instead. SSH_TRANSLATE_GUESSED 0x00000002 Translate files if the server has a reasonable idea what the charset is, but doesn't know. (For example, using the users LC_CTYPE.) If the translation fails (an invalid character for example) the server should use the rawname instead. SSH_TRANSLATE_INCLUDE_KNOWN_RAW 0x0000004 Include the rawname as an a part of the attrib if charset was known, and translation was successful. (If translation was unsuccessful, the rawname is sent as the name.) (New attribute field SSH_FILEXFER_ATTR_RAW_NAME.) SSH_TRANSLATE_INCLUDE_GUESSED_RAW 0x0000004 Include the rawname as an a part of the attrib if charset was guessed, and translation was successful. The initial mode is SSH_TRANSLATE_KNOWN|SSH_TRANSLATE_GUESSED. 3. Allow the server and the client to prepend a 0xFF to any filename to indicate it should be passed down to the system APIs without further processing. The thing this does is allow most clients to continue to operate as they do under sftp v4 & 5, except that if the translation fails, behavior is well defined and there is a way to open the file, even if the filename can not be displayed correctly. If a user runs into trouble, they can set INCLUDE_GUESSED_RAW, or turn off TRANSLATE_GUESSED. Okay... after all that, I've just realized that the per-file tag for rawmode is more complicated than I thought-- it has to be per path component. Rats. I really wanted to be able to rely on the server as much as possible and only punt the exceptions to the client for processing... and the client wouldn't really process them, because it would know it didn't know the charset (cause if it was the one the server thought it was, it would have worked on the server side.) It would just use them as opaque handles to at the file contents-- or the user would have to manually intervene to display the filename. Argh... well, I'm going to go off an think now. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 10 00:44:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28713 for ; Sun, 10 Oct 2004 00:42:50 -0400 (EDT) Received: (qmail 11708 invoked by uid 605); 10 Oct 2004 04:42:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11699 invoked from network); 10 Oct 2004 04:42:45 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 10 Oct 2004 04:42:45 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA07434; Sun, 10 Oct 2004 00:42:44 -0400 (EDT) From: der Mouse Message-Id: <200410100442.AAA07434@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. Date: Sun, 10 Oct 2004 00:41:18 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer In-Reply-To: References: <63D30D6E10CFD11190A90000F805FE86051AC8BA@lespaul.process.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Your impression is correct. Many text files on VMS do not store the >> line break sequence. > Is it possible for a VMS application (in particular, an sftp server > on VMS), to reliably figure out wether or not given file is a "text > file" using this record format, or a binary file (whatever that means > on VMS)? Yes. Or at least, it was back when I used VMS (>10 years ago). I would assume that things haven't changed that much, but that's an assumption. It would mean VMS-specific code in the daemon, of course. /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 10 01:50:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01784 for ; Sun, 10 Oct 2004 01:50:43 -0400 (EDT) Received: (qmail 14359 invoked by uid 605); 10 Oct 2004 05:50:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14350 invoked from network); 10 Oct 2004 05:50:41 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 10 Oct 2004 05:50:41 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA08059; Sun, 10 Oct 2004 01:50:40 -0400 (EDT) From: der Mouse Message-Id: <200410100550.BAA08059@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. Date: Sun, 10 Oct 2004 01:41:06 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... In-Reply-To: <467630000.1097251530@minbar.fac.cs.cmu.edu> References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> [...filenames...UTF-8...character set...conversions...] I see a philosophical problem here that I suspect is at the root of many of these difficulties. What are file names? On most Unix variants, file names are opaque octet sequences (with 0x00 octets not permitted and 0x2f octets permitted only as component separators). (Some very old variants also forbid octets 0x80-0xff.) Note that they are not character sequences. Interpreting those octets as characters is something done only for human-interaction purposes and is done using whatever character set the display device is using. Thus, even _contemplating_ doing character set conversions anywhere is, from a Unix perspective, a grave mistake. However, other systems complicate matters. I have seen it said (with what truth I know not - I am no Windows geek) that Windows filenames are sequences of Unicode characters, or more precisely sequences of Unicode codepoints, from which perspective character set conversions are perfectly reasonable. I see no good way to cater to both philosophies other than either to have a bit indicating whether a given filename is an octet sequence or (an encoding of) a character sequence, or perhaps to have a character set indicator but with a special value reserved to indicate "raw octet sequence". Thoughts? Agree? Disagree? /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 10 01:57:23 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02039 for ; Sun, 10 Oct 2004 01:57:22 -0400 (EDT) Received: (qmail 17525 invoked by uid 605); 10 Oct 2004 05:57:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17516 invoked from network); 10 Oct 2004 05:57:21 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 10 Oct 2004 05:57:21 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA08116; Sun, 10 Oct 2004 01:57:19 -0400 (EDT) From: der Mouse Message-Id: <200410100557.BAA08116@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. Date: Sun, 10 Oct 2004 01:53:05 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes (fwd) In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > And still further in the document, we define "pty-req" as a specific > 'channel type'. That doesn't sound right. I thought it was a channel *request* type. As I read it, the defined connection types are "session", "x11", "forwarded-tcpip", and "direct-tcpip". At least in connect-19. Note that "pty-req" is listed in assignednumbers-06 in 4.2.2.3, not 4.2.2.1. /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 10 18:56:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21515 for ; Sun, 10 Oct 2004 18:56:20 -0400 (EDT) Received: (qmail 960 invoked by uid 605); 10 Oct 2004 22:56:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 951 invoked from network); 10 Oct 2004 22:56:15 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 10 Oct 2004 22:56:15 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1CGmbu-0008Ck-00 for ietf-ssh@netbsd.org; Sun, 10 Oct 2004 23:56:14 +0100 Date: Sun, 10 Oct 2004 23:56:14 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer Message-ID: <20041010225614.GA30626@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: <000001c4acdf$002f97a0$6302a8c0@Nucleus> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list denis bider writes: > I would like to note that checking whether the file is textual or not > is a cheap operation only on VMS. > > Defining the text/binary hint as a file attribute makes it less likely > that Unix and Windows servers will implement this. My intention in defining the attribute extension was to support those servers which have a reasonably authoritative text/binary distinction, for example in the filesystem, rather than those which have to use a heuristic approach, such as Unix/Windows, where I would much prefer that UNKNOWN is returned rather than a guess made. > I think we would benefit if it were possible for a client to query the > likely textual or binary state of a file independently of anything > else. In other words, without obliging the server to either show this > possibly expensive information as part of regular easily-obtainable > attrib-bits, or not support this feature at all. > > I think the attribute hints are a nice idea and will work for VMS. > However for Unix and Windows servers, we might also benefit from a way > for the client to prompt the server to determine on the fly whether > the file is textual or binary, if the server has not indicated the > file type in attrib-bits. This query would be done right before > downloading the file. I'd prefer any such extension to be optional, and to have defined semantics of being heuristic rather than authoritative if that's how it's implemented; as a client (or rather client user), I would like to be able to distinguish heuristic from authoritative information so that I can choose not to use the former while still getting the benefit of the latter. (Perhaps the extension could have a flag indicating whether it contains "authoritative" information?) I should come out and say that my personal view is that I'd rather not trust the integrity of my files to text/binary distinction heuristics, which is why I'm pushing for this distinction. I realise this isn't a universal view, but I don't think I'm alone in this; it's a popular feature but I'd rather it was possible for the end user to choose whether to use it. > However if there was widespread server-side support for a query to > determine file type, the detection and conversion algorithms could be > entirely removed from the client. Except that the client would need to convert from canonical form. I agree that if you're going to do file type detection on server->client transfers, it's better to do it on the server. (Clients will also need to have some means of file type detection for client->server transfers if they don't have that information to hand.) > My thinking is, either we require Unix and Windows servers to > implement both (a) conversion - SSH_FXF_TEXT flag, AND (b) file type > detection; or we should require them to do neither. [...] > The idea is, let's be consistent, and let's not specify things halfway > through. I don't think there's anything inconsistent here. The server may not know _which_ files are text files, but it could well be in a position to know what the likely line ending convention is if the user asserts that given file _is_ a text file, which is a better position than the client is in; in such a situation the server should convert to canonical form iff requested. This is the position I see simple (non-heuristic) Unix/Windows servers as being in. Given the which, having no text-hint-attrib-bits support and yet having SSH_FXF_TEXT support does make sense; it leaves you in the similar situation to plain FTP (or SFTP before this extension) of the user having to decide which are text files, which is IMO where you should be (or at least have the option of being) with such servers. That said, I wouldn't object to making SSH_FXF_TEXT support optional in general. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 10 22:25:23 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04591 for ; Sun, 10 Oct 2004 22:25:23 -0400 (EDT) Received: (qmail 20973 invoked by uid 605); 11 Oct 2004 02:25:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20964 invoked from network); 11 Oct 2004 02:25:18 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 11 Oct 2004 02:25:18 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2004 19:31:09 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9B2PBYJ021530; Sun, 10 Oct 2004 19:25:11 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA18646; Sun, 10 Oct 2004 19:25:15 -0700 (PDT) Date: Sun, 10 Oct 2004 19:25:15 -0700 (PDT) From: Chris Lonvick To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes (fwd) In-Reply-To: <200410100557.BAA08116@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200410100557.BAA08116@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Sun, 10 Oct 2004, der Mouse wrote: > > And still further in the document, we define "pty-req" as a specific > > 'channel type'. > > That doesn't sound right. I thought it was a channel *request* type. Doh! You're right. "pty-req" is defined as a value for 'request type' in a SSH_MSG_CHANNEL_REQUEST packet type in [NUMBERS]. > > As I read it, the defined connection types are "session", "x11", > "forwarded-tcpip", and "direct-tcpip". At least in connect-19. Got it. Those are the values for the 'channel type' in SSH_MSG_CHANNEL_OPEN packets. > > Note that "pty-req" is listed in assignednumbers-06 in 4.2.2.3, not > 4.2.2.1. Yup. I'm going to duplicate the tables from [NUMBERS] into [CONNECT]. I believe that I got confused from this paragraph in [CONNECT]. Many channel types have extensions that are specific to that particular channel type. An example is requesting a pty (pseudo terminal) for an interactive session. I made the intellectual leap that a "pty-req" was a 'channel type'. Thanks for the corection. :) As far as the pointers in [NUMBERS], I'm going to make sure that all else is straightened out and then I'll go back and get the pointers straight. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 10 22:48:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06083 for ; Sun, 10 Oct 2004 22:48:12 -0400 (EDT) Received: (qmail 3143 invoked by uid 605); 11 Oct 2004 02:48:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3131 invoked from network); 11 Oct 2004 02:48:10 -0000 Received: from ajax.cnchost.com (207.155.248.31) by mail.netbsd.org with SMTP; 11 Oct 2004 02:48:10 -0000 Received: from Nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by ajax.cnchost.com id WAA25748; Sun, 10 Oct 2004 22:48:09 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Subject: RE: Text file type hint proposal for filexfer Date: Mon, 11 Oct 2004 04:47:56 +0200 Message-ID: <00be01c4af3c$b76dee30$6302a8c0@Nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20041010225614.GA30626@chiark.greenend.org.uk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hi Jacob, all, I think you are right on all counts. I agree that attrib flags for text files are OK as proposed. About server-side heuristics, I agree they would need to be optional, = and if they're optional the client cannot rely on their presence, so they = wouldn't be very useful in a general case. Also, a client supporting auto-mode = transfers would need to implement heuristics and conversion internally anyway for interoperability with currently existing servers. (Note - when I say a client supporting auto-mode transfers, I do not = mean a client not giving the user a choice. Auto mode is usually accompanied = with text and binary choices. However, I believe that a user will mostly prefer = the program to make the right decision for him if it can, and will choose = auto-mode most of the time.) If the attrib flags go through though - and I hope they do - I would = like to propose this addition: Files not advertised by the server as textual in the attrib flags MUST NOT be opened with the SSH_FXF_TEXT flag. A server MAY fail textual open requests for files which were not advertised as textual in attrib-flags. This simplifies the server significantly, and does not affect the = client. The assumption for this proposal is that on platforms where file type (text/bin) is not determined (Unix, Windows), line endings are LF/CR or = a combination (CRLF, LFCR), and the client can convert from any of these = formats into its native format with a simple filter (interpret the first LF/CR = as line end, discard complementary CR/LF if follows - this algorithm could be = mentioned as a good solution in the spec BTW). My above proposal is ill-conceived only if there is a platform where: * file type (text/bin) is not determined, and * line endings are not one of LF/CR or a combination (CRLF, LFCR). If anyone is aware of such a platform, please let me know. If there = isn't one though, I suggest the server shouldn't have to support SSH_FXF_TEXT if = file type isn't determined. The client can read binary and convert line = endings if it so pleases. denis > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Jacob Nevins > Sent: Monday, October 11, 2004 00:56 > To: ietf-ssh@netbsd.org > Subject: Re: Text file type hint proposal for filexfer >=20 >=20 > denis bider writes: > > I would like to note that checking whether the file is=20 > textual or not > > is a cheap operation only on VMS. > >=20 > > Defining the text/binary hint as a file attribute makes it=20 > less likely > > that Unix and Windows servers will implement this. >=20 > My intention in defining the attribute extension was to support those > servers which have a reasonably authoritative text/binary distinction, > for example in the filesystem, rather than those which have to use a > heuristic approach, such as Unix/Windows, where I would much=20 > prefer that > UNKNOWN is returned rather than a guess made. >=20 > > I think we would benefit if it were possible for a client=20 > to query the > > likely textual or binary state of a file independently of anything > > else. In other words, without obliging the server to either=20 > show this > > possibly expensive information as part of regular easily-obtainable > > attrib-bits, or not support this feature at all. > >=20 > > I think the attribute hints are a nice idea and will work for VMS. > > However for Unix and Windows servers, we might also benefit=20 > from a way > > for the client to prompt the server to determine on the fly whether > > the file is textual or binary, if the server has not indicated the > > file type in attrib-bits. This query would be done right before > > downloading the file. >=20 > I'd prefer any such extension to be optional, and to have defined > semantics of being heuristic rather than authoritative if that's how > it's implemented; as a client (or rather client user), I would like to > be able to distinguish heuristic from authoritative=20 > information so that > I can choose not to use the former while still getting the benefit of > the latter. (Perhaps the extension could have a flag=20 > indicating whether > it contains "authoritative" information?) >=20 > I should come out and say that my personal view is that I'd rather not > trust the integrity of my files to text/binary distinction heuristics, > which is why I'm pushing for this distinction. I realise this isn't a > universal view, but I don't think I'm alone in this; it's a popular > feature but I'd rather it was possible for the end user to choose > whether to use it. >=20 > > However if there was widespread server-side support for a query to > > determine file type, the detection and conversion=20 > algorithms could be > > entirely removed from the client. >=20 > Except that the client would need to convert from canonical form. > I agree that if you're going to do file type detection on=20 > server->client > transfers, it's better to do it on the server. >=20 > (Clients will also need to have some means of file type detection for > client->server transfers if they don't have that information to hand.) >=20 > > My thinking is, either we require Unix and Windows servers to > > implement both (a) conversion - SSH_FXF_TEXT flag, AND (b) file type > > detection; or we should require them to do neither. > [...] > > The idea is, let's be consistent, and let's not specify=20 > things halfway > > through. >=20 > I don't think there's anything inconsistent here. >=20 > The server may not know _which_ files are text files, but it=20 > could well > be in a position to know what the likely line ending convention is if > the user asserts that given file _is_ a text file, which is a better > position than the client is in; in such a situation the server should > convert to canonical form iff requested. This is the position I see > simple (non-heuristic) Unix/Windows servers as being in. >=20 > Given the which, having no text-hint-attrib-bits support and=20 > yet having > SSH_FXF_TEXT support does make sense; it leaves you in the similar > situation to plain FTP (or SFTP before this extension) of the user > having to decide which are text files, which is IMO where you=20 > should be > (or at least have the option of being) with such servers. >=20 > That said, I wouldn't object to making SSH_FXF_TEXT support=20 > optional in > general. >=20 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 05:37:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17817 for ; Mon, 11 Oct 2004 05:37:53 -0400 (EDT) Received: (qmail 24528 invoked by uid 605); 11 Oct 2004 09:37:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24513 invoked from network); 11 Oct 2004 09:37:38 -0000 Received: from srv04.zergon.net (67.15.0.20) by mail.netbsd.org with SMTP; 11 Oct 2004 09:37:37 -0000 X-ClientAddr: 127.0.0.1 Received: from srv04.zergon.net (localhost.localdomain [127.0.0.1]) by srv04.zergon.net (8.12.10/8.12.10) with ESMTP id i9B8X2ob010349; Mon, 11 Oct 2004 11:33:02 +0300 Received: (from apache@localhost) by srv04.zergon.net (8.12.10/8.12.10/Submit) id i9B8X2ZT010347; Mon, 11 Oct 2004 11:33:02 +0300 X-Authentication-Warning: srv04.zergon.net: apache set sender to roumen@roumenpetrov.info using -f Received: from 213.91.169.3 (proxying for 192.168.15.67) (SquirrelMail authenticated user roumen@roumenpetrov.info) by srv04.zergon.net with HTTP; Mon, 11 Oct 2004 11:33:02 +0300 (EEST) Message-ID: <60196.213.91.169.3.1097483582.squirrel@srv04.zergon.net> Date: Mon, 11 Oct 2004 11:33:02 +0300 (EEST) Subject: Re: SFTP and unicode file names... From: roumen@roumenpetrov.info To: "Joseph Galbraith" Cc: ietf-ssh@NetBSD.org Reply-To: roumen@roumenpetrov.info User-Agent: SquirrelMail/1.4.2-1.7.ct MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20041011113302_59241" X-Priority: 3 Importance: Normal References: <4162D042.3010305@vandyke.com> In-Reply-To: <4162D042.3010305@vandyke.com> X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list ------=_20041011113302_59241 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > Okay, I've been forced to face up to the unfortunate truth: > > Unix directories can contain files encoded in multiple > different char-sets and the server has no way to tell > what these multiple char-sets are and translate them > to UTF-8. Because the transformation is one way, once > the server has mistranslated the filename, there > is no way for the client to get back to the original > data. > > So, for these file-systems, the best possible thing > to do is send the filename raw and let the client > (with help from the user decode it.) > > On the other hand, maximum possible interoperability > between different language and regions is obtained > through use of UTF-8 where available. User can use cat/type/ls/dir to access a local file and it should be able to do same with SFTP. As example "echo 'get ' | sftp localhost" should get same file. In all cases should be same and is encoded in user charmap(charset/codeset/etc.). > > I haven't been able to come up with a solution I > really like. > > Here are some possibilities: > > 1. Let the server say what it is going to use, > UTF-8 or 'undefined-raw' at the beginning > of the sftp session. > [SNIP] I'm not sure that server is responsible to do decision for encoding: 'UTF-8' or 'RAW'. Since in a SFTP session client can request more that one file negotiation of file name encoding should be at begining of session. Client should request encoding from server. I guest that a new extension "encoding" will solve problem: 1.) Client send to server list of accepted encodings and server return prefered one or "RAW" or "UTF-8". To do this sftp implementation MUST implement extension "encoding". Extension should be defined in draft as "newline" is defined. I not sure that sftp can use names like "ascii", "usascii", "C", "POSIX", "ANSI_X3.4....", since ascii define only 7 bit charset. When SFTP server support 7-bit encoding is should(must?) reject file names containing symbols with code greater that 127. When encoding is not set server should treat filenames in "raw" or "utf-8" format. This must be annonced in "Server Initialization". Empty "encoding" is alias to "RAW". When encoding is set server must convert "local filename in encoding" <-> "wire filename in utf-8". Client may convert "wire filename in utf-8" <-> "local filename in encoding". Note that client know name conversion on the server. I guess that this solution is interoperable with SFTP clients version 1, 2 or 3. For version 4(four) clients, when server support encodung it should announce 3(three) as maximum version. For client version 1,2,3 server must use "RAW". Server version N(N>=5) must support "UTF-8", "RAW" and "ISO8859-1" encodings. Server version N(N>=5) may support "ISO8859-N" encodings, where N is in range 2-15. Client version N(N>=5) must support the "UTF-8" and "RAW" "encoding" extension. P.S.: As esample cyrillic use many encodings. Most popular are IS08859-5, KOI8-R, CP1251. In case of cyrillic one utf-8 file name in cyrillic can address different files on file system and this depend of encoding. In this case SFTP client with help from the user is responsible to select correct encoding. This is same case as access to local file system. I don't have problem to adress correct file name on remote host. My system is properly setup and I can use UTF-8, IS08859-5, KOI8-R and CP1251 in file/directory names and in GUI termininals. For the test in directory $HOME/tmp/cyr I have four files with name in format f.., where is one of mentioned above and is first three leter from cyrillic alphabet in uppercase followed by same leters in lovercase in same encoding. Content of each file is "data.:" where and match the file name. In four xterm for every encoding I run same command sequence. Results are attached images in "ssh_session.UTF-8.png", "ssh_session.ISO8859-5.png", "ssh_session.KOI8-R.png" and "ssh_session.CP1251.png". With command "echo get tmp/cyr/f.*. | sftp localhost", where sftp is openssh SFTP version 3 client, file that I get depend of my locale charmap. Regards, Roumen ------=_20041011113302_59241 Content-Type: image/png; name="ssh_session.UTF-8.png" Content-Disposition: attachment; filename="ssh_session.UTF-8.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAApsAAAFpCAIAAABcQnS8AAAgAElEQVR4nO3dX6gk133g8V97e8zp 4cp0Dxpz20hB19igUZwlIwjEIoFIxA+WycNK7D7I8YOt5CGaiJBo431xIMlqyUOkNSw7Xtgg5SHI CwlSHozsB4VRQEEKZJlZ2M2MIcIt1kI9WOJ241ymD1Gzdx+qu6bu+Ven/nVXV38/iNKZ6lOnTv25 derUqTqnd3p6KgAAYIOuvXHtsS89JiJX//NVORhKX8lSq77SS106/IltbxQAAHtnsVysQn1RfSUi qq+0VAr3Zx/O9FKrvpKlSF+aC48ujpLMz/5Zph/NZKnnJ3q9aUpEnw0Q3npYpC9DNRwdyPjekZxb zZtNZ42eJzsflnWgLyM1koEAgG3QX18dlquLRlLbrhLuffDBB0qUFm1MR+NR7RuwWMjk/entuVZ9 0UvJTkXEnsm0LVORS/cdji9SOgHAll19+dWk7mVPe8cfHBvF+Xg8biIT0+lscnvuKzNEtl1oMc2b Hg7V0X3jAcU6AGzb1ZdftdvRz9TRs/Xy6s/G9VIrpS4/OB6ck8mPZ5Pbc5GF3H0K6QznRiC8sbDj V9UfXH7waDCQ6YezyXtznXmyIiLtaCwgTJgw4S6FRUSUUtKX8XA4HA4G5+7ON+rrn7CL88VCbv7T 9MYPJ/P5/PZci4heiojopU4D2Zm+sOrLpfuGg3Mymy0mt+ciojKlhTOcG4HwxsLOX/VSbr03FZHx xZH0Vw/kk0Jdok8MwoQJEyYcHRYRmZ9ofaJvvXf7xv+ZTKczWXv8S4/ppVbrRT6R/C8tzqfT2Y0f TpxN3apf7DmtiIxGAxG59d7txXIhS5ktF7IUZzg3AuENh32/Tuez6YcLETk6PJydLGRZ4JRgypQp U6YVp5Pb8+u3pvKxiMjR/aPLX3xEiySv5faOPzjWSz2+fyxiPBtPXqxPAoPDe9V4OBypQfLbdL6Y nSQ1+DSyOT06HB/dP5rNFm//cDKQwUIWgamIhCMY0+/88e9LXx64/4GH7nvohT974fn/8tJQHcqB ZOO8+dcvv/I/Xvmv//11OZBRf2Sk8JUvPiQi196ZJHMe++KRiLz+zk1jXcb8dKlkvu31d24mcbLS tRhr9/3a8qlS8sjlo8VCrv39zYES1R9o/2nAlClTpi2fXnpgODwYDfqyWEp4Oj+Z3XpvbqRw6YFx 8cWl4tpVXx75wlHyFdJL33tbTyeqr3of/N8PkuJ8NlvcePe2XUQND9ToYDg8kNHBYKEXeil6mfyi tZbZSbah/YxLDxyOLw6u/9N0+tEs+bwnNJW8CNb0tT9/8dLnLo3uHV36/KVv/fG3vvqbzw0vjpPG BlnKjTdee+kvXvr3f/SC6qvs/HSalKlf+XdPP/O7z8lSvvLL638++1w2pjE/u9R3vv2iiLz+ly8l c+4W6tYcEUnWYqSZRn79nZuFtn3r08d+/qHBYJXtQV8k/QwDAHbNpQcOxweDhchgIIuPk8/JFiID WS5k/dxbkhfQRN96b96SxZWSR37uSEQmP559/60bomd3e5hJn42n08VyofpqpJRSotRAzsngnoHq D9Td16BEKaX6amE9rV0sF+PhQET0XK8K7KWIDLzh3AhW+OFfeWKu50f3H6mhev2116//3ffnH071 idZa33jrtZf+4qUrv//8QoucW7/udzad19+aSFKgni1iHRlbWc9fp/bMs8898+xz6Yxnnn3umWe/ Zc1J/vuWM81nnv1WEvjOt18stO0bCYd+1ScLERkdjLTWIgPnCcCUKVOmOzGdnejpyUJrWSxkcE4G fRmpwUjJ6GCg1GCoBiKSvE8+O5GFXhgplFi8lrXrE5l+OBORo/tXxdwn0gr6TJsPVwcySFrZVV/0 ciEfi3wsA7UqjZJX2UW0Xmr3g/RzIiIzffcuQy+94dwIdvjw4mj8wBcnP55cuu/SYDR44Y9eePtv X5tMp5Mb1177i9eu/P7zWmR0MFJKKaWc6bz+1k2RM8X5M88+Z69rvb13w+s5Ys1xx4lJs9C2byQc +nWuVyeGLPViuf2GAKZMmTItPb390TS5xGm9WHwsqw61zomIDPqik4fkSy2ibn80n8/nRgolFq9r 7ZP3V1X2R3/h0mK57gV28tFcRBbLRXaa3AgkxeHqnedzIiIjNVB9kaVorUcHQ1nK7GRhL54t1XJb +0u8ICD94eF4rPuH1/7+2mK2uPX+rfmH88HJey//2ctP/NYVvZTxcKjuGQ6HKpBO1jPPPudYy5oR 304hMMeYvvrmTRF5/S9fevLRuzcTbXjhIn46nWsRGd87TLbXPvRMmTJluivT2VxkuSrUZCmSFKvr wlXJQGudfCA2m8/0UhspOBfv9Xq9T/Z8i/vWfv6TvV6vl137hU+d/8ynz/vWPjtZLBYiIg89MJ68 f2tVop99Nr6avnd7PhwqLVqWq9uExcciIgsRtW431UutlNyez+3FVxG0jplGRjsz7YuIDC+Ob031 7du3r3776uNffnxxslicLObzmVJKDQZKqXA6WeE4vvi+OUmB/ZVffujJRx8y0kwL8rQp/Ru/9VyZ PbC96VCJiExu306PneMEYMqUKdNdmE6mt0VkdjLXqzZsSYrJZJoUf7OTuYiaTB2Fnb14r9cTERHp fbLnXtyz9tVSvV6y9uSeILz2+clCROSciJZViT49WYiI8T3cdDYbHSgl6jOfOX/hU+d7n+yd/2Sv 98ne+fO985/qffZnLnz2Zy4oUcMDNftQa63Xi99NRGT19D9/GhnNmCql+vLkow8//6fPHz14NPto Nnl/8vDPP3z1T/5AtNYSkUKWM47xa8pO4eycpMBO/nv5z6460/zGb60a3V/+by+W3ANbmg6UWp1P HzvOHMKECRPeofD8ZKGXWkQtliLLwWIpA5HFUiSZLgeLpYgovdTzM2XlKh1j8bQYTlz41Hl78Wwe sosfH69GQ02K2iT8jz86Dqz9+g8nSTS91KsSPfk+XUnygH0Vnn40V33RS/2jHx2Ly49+dKyXenCg JvPp/GSukn7i1oms1tFcHV1En+jHvnB09dtXjx58ZK7V5P2Jnmst+olffeIP/sNvzD6caq31iTeF J7/0sGTeOc/Of/LRh5780sNV6ugi8o3fvPLU168kUxFJ0kwq6Hb8NtS846eLJOer7nvNM4cwYcKE dyg8nc+TS5kkleyk+w1ZhddTLSLT+Vx/vDAKu+ziFy6cKc4TP/vZC8bi2TwYa7/z0zNDnH/wkzvh tSc/iYjqr+voyQ1CpuRXeqn1UrQW1VcL0R/85I6RxePjOwsR1VezudYnsl5lNhERWTfD97ON2Y5w bgRHWMvjv3j04p++OHzwshY5PByPH3xEDZWIzJfzx3/18T/4nV+ffjiVpU62wkjnq1++W5y/+sZ1 Efnqlx9O4rzyg+tJ3fq7f3413V5XG7my5rjjJPNffeNm+qQ9TdNIv8x+aCoc+nVwoERE66T3QfPM IUyYMOFdCuv0gpz0v7ZQMshMRWQ9sqIWWb0zfjed7OLiYSx+Jg/W2s8smLd2Wdeg9VI+cXepu5FW YdVX19+bJnNmJ/o4U6gf//RUL5PX8PTk9kyfTPViYSQymy3WuVxV7OaZSp4Rzo1gh7/6Kw+/+O0X 1QOXRMtwOBwMh+Px+OgLjz1w/wPD/nBVU/+dX59MJ9qVfuqpr1+Zr+d898+vJuGnvnblqa9feeJr T7/yg+uSNIp/6eHsTYCdTpp+lrFeO800wULbvoFw+NfksE7ns7Onl+MsIkyYMOGWh6fzueqLFpG+ 0pKUmou709V8rfoync9laRZ22cU/+Mmd4+PT4+M7xz89PT6+c3x8+sFP7vzjj47NxTN5MNZ+4cL5 bCFy4dPnw2uXpV6V4n2VraOb06N7R9f+4Zbqq0FfBiLzpU4e8d+5cyqySF5QV6Ku3bilJOk19szi Sc8zR4djWSajR0tmJGkrnBvhbPirv/rw83/yvLr3kixF3TscjMbDe8aqPxxdHI+/8Njw/qGsa+r/ 6bnfmM1mdjpJRVxkNf+V711fv3Nuriutsqc17Ke+fsWXjmTmBPKfTVNEnvjalfht30w48Ksk/bqL TG7dElkkA/T6ziKmTJkybftUi17KSCkR+cynz1+40Ltw4fyFT/UuXDh/4ULvM58+/7OfvTBSKnlu badQYvHA2kVERJJ7giQcXrus6aXuZ/4hIqt355Lw0f3DG+9OXvu7G0/80iUtIkvRenZ8fCd5FjGX hfTV9KP5m/9z8vjnlJaBOpvIzfenR/ePxofqxg+TtSq9evTvCItIOIIRfulv3tb3Hono4fBwcM9A rW5hlIiMhmP5wmOj++YzPRMZXPniY7LafWY6T33tipbVTlGinvja0771PvG1K7IebTY3nTT+enfH pCnx276xsO/XS/et+gzWWid19FVh7zqLCBMmTLjl4fl8lnSIOci0hJr6okTm89li+cDwbDolFs/m wV78+PhO0mfcnZ+env9UL7z2VVjMdnTrvmOpLz94+NL33n7t724l1WhZtacOktRf+9sbv/Enrwxl rg5GamBW1OZzPZstRvcMju4bqcxTAmc4N4IdPjo6Ovr85dHF0VANJS1o+0oNZHz/0dGlS4/8wmMP X7586ee+OBqPS6S/5+HAr5c/dyQi19+dDg+GInK2HZ0pU6ZMd2y6WIisnxZ/8JM7H/zkzvHxndWT 85+e3rlzenx8J6kxrr5nO5tCicXDaxcRkYX0B1okd+2yptN29PVbc2k9TJKX8cYXR4///NFLf33t t7/93e+/eevWe7dlKTfenb72N9d/+9vfvfryK0M9uXyfGt97KH1lJaJvvXdbRB75wlH6UrSIzDP5 SMPOmYS3GPb9eulz48E9MplM33nrTd0Xde7u4XaeRYQJEybc8vBcz+2GY70UrReyXOjlQqmB6os6 GM31fL3U3XRKLJ7NQ8W1Z+roqnd6eioiL/312+uvjZPW33Vje19Ey2w2e/N/3Zj8eD49Eb0U1Zdh fzY+UEcXB8N7D8f3HY0ujpQaylLbiTz+i5fH48Hin+W7f3tdliLJE2YRJcoIO2cS3l7Y8eulB0aP XD4SkZf+6u3J5Nb48Ejdo1TSjp49cwgTJkx4d8Kv/ODGO/979VV32NFQnvq1R8cXR9l0Xnmj+OJJ 8boU6atXfvBOlbVLXz39aw+LyNO/9/y6RP/e9Ux5vJ6KrAJazxZ6fnsyO9F6Pk0u92o4Hh2o4eHR aKBEKXtxvdRKRPryxC9dHo0Gi3+W1/7+evK9eFJeKFH6btkh9kzC2w1n56i+uvyFo4c/PxaRV9+4 /s477xweHg4ORirp6L/vOAGYMmXKdFemsw+nk3dvzT+6HY45vPfw6HOXRhfHZ+aLFF48LV6rr32p n/43j4jIlW+uS/Srf/W2s8/zM//8WC/0QpY6mSN9NVADOaf8HYCvimrVV4//4qXRxYGI3JzMbr07 vf3hbTmn5GOtzin9sZZzSokkgexMwlsM3z00fTm6b/zFB48G94iIvPrGzWtvfX9875EaqtFgtG5P 2Wiv8kyZMmVa71REZrOZLLUs09qza9pXo9HILByl8OJ2CqXXrvqSlOiZOvpfvX2mXuaZSl6Es9NM he9j/egvXHrogXHS9fxiIZP3p9KX2x/pdHvacFCZplPpy/BgOFByNF6dfzcn0zffunXz3evje8fq YDhQAxFR59T6QMefGEyZMmXKtLbplX+b1NFfWNfRv3stqZ+th3zxhEVyIljhbOVveM/w8oPj8eFw dE923HG03eTHs+vvTq69cW1wMBgOD5VSSXF+9hAXOzEIEyZMmHBcOCdmUqLfraNf/e41EVmX9+IP 50a4G16IpOV2Ek66v5/p2fji+PDeoYiMh4MkvhZZtdcybcd0fjKbaT2f68k/3ZqdzEYHI+mr4YFK WlsWSxn0s4e4wIlBmDBhwoSjw/kxrzz1mIhc+ebzqw/apx9N1281ry7onrDkRciEV69Ar1rvdToV NZlMJhPRWiuR5GV9EX/LAdPtTkVGapScPvMTrfqiT+ZnDmhyiONPDMKECRMmHBeOiykiopeyKtFV X33rmSclWq+3qtwDAIBtef47r6bhM33GAQCAXbIuvlXaC2zSwxwAANgl/btP3dejqVJHBwBg12i7 ji7U0Tel1+vteQYAAHVRdh19d9vRe2vGnC1maVsit/r09HQ/9w8AdFBn2tGTV+4TaSnV5pfwjW8E aixZk6QoqgFgv3SjHZ0v6FLpnc22MwIA2KhsO/rqe/Qq7ehJvdCuJafznXGyP6VFkf2rvaxdbvkq pnZ859qL5seXeC5nBd1YRSA/ufshPj9JItwBAMCuy7aj99eh8nX0pHiwSwijjM8WSHYRZZcx6T+N 9H3RjHLdju9csER+AoybmHB8Z7EayE9gP4SLeQBAZ9l19Ort6OXKEmfFt5b0N58fuyR2/lolP845 2fnxa6GaDgBdYNfRW9KOXq7Ma+51sEL5ydaYm8mOF2UzAOynmtvRYzT6DvZWCrNCT7kjn9hX2ZAS T92ppgPArqu5Hd14wytbQhjN52mccGNwdvFs+mkEuwlcrIfevviBxCPzUyPf64S+tn/x72dp+LYJ ANBG9baj577/5Ytm/5T7/nb45buY+DGJxzw/jy/dw/XgQA5jtqgiKugAsNta245eQvvLpI3lsP27 AgBQL/p130n0CgcAMNTcjo7NoAoOADB1pl93AAD2Wjf6dQcAYM/Rjr4XaHEHgM7bsfHRy413Xm6p Kuk3vcZc9tfzFOoA0HG71Y5eSw/ttYvvcb0ESmIAQJR629G3XjcFAGA/1dyve2DAMR9f76rhXler DxjqG+/cGPXVmZ9CncT50g/Ml7N7styqDfTcDgDd1sj36PGjedrjjofnG7+WLqICA6vH3FJErjdy XHbn/HSldQ29CgDouCbGR09kh2bJjZP+Mzzf+c+G+IZFKZ1COGYtFfGYtVDYA0A3Ndeve2Th4av7 lqgTNyf8zKAWrdpeAMDOaeR79OT9uMjn0oXmb5gzG03kLTLN6qvmMzYA6KpGxkcvVL+MeVPMaNu2 xzuPSTzbOF30ab8xVGt6y+JLv9C47OH94BwlFgAA0ybHR4+PHzO/6CP9JlZdIp+5474X/bUobgsA oJvo1x0AgA6gX3cAALpgx/p1BwAAbrvVrzsAAHCjHR0AgA6gHR3oLPoeAPZKx9vRGQuuCYF+gTY8 Dn37U66CDoUAFNNcv+5tUNcVLXKAOPF0CGN0vOOLEJP58Nfkvvh27zfO7MV33OuM2XT50Vz67Sz5 6IcfQDH19utefZDTdrJHVk3CzhFXw8WDMx2xBqxzlrK5pY4vvt3nnZ2H7MB3zpQD/0RD2M8A4m1/ fPSicntRddZs7CzVPtaZsdI0G4E+awtVwopW12LiO4fGqffAFT1eRY9L6fhVzhP71s3Zv2/udhnp xJ8J8ZGp6AP7Y8vjoxdlpJmtXwYqsnY0Xzqlc1V62YTzCXbp9H3xN39xL3G8Ch2Xosex6Hniy89p pm//bM4Dj1hi0qHoBVDJdsdHLyHmyXPunIqrdj6Cbq4htmj6FfMT89S9Rs5acrzSmxl5ngTSD++T +O0qum9LxOdeAdgLWx8fvagtXpjCJaXvTbG6Mtz0db/6gtXZde7cRRrNbYn8NJoOAARseXz0hmzr jevcV9ONZUs0jcdH9uXHaNA18lMo/bo417uBzBRaRV35qZ5O8vdVaJHw25oAumH746MXYl+Ysu2R xsw0P/a7ab74PsZ7bfb7boHIRgTjdSpjKTm7D53px+QznP8sX34Kcd4WBPZzzPxsG3Nk+rmbUOU8 sfNj7DdjJxuN8c507C0KZD5+MwHsqe2Oj17jKpzzjReXYtKJTNx+3Sk3cnxWy2UyED+wH0qsJX69 kVnyzXe+nha/6vj4kedJOD/hmHWdijW+NwCga+jXHdgtlM0AnOjXHdiaoq0qQnEOwK+R79HRqPiX 7dFyHDIAdep2v+6dRDEAAHCgHR0AgA6gHX0Tmv4UuPOfGnd+AwGguo6Pj76ftlv+NbF2OkgBgHyd b0cv0S9bvQ3VTXefF5l+uFublLOn20LpAwC2g/HRu8TZ8VzCWc01ep43+jXLzg8fUwYCAYCt2+Hx 0X2lUXbV9ve+uSWTHd9ePNvTZzaOnbhd1Dnzb8w0woGOWo307f5HCylaFw9smh3ZXqTQeWIcbgCA YYfHRw88GbY7YI9M3xnfLnrTOUYf3YXqsvZ9g51nuw/wXGnH476yP3yTkTvfuZ994cBdFwCgZjs3 Pno2/ew/N1ZaxPeLHi6JC91nxKcf6HA+N31njV+CN1K5mRT/HUOJLtmppgOA186Njx6zrl2sC6bF VXP7rfpuKbefjbsBimQAaMJuj4/uLFECxUzRIq1KERizB5pO34icquWOp0Qi9mOVoonwGRsA+Oz2 +OjpiuwXyoymXCN+5Cqybecl2qHj85/91a4EF8q/zc5/+k9f+r75vv3s267cNxOprwNAbTo5Pnr1 9trclAOrk2AFulwLd3z6uYmEcx6eH1jcuUhM43pR3AQAgBv9ujehdGU6csFulGrd2AoAaAn6da/E fqrchqR2AsU5ANSL8dErqbFYooQDAFRi19E71q87AAB7gXZ0AAA6YLfb0Ztudd6fVu3Evm0vAHRJ F8ZHL9FRSTtXtLENAQB00O62o2f7kImJXDr9VNMvrxVKv/ayny7TAWC31duO3tpaJmUVAKDbdm98 9ISzQunsLTUwMzA6XHyF1biD2cytg7N3VbuzVaPn10Lba/T2mk3HWF022Yod1gIAStux8dEDnONz y9mbjGwOs32/l85q0bHI7Ajl1uscos0uetM5RbfX2JnOVdhhntsDwDbt4vjozpKjxFqq95oeHnkl fo1NiN9F4e0t3YE8AGCjujE++hYZdfTOb/Jp8+O4AwBK2L3x0X0p1/VGXqGct+Q1wCrZiNnelmwm ACBgx8ZHD6/UN863Ec6OC26Ew6uw0xGrmbnKJjjT97G319iQ8Mtu4fyEWxPsCrrxph51dwDYgt0a Hz3cgh7fcuwb2NtXrtcy2HlA6ffjfP907pNCr/QXyhJFOABs3271696qPl46oOlx3AEAG7Pb/boj EuO4A0DnMT76XmAcdwDovt3t1x0AANy1W+3oAADAqSPt6DTrAgD2XFvGR69YJBvfTwMAsHdoRwcA oAv2ZHx0AAC6reZ29OzAndUzVygdHrwDAPZZI+3oableaJGKKwUAYK81145evbKe3BkUXWPp1QEA sMMYHx0AgA5o9fjoJar4VNMBAPup7eOjU8sHACBKa8dHL13V5iYAALCP2tyvO2UzAACR2tuvO8U5 AADx2tKvOwAAqIR+3QEA6II2t6MDAIBI7W1HBwAA8XasHZ2x3arw7bqm92pz6bfzfGhhlgDshXq/ R29aLV3CGSnYL9WnEYyf0v5zsj3i2ZFz08/NUrpUNnHfioz8BPhiNt3RXnPpt7OLwPgjAgB1qrdf 99r7jGtCWlg682mU1nbYLrCdRXiha3rgLsEIB/LjLNuMPLT80HQG+xnA5mm7jl5xfHQpWK5ny6Hs Ir6SLPurM378qp2ZyS6brjo7v+mLdcytgDM/9Was6HEpuv9Lx69yPmSfamRTM2LmbpeRDuU3gDao uV/3RHwl1YiTrXf6HmI7o/nS2QBfHsol5Zy/+ae4JY5Lof1f9HgVPR98+UlH+HXet8nZojpdJDcd nrEDaIXm2tEjazC57aDOdt+KebPz0OgVOb6dWyq8VxXz1L1GzlpyvBr77fe1nsSnEPi1dDoAsGlb Hx+9A5fFel/OKr1Dtrgn7Tp37iKbvIWqcpNUSzoAsAGtHh89m2BdSYUZrarGU1Y7P0mEVF35dL76 bjToOvOzYc71biAzhVbR3EEBgFbZ8vjovhfFne8rpemnb6tJpkyNf9Mq9+Xw7GtTgfnZDGT/aa8o l72sMd/5qNmZz0KcuQ3sz5j52TbmyPRzN6HK+WDnJ/c45m6XvUWBzAPAhmx9fHTfIs75RhFbbtW5 MSOzVDoD5dbYxPsEgRQKHRfxZLVE+oXiR54P4fyEY9ZyygHAJtCvOwAAHUC/7kBhvlYSANiiRr5H h1Pgc/MN5wQVccgAtNFu9eu+0ygGAAANoh0dAIAOoB0dAIAu2LHx0QEAgJtdR6cdHQCA3UM7OgAA HUA7OgAAXUA7OgAAnUA7OgAAXUA7OgAAHUA7OgAAXUA7OgAAnUA7OgAAXUA7OgAAHUA7OgAAXUA7 OgAAnUA7OgAAXUA7OgAAHUA7OgAAXdCKdvRer9fr9Ta80s3o6nZtS8X9uetn2q7nH0CzamxH760Z c3IXPD09LbfGJjR6xeyd1dyKKiqRzzZvTqpVZ1oJJfJf9LiE4+/EUQb2V43t6MnlJnvR2fULaO3S XZRo7fVxV/KJDeMvGmizbDt6fzWvjnb0Xq9n/PFnS4WY60IaPylR0kXsdJxzAvFzV+pcpGj+iwqs NLuZRvkaub3GslXyH0jfd2iyeY45js5/xuQnN7KxVDZyc+eVb9t9a5Hgfgun6dyE+PM5Jn7M33WN 5xuAeNl29P46VH87ulHA2+V9IL7xGN9OJ1vkZy8lxq1AzHrtRcrlP5tgTDRf+sY13dg6id7e5Kfs UuUusuH07TSN9YbTMRJxppmbTqGt8O2Qes8rO356KCOPly/Z3P3gOy6+xXPjG3u46fMNQDF2Hb36 9+i+q1651IpeCwJ1iJaIrH1Git/eoqtz5rPE/oxfr1GI5i7ofGJRY34CS5U7rwqVbb6Yzhudovth A38XlOLAptl19Ia+R9/Wn3cLLyvO6k69iTeXVNv2Z7lnJ/WuN5LzTrfcqsNPLwo9A5NW3vUCKGE3 vkff1hWn0fUa9artZqZeVbIa88C5lhXtNOPkiW9uiJxZKNmikuPbRMrAnqu5HT1be7DDRkyx2sjT n3xPEZ3zjSZJuy3WXm/uJsSstwQjq+kuCiP5tBsAABR5SURBVKSf/pQWdWlS8dubXa+zBdeXT19m 7Kw691s2HV9kqbA/5ewplJuObz80fV5F/l3k7je7GdvIrZ2Z3PPZuIUKHEcjHDhvi55vAOpRezu6 cTVxhsMzwz/Z851rsQPxmnvaHMh8zK6IWTw38zEbUuK4hLNX1ypKx7TjB55aByKXPq9q+bsolEj8 KgrtioqJh1MDUAn9ugMA0AG70Y4OAADCWtGvOwAAqIrx0QEA6ALa0QEA6ADa0QEA6ALa0QEA6ATa 0QEA6ALa0QEA6ADa0QEA6ALa0QEA6ATa0QEA6ALa0QEA6ADa0QEA6ALa0QEA6ATa0QEA6ALa0QEA 6ADa0QEA6ALa0QEA6ATa0QEA6ALa0QEA6ADa0QEA6ALa0QFsX6/X23YWgN1HOzoAAF1AOzoAAB1A OzqARvR6vfhn6aenpzx4ByrKtqP31yHq6ADqZ5fZp6enW8kJ0E2ZOnp/HaKODqAqu7Sm/AaaRTs6 AAAdQDs6gEYUakcHUB3fowNoSvxj9l6vxzN5oCq+RwdQO2rnwBbQjg6gCdS5gQ2jHR1A/YoW5xT/ QHW0owMA0Am0owMA0AW0owMA0AG0owMA0AX0674v0q+JCr2ClCxV5avi7FdMdjp2rsrlEwBQc7/u xkeo9mU6+5Pvah64uDs/cnWO2hQuD3zxs2sMZC+mNwxnyRRI3/jJt8mR22WkbyQYWVgmMSM/LHZG M9YV/qcxhy5HAKAYu45epR3dV3g4S6lwaeG7uKflX7YgDJeCMfnMzg9vSxrBd3thJ2Ws104/twiP LN6yaRrh3GUrMnZOLgpsAKiXtuvoTbejG5fytODJ1gh9cUqkX0t8+5ZCGismKyZr7M/S6VDiAsBu 2Wg7evWOIcPjMxZN3xe/enEoZ+v0RlJ2+kaFvq5C3c5SxcTrHd/abphwNnYAAKI0MT6676Jc9MFs UUXTr5if8FP3osINzLWIf4CfPikx8lOiI7DA7nW2aNCODgAl1duOngiXlM56do2X7411Pxn/ctyG VX/qXuPtRZWHKACAeA1+jx6on+U+vDWWLdE0Hh/Zlx/jMbiRn9wETzNy069xJGnjzbiYDNe49piM AQCaUHM7uvFem/2+WyCyEcHXpGqUUtnnAYVetHbGd76XF85PIHEjb773/sLpO7c3ZtXZcOn26UCG nTHFdVyc63VmiXZ0ACiv3nZ035trzqtz+DW3+KV8Mwvl056fm73IxH1p2uHqmxbIfyCdcj/FxAwv XsuhBACs0K87AAAdQL/uAAB0QZf7dY9/2X63dHW7AACVNPE9ekt0tYTr6nYBACqhHR0AgA6gHR0A gC5Qdh29rnb0zfRbsjG9tW1nxNTCLAEAtqC5dvRwn96pWroSy3ZL4gznZiy355ai/Y2Hu4sx1mvM L5Q+AAAiXWlHz/bQYvTWkvSYlg1k42RnNpElXz6N9Rrzi/YyW2vGAQA7qf7x0X29eDo7BLV7Y/X1 CFslSwE1PiEokU7Rurhvlzp3WvwqAAAdUH+/7r7SxXj4nNZKfWWqM35R4Z5c40vEEv2NO0cI9a03 MN+3H5xhY3/yZB4A9sjG2tGrj4dWO/v5tq+0Drejl+5V3kjKV1qHE3HmtlzGAAA7rInx0W1G0RXZ Thwfv7RGy7zq2S63H4y7Acp1ANgHDX6P7it+AsWS8yfnmKetep5s58d4c62W3JZIhLIcAPZHze3o 9sdjzvG50/n2IuF04ledzg+M2x1fhS3Ujm6MKe4cs9xIyjc/Zn8G0oncOgBAF9Teju57q8sXtv9Z Ln5MOrkpBAQWCWcvsCFFE89NivIbAPZXN75HBwBgz9GvOwAAXdBgv+4AAGBz7Dp6Z8ZHBwBgj9CO DgBAB9CODgBAF+xkO3qJHmYC3d20rb8aAADKqL0dfQP9txf66jpQYGd7diuaBwAA2qXz7ei+AruW cVQBAGiJmsdHLzre+dbHRwcAoBsa6dfdLoDtMcQ2Mz56GKOOAgC6o7nx0SvazPjo6boo1AEAu20z 46MXtbHx0QEA6IZmv0ev5b13inMAAHLV3I4uEeOdizUqaPy44NlEIlvBneOj+9YLAMCuaqIdvejQ 3fHjozc6rjkAADus89+jAwCwD+jXHQCALtjJft0BAICJ8dEBAOgC2tEBAOgA2tEBAOiC+r9HRxPo pxabZJ9v7Rw5qa58Vk8n3LmF0RlGxdSqC2xvYD84f23PyQCRFvfrjgRd5mGTfP02lhg5qVCxVLRs qCuftaSTjeAsLI3esXKzVGJXZEe9ChTDudtrrz1wj4LWaWe/7kg5/0SBhtR1voULierqymct6Wyx nuosxY0xLbPh3CI/Eteldqp5fHSf7F1kMsfZCWvus6lG0ym1Ze3i267sDrHjZH+KGc8+XXZjO62r 29VVRhHurD7aM9v5YN8WOEl8FfRCKcvZvRSOX6U/zXCCdq7afFCQqLkd3b5ly46DHvg7z87ZVjqB +L75bePbLuc9kH1JTef4njoa6W+sFa2r27VvArdW7HNx3YBuXYnWFmxTve3o4eMdrjQbRfJW0vHF 363zuFxuc29uKqZfXVe3q/2MJx91pVlvghvjy7mvhpCteW9yq4vWrSmwu6AN7ejO+tMW04Hs8gU3 rKvb1TSjrrbFnLST87Kz3QpuodVx2ewGvkffO129HHd1u9om5tJv1Ol9i/gOWcsPZdJAY8xxtiY0 vV57P5dO2Zn/cgna+cTGbOh7dOPpU/ZtDqMtM/dNkEbTaSHjZZnS22U0M9tPAo23bOxrRzb97JsK G9h7Xd2uFnKeb0abd0w6xisO9kzxHMfIVTjzGUh/Y+kEfo05qbKnesx6nfstkIjveuLMf2A/FLou YXM28z164HjHN3tvJp22KZTVyPcGAo8HA3Gk4E6uUVe3q4Vy909zSdVyqhfNaol04t+/KZGrEvun UH7qOih1HUfUjH7dAQDoANrRAQDoAsZHBwCgExgfHQCALqAdHQCADqAdHQCALmB89N2wt59HY8N8 H4W3s/MGX8erifisVk8nvH+KfrS9+b1d9Lg7+3WQCvstfhGE+L5Hz/aoGp5uLev7gd6XsDFG32G5 4dzUkkDklb3QxcT5d2EkEt+jS8V0wvsn23NRjEK7IrdktS/Uzh5pShx3O5Ml9r8zHZTn69ed4rwl 7E67gIbU1W2LlL0JiFfX30Ut6WzxSpjm31eUGpvW9HHBdnnHR6+3jp7tpzOZE+i8MJBmo+nEbEjL +bbL7tHz1NW/o+9CYO/YDXf92NXtaq2K13pj8ey1wll3zPZamv5aeu1NC5wkvgp6oZTl7F4qn1Er hcBxKaGuTHbsIrxd3nb0csW5faubxDllfPSN8G2X8x7IvqT6Dm76TyP9jd3jd3W7dkv1253ArRX7 XDwV7nLpFLo98tVtAnWewI2CLXD9LJQO8tXbjh4+HuFKs3EmbSUdX/zdOs/K5Tb35qZi+tV1dbva xndhrfd2Z3f3ti/nvhpCtua9sa0uWuJm77Ryw4GVOv++dvdY7542tKPXlWDtGdtnXd2HXd2uuvDn U45zv+1hBdTY5C3mZD95v0ePrKNvK98oratHravbtUm+p+JF961xcfAVZr5kW34okwYaY45zvzW9 3qIxI49LTPoxcXITD6cTv71I1dyO7mM8fco2ohhtmTHtMc2l00LZR3aSl9XAdhnNzPaTwOxOs2/X ss3S2fu5zdQ8urpdLZRbEkTuFucigfbdoqtw/l0UbT9uIp3Ar/GFXMwfu7FeYxHf/sw9LjEHxbd/ iu60EvsZOTbzPXogmnGibD2dtimU1XDk7B9w7k/OpArt5Bp1dbvaJvLvq0pqda3CF7loPkukE366 XjFXRfdPYGahTSu6H4oeXJ96Tzl4+3Wvt44OAAAaRTs6AABd4B0fnTo6AAC7xDc+OnV0AAB2Ce3o AAB0AO3oAAB0wYa+R0dF7G1skn2+tfO74bryWT2d8Mf08d+Xx6TWhJ3onAP5GB+95XgQgk1ynm/G X3rkH37RHmMKXUzqymct6WQjOG8OCj3RjN8V2T1s723n/vf1sBTIf2C9dvrYsjb0646A9E9u2xnB XqjrfCtaSBRVVz5rSWdbV0LjOuy7C7HjVDwixnopC9qD8dE79azJt13ZHWLHEc+tuvGrveyGHwl2 b7u6yrgyZK8Vxl9udmY7H+zbAieJr4JeKGU5u5ciFww8VKACtj8YH93beJaN75vfNr7tct4D2ZdU 38FN/2mkv7HLRFe3a98Ebq3Y51JTBbrcep33ELty3cNdjI8ek/Juncflcpt7c1Mx/eq6ul3tZzz5 qCvNehPcGF/OfTWEbM27ia2ufmiMO600HM5txx5wdkQb2tHrSrD2jO2zru7Drm5X08JVNzgvO4En 4TXaYs1eOBlahu/R905Xj1pXt6ttYkoO4+LgW8R3yFp+KJMGGmOOszWh6fVmOVug7OzVzi4IwvlE oxgf/Uw6LZR9ZCdxz8Gc22U0M9tPAo2nbcbfZPZ+PHs/t5maQVe3q4Wc55vR5h2TjrNp1tj/zuMY uQpnPgPpbyydwK8xJ1X2VI+PbD8zz20a921v/MYWuuRiQxgfveUKZTUcOdA8Zv/kTKrQTq5RV7er hXL3T3NJ1XKqF81qiXTCT9cr5qrKesP/DKdfcefzF9QW9OsOAEAH0I4OAEAXMD46AACdwPjoAAB0 Ae3oAAB0AO3oAAB0AeOj7wb2NjYj/F1y5HfSG2P/XZT4dL6WdOrdb+3pKqM9OTFwSXRjfPSW40EI NsbZV4nxa/wJWbTTkkIXE2c2jETie3SpmE7t+y1yV2T3sDOc5ZxfZbtys2TPNNZrzC+UPtza0K87 ApynPtCEGv+iSxQGhdT1d1FLOtu6Emavw8Y1Od2u7AYacZq4qvjuG5zrtefH32HAifHRW/pMqRzf dmV3iB1HrL9/OfvXbu/YDT997ep2tZavollu8ey1wnk1753t5VfafQgCJ0n1/WYEGtoP2y0ai9bF fQ0igVuTNp8/jWJ8dG/jWTb+rpwxvu1y3gPZl1TfwTXqAdmlNrMfurpd+yZwa8U+F9cNaJV0fHPi S8QSdZ7AH5EvKed859+pL+x7BrCPGB89JuXdutaUy23uzU3F9Kvr6na1je9anK1BVt9Xu7u3fTnf zH6rzniOJXFbVON9hu8qHVMqhy/+uXG6rw3t6HUlWHvG9llX92FXt6suzj8fX4UJqd3ab43mpHoV 2X6WFrOUcTfQnr29SXyPvne6etS6ul2bVNejS+Pi4CvMfKto+aFMGmiMORt45Guvd7t8+yFVS25L JLKfZXmC8dHPpNNC2Ud2kpfVwHalf2Bpm3G6iN3u5Xsul6afRthMzaOr29VC4Qto/M7J7mrf/nce R4n7e3T+XQTS31g6gV9j9lv2VI9Zr2+/OberrsTDOQ/8TRlJha/n2XB6r+A8LkY6kVvXTYyP3nKF shqOnP2Dyf3JmVShnVyjrm5X29T7h5O7q2tPvGgi5dIJnGZF11JxvYH5RXd+9fwE/llxJ+cmtc9/ syb6dQcAoANoRwcAoAsYHx0AgE5gfHQAALqAdnQAADqAdnQAALqA8dHbbic+mgcAbF+N36M7++7I 8hVO2R5CjE4DspFz07fZTxFOM70fpCt1rijmrsWXjvPphXN+bvrZXFGoAwC8auzXPS0snQWPr3Ay +hjKpuYswgsVbIG7BCMcyI+veDaWNdIxchu+awEAoKLNjY9u9Ptjp9B0BTQmt878NJExKtwAgHq1 tx09W7utuCJfVbi5rbDTdDZPBCrr2Xq/L00AAO5qtF/3jZX6Yc6n+oXW4kuzHF+DgnPVtKMDAKK0 YXx0n3qbmUvndjOVeAAAqtjQ9+hGZONtsuz8bIRUXUW78+F2dqYvPwAAtFyd7ei5L4c7m4Tt+T3P OLv2inLZyxrznQ3ehZquffGNvWFvS5XEAQAw1diOnlvk+CIY88P/LCRmjeG32EqvJX5micQBADDR rzsAAB1Av+4AAHRBe79Hjxf43HzDOQEAYGsa/R59M9qQh13EnRAAdArt6AAAdADt6NvEDgQA1EXZ dfSda0dP9daMOVvM0rbs51YDwF6z6+iF2tG3lm9Ltpu5neiVxbglqnFn+vrVAQB0WTfa0VuVme1K 72y2nREAwEbVPD562r+ps2NXI2x0qC5nC2b7V3tZu9zyVUzt+M61F82PL/Fczgq6sYpAfnL3Q9H8 AAB2Xc3foyfz7Z+MMj5bINlFlJ14+k8jfV80o1y34zsXLJGfAOMmJhzfuT8D+Qnsh3AxDwDorCa+ Ry9XljgrvjExi6a8gfzYJbHz1yr5cc7JzqclAgD2S2vHRy9X5jX3Olih/GRrzM1kx4uCHAD2U83t 6DEafQd7K4VZoafckU/sq2wIT90BYA/V3I5uvOGVjWA0n6dxwo3B2cWz6acR7CZwsR56++IHEo/M T42MVw3C+Uk3086M800CAED31duOnvv+ly+a/VNuC73zPbJAIrlZdUaOeX4eX7qHK9+BHMZsEQBg r7W2Hb2EtuXHtrEctn9XAADqRb/uO8lo3QAAoAvjo+8h9jwAwNSB8dFRDscOADol0K975BQAAGxd th19VeF+9c2bIlqJ0us4SpT0RS9FMWXKlClTpkzbMZWlZEtqLfLkow+JyJVvvrAq0V9/66b0RZay mmbLfxFFmDBhwoQJE25BeF26axElSy19lZToT//e8+lTd9F6FRj0B5KhZECYMGHChAkTbkNY9ZPp qjgX++u1uday1HOt9VJmeiZL0Uutl1qWoperfxImTJgwYcKEtxte/VNrEaX1qjIuInq5bkd/5QfX kxJeL0X1lU7a0UWSiv76n4QJEyZMmDDh7YbPFM16qb/65YdF5Mo3X/hXf/iHfygi//DDSf//9U+W uv+J/sm/nPSlf/IvJ3qpRe7+kzBhwoQJEya83XC2aF7+y1I+If/682MRee0H11bfoz/9a48IAADY TaovvW/87n/0vSWfxGjDy/pMmTJlypQpUx0smv8/wNZ7nHLBpYkAAAAASUVORK5CYII= ------=_20041011113302_59241 Content-Type: image/png; name="ssh_session.ISO8859-5.png" Content-Disposition: attachment; filename="ssh_session.ISO8859-5.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAApsAAAFpCAIAAABcQnS8AAAgAElEQVR4nO2dX4hkx3nov9HtNdVi ZLqX3TBtpKAxDmg2zsW7xGCJBCJdC2KJPFwtCViKA5biB3tjQqJr3xeb/LFCHiJhcpN14JqVH8wq 4ETKg5H0oLAyKEiGXHYNSTQCG7W4EurBEtONPWwXUXPnPpyeM2fq3/nfffr078duUVOn6quv6pw+ 36n6zqna+Nsr/6hEtEipsCMyE+mInqXHH/u9iwJrzNVnntczrTpKz7R0lJSL57pOx+/sPvbFx2Qm /bN9ERmPx7s/2r387cvDz04uycMv3HXj/Dvbg7u2dEdUR278843zv3m31lrN9Ksv39D39+Q7w9c+ u/dQ797BXv+Fb78w/W21/Z3B4Fe3ZK/b21Rd1VMdkY5fh5mW+a+gTDzHb82MZ+ijZ//PzsX7ByIy ncl9n+gPzsi1H0133548cH6wffvxSdx9a/rq7kSdkgc+NehvHqXOZLg3feG1iSi1c4e67xPd0fty 7UfjbkdE5OqLo4F++oHfuLvs3YaQkNAT3qJEtOhEUt64KBE9E5GjW4Y//tijFzHn8MjDDz72exeP TXLSPEdxmZvqLPHElSgp8Znun+kfm/P3xjd+dOPy312efFZEy87Wzqgz3ZE7hwfD6+/vDvVQ/VwN D3avv7871KNzs509PbrnzD3q36cjPRn9aKTeUvr9idbT8TsTfTDWWo8PJnqmZaZFRM+0iJjxjui5 cS0TT5jnbL+743iG37XMtOrIVLSIaD2N9Fei9Gx6fApjTY7S9UzGB/LqG+Nr/zZRZ9VgEJ0j0Xoq HZnOjkrNpc37hDhx4tXGN4qN0UVyjxIee3Ruy8c/l9H7Y5npyYE+ukPEd944Qrx18Y70VK+/KYMz fTk1P3b1meejK0TPR96+eAWjeT2T6WTv0ucf7fa78eh8IpPpZ9Xevw533tgZfkVv/5Xa/vr2cG+s bpfJn0x6f9bT78jO7YPdP9kdfl22vyG7nxqe/9x5+aaWPTX89Fvnf3i+21M91VdZxujucKmj9s6R oT3S5tkf7lz8TH86VdIVEdVXenwgeqrvO9/bvr17dE6jMbpWp+SBX+2Lkr296fXdiZxS/Z6STldm 0/FE9zdFazUVLVORU/qFF8f9GWN0QsIaw43Dw0NZFNOpDN8Z7U20OrqbxKGI2ImE7QxFdm7fGpzt pl0vAABgcuXpZ30DmMVZ9NFoPNyb+O7yIss2M4SLDbd6avv2QRezDgCQn8tPP+sYo+//dD+a2JSZ 9Af9OHf5uXE900qp83cNuqdk+PZ4uDcRmYrEt3BnPDUD8fbEVad7/q7tbldG742Hb010Yp5GRDJe ZsSJEyfe+rhSSjoy6PV6vW73yGspIpeffjY5Ur9Fz1970bE5n07l9R+PbrwxnEwmexMtIvrolZY4 kkz0xVVHdm7vdU/JeDwd7k1ERB3fzd3x1AzE2xTXM9l9ayQig7N96cwn5COjLpkvM+LEiRNvfXxy oPWB3n1r78a/D0ejsRzxwP33qY7SIqqjROQWJUqLHgwG0eHRaHzjjaHT1a06+WZWRaTf74rI7lt7 09lUZjKeTWUmznhqBuKtjI8m49F7UxHZ3toaH0xlluMCIyQkJFzDcLg3ub47kg9ERLbv6O988kJk /pXIxrvvvqtERQP0k3Pj0ccqUaS7dUYNer2+6kbHRpPp+CAawceZzXB7a7B9R388nr76xrAr3alM A6GIhDMY4bf+/CvSkTvvuPPc7eee/PaTT/yvKz21JZuSzPPyPz199e+v/u3/fl42pd/pGxIevPuc iFx7bRil3Hf3tog8/9rrRl1GelQqxsifPBpL9qVHkg05TvnOnL56fXkaGyol95zfnk7l2g9f7ypR na72X1SEhISElYc7d/Z6m/1uR6YzCYeTg/HuWxNDws6dg/zFpWTtqiP3fHw7+m7oyvdflfdGWmRj /939yJyPx9MbP9kTi96m6m/2epvS3+xO9VTPRM+iI1prGR8kHe0n2Llza3C2e/3Ho9H74+Q3Nu5Q 0jJY4XPfeWrnYzv9M/2dX9r52p9/7ZEvPN47O4icDTKTGy89d+W7V/7Hnz2pOiqZHoeRFXzwdx77 0h89LjN58NeP/vzy48mcyfQ4Pjec37siIs+/8rqR8/jQa6/70uPaDTnJ9GQtdk5nW+JSRisaHt73 iXPd7ry7uh2RTtd5RQEA1MHOnVuDze5UpNuV6QciM9GzqUhXjpZbEImWlFAievetSUOKKyX3/Mq2 iAzfHr/wyg3R41uimXpJzI3H4XQ2VR3VV0opUaorp6R7W1d1uur4xSVRSqmOMgpG4aDXFRE90XOD PRORrjeemsGKX/iNhyZ6sn3Htuqp5597/vq/vDB5b6QPtNb6xivPXfnulUtfeWKqRU4dve53Us7z rwwlspEnja5DsTnH8S99+Wtf+vLjz7/y+oO/89i3/uYpQ0J0SESMofOXvvx4FPnWN59yJP7NU0nD /KUvPx79c+ZMtsUq9bV5zpz9ucS4PpiKSH+zr7UW6TovJ0JCQsKawvGBHh1MtZbpVLqnpNuRvur2 lfQ3u0p1e6orMl8EYnwgUz01JBQoXknt+kBG741FZPuOuZm7ZXDHQETG4+lYm9OhXelG9l51RM+m 8oHIB9JVcwMTvcouovVMuyfST4mIjPXxU0a8vJQdT81gx7fO9gd33j18e7hz+063333yz5589QfP DUej4Y1rz333uUtfeUKL9Df7SimllFPO3O6eNMZ2XUftncef/96VOM+Xvvz4o188NrpHEo7//Nbf PJWQIFl4/ntXnv/elQd//Vw4f1LPk6Vy9GFD4hM9v8xkpqez5TsCCAkJ1yrce38U3ZS0nk4/kPkS WKdERLod0dEk+UyLqL33J5PJxJBQoHhVtQ/fmQ/Z7/3kznSmbon+GL4/EZHpbJoMoweByBzO31I+ JSLSV13VEZmJ1rq/2ZOZjA+mdvGE7Un39hd4QUA6va3BQHe2rv3w2nQ83X1nd/LepHvw1tPffvqh L17SMxn0euq2Xq+nAnKSRMbYrOUI1ZFnX349il+899yDv37OKcdOiUo9/70rF+9NzLS/Mk80ZvKj ePTnxXvPGZKdXeos1YTXN7KHo4kWkcGZXtRG+0IiJCQkrC8cT0Rmc6MmM5HIrB4ZVyVdrXX0Ldl4 MtYzbUhwFt/Y2Nj40IavuK/2Wz+0sbGxkaz99Idv/cgv3OqrfXwwnU5FRM7dORi+szu36Cfnxufh W3uTXk9p0TKbPyZMPxARmYqoI0+nnmmlZG8ysYvPM2idJcyY7UTYERHpnR3sjvTe3t7lb15+4DMP TA+m04PpZDJWSqluVykVlpMknCeKP/vS9TglMsY+OTGxIY994Y9+8dglf5z4hUvPvvx69OejX7gU lX36756KaowfCGxtnaWK9Ofywp4SERnu7cVXguNyIiQkJKwnHI72RGR8MNFzH7ZEZjIKI/M3PpiI qOHIYezs4hsbGyIiIhsf2nAX99Q+L7WxEdUePROEa58cTEVETolomVv00cFURIwv4UbjcX9TKVEf +citpz9868aHNm790MbGhzZuvXXj1g9vfPQXT3/0F08rUb1NNX5Pa62Pih8LEYkXoE4LM2YzQqVU Ry7ee+GJv3pi+67t8fvj4TvDC5+4cPkvvy5aa8kgIYkzj3X02Zeux0Pqi/eeM+U4JYuISDw///Tf HU/FH5vhb1+WmX70i48/+oVLRr1RjclxvKGns1SR/lxS2FVqfnV+4LgOiRMnTrzW+ORgqmdaRE1n IrPudCZdkWiHoThFROmZnrhspVE8NsMRpz98q108qUOy+P7+fBXXyNRG8f94c99V+1yH628Mo2x6 pucWXYno+VIzx/HR+xPVET3Tb765Ly7efHNfz3R3Uw0no8nBJFqpJhYyr6O+MbqIPtD3fXz78jcv b991z0Sr4TtDPdFa9EOffujr//P3x++NtNb6wCvh4v0XJPEaeTL94r3nLt5/wR6jR+HDn78UD9aT 5jmZ08aXbuex633485di2x8RaRgN3H2lViWcRprPFwM2r0PixIkTrzU+mkyim49Eg+xowQyZx49C LSKjyUR/MDVtZaL46dMnzHnEL3/0tFE8qYNR+82fnVia/d2f3nTVfkL/KKfqHI3RoweEhOVX0UOE 1qI6air63Z/eNFTc3785FVEdNZ5ofSBHVSaFiMiRG/54Ky13PDWDI67lgU9tP/VXT/XuOq9FtrYG g7vuUT0lIpPZ5IFPP/D1P/zd0XsjmemoFYacRz5zbM4j8/zIZy5Eea6+OB8TP/Ody3F7VUcu3n8h zqNnx12hZ/LsS3O/eCQ/+ayQkKDEIiknKT/mkc9cuHj/hUjnWKaeSTxwT5Q6ll+kP5cX724qEdE6 Wp3YvA6JEydOvN64jm6bItH+wrOpkm4iFBEd3WC1Fjl6ZzyWkywuHoziJ3Swaj9R0F37Cf2jnHp2 ZNFFHDtPq466/tYoShkf6P2EUd//2aGeRa/h6eHeWB+M9HRqCBmPp0dazodik8SwzIinZrDjj/zG hae++ZS6c0e09Hq9bq83GAy2P37fnXfc2ev05iP1P/zd4WioXfJjHv78pclRyjPfuRzFH/7cpYc/ f+mhzx2b5InWV1+cG/7IiErCZusTR49fdnv4c5ei9Oe/dyWZfvX788SknKT8OPHK918VkYv3n3vk Mxei+MOfuxTp8/DnL8XyjXoL9OcS49FFMpqMT16sOXZJJ06cOPHC8dFkojqiRaSjtERWc3ocztO1 6shoMpHZ1JCTLP7uT2/u7x/u79/c/9nh/v7N/f3Dd3968z/e3DeKJ3Uwaj99+takhTr9C7fatVtt ERFRnaPBoJ5Fy75q6RzHt8/0r/3r7j13bYtomclkpvf3D0+f3rh581DPpqoTTZOqazd2lcyLJIVM DnS/393eGtx4Y3i0GbOSmbjjkpbhZPyRT1944htPqDM7MhN1pte9rd9TSmbSP6v0x+8TuTZ5exKN 1P/i8d//xl//4+COgSHn6ovXoyF4lH71+9ef+e7lqFOSdRnpcankA4Etc37oc5cC6Ve+f/257142 5Bg5H/rcJdWRWIekTGdbAnkaG5doXXeR4e5u/0xPOj3jOiROnDjxeuNa9Ez6Sk1n8pFfOGFQY978 v/vRvHVkMZNyihQXOdbBVXx//6Z0uqc/vCEiv/zR00ZxQ//Yjs93U43GeTbPvXzjvk/uPPRrO9GU r+rMd4BR0p3MpjKT0fuT3/3G1Qc+Jtt3Xej1e8myvZ568O5z459PX/jB7nw+VXS0jLwdF5FwBjs+ /PFQRPc2t7r9rur0pDPfckZPZTwZ6clkrMci3a6Srd5W/45BXvnEFxPfuX1wz/nt4dvjK3//3OD2 bXWbcronAABq4i++88Lzf30penX8o7942pnnzXf3lch/+8PLj/7m+XgnlJqK7+/fjNaIVZ3urR/e CBcXmTuRL331iaQf3Qz1TJ+/a+vK91997l92VUdJR2TuAe1KR5TIcz+48ft/ebUnE7XZV11lFJ9M 9Hg87d/W3b69rxKzBM54agY7vr29vf1L5/tn+z3VEzlK7yjVlcEd29s7O/d88r4L58/v/Mrd/cGg gHzii4mf/9i2iFz/yai32RORk350QkJCwtrD6VQkmjjsyLs/vfnuT2/u79+cz5z/7PDmzcP9/ZvR SGP+PdtJCQWKh2sXEZGpdLpaJLV2OeLYj3701tz8JhvFlajB2f4Dn9i+8k/X/uCbz7zw8u7uW3sy kxs/GT33z9f/4JvPXH76ak8Pz9+uBme2pKMsIXr3rT0Ruefj29I51mOS0COOOxOJtz6+87FB9zYZ DkevvfKy7og6dXzxOK9J4sSJE688PtHzD7uSllLPROupzKZ6NlWqqzqiNvsTPbHlFCie1KFQ7Sd0 mNvxjprPul/5p1ePvg8WmR19zSwiHREt4/H45R/dGL49GR2InonqSK8zHmyq7bPd3pmtwe3b/bN9 pXoy07aQBz51fjDoTn8uz/zgusxEREf/lSgj7kwk3uL4zp39e85vi8iVf3h1ONwdbM2n3LVxHRIn Tpx4nfGrL7722r/Nv+oOs92Th3/r3sHZflLO1Zdu5C4uxzpcfTF/8ZP6P/ZbF0TksT9+4siif/96 wh4fhXK0konW46me7A3HB1pPRlpEiajeoL+pelvb/a4SpezieqaViHTkoV873+93pz+X5354Pfpe 3HapikgTfLrEFxNXHXX+49sXfmkgIs++dP21117b2trqbvZVtG1Ax3E5ERISEtYXjt8bDX+yO3l/ L5yzd2Zr+2M7/bODE+kiuYvH5rV87TP92H+/R0QuffXIol/+h1ePvg8+DkVO/vmBnuqpzHSUIh3V VV05peyCR+HcVKuOeuBTO/2zXRF5fTje/clo7709OaXkA61OKf2BllNKiUSRZCLx9sVVR7ZvH9x9 13b3NhGRZ196/dorLwzObKue6nf7R96Zha4qT0hISCgi4/FYZnr+DY4v7Kh+v28aR8ld3JZQuHbV kciiJ8bo//BqPFgOhJKW4WSYGJx9oO/95M65OwfR0vPTqQzfGUlH9t7XcXuacFIJawqlI73NXlfJ 9mB+Nb8+HL38yu7rP7k+ODNQm72u6oqIOqWOLpvslxkhISHhWoeXfjsaoz95NEZ/5lo0ljra8sUT F0nJYMWTA7Xebb3zdw0GW73+bcl9x2G9GL49vv6T4bWXrnU3u73ellIqMucnL5h8lxlx4sSJr208 sujHY/TLz1wTkSN7L/54aobj+FQktttRPFr+fqzHg7ODrTM9ERn0ulF+LTL3sBK2MZwcjMdaTyZ6 +OPd8cG4v9mXjuptqsh3M51Jt5O8YHJcZsSJEye+5vFLD98nIpe++sR8sZnR+6Oj95Dnt2BPXNIy JOLzl5bn3nsdh6KGw+FwKFprJRK9rC/i9xwQtikU6at+dDFODrTqiD6YnLg8ogsm+2VGnDhx4use FxHRM5lbdNVRX/vSRcnMxsZ8cA8AAADL4olvPRvHT6wZBwAAAKvEkflW8W6qrKQNAACwenSOZ92P dlNljA4AALBqaHuMLozRF8XGxsaaKwAAAFWh7DH66vrRN44wUpao0rLI2OrDw8P17B8AgBbSGj96 9Mp9RGylmvwSvvGNQIWWNRKFqQYAWC/a4UfnC7qY+Mlm2YoAAMBCSfrR59+jl/GjR+NCe5Qcpzvz JA/Fpsg+ape17ZZvYGrnd9aeVx+f8FScA3SjioA+qf2QXZ9ICE8AAACrTtKP3jmKFR+jR+bBthCG jU8aJNtE2TYm/tOQ78tm2HU7v7NgAX0CGA8x4fxOsxrQJ9APYTMPAACtxR6jl/ejF7MlzoFvJfIX r49tiZ1Hy+jjTEmmZ6+FYToAQBuwx+gN8aMXs3n1vQ6WS5/kiLkedbxgmwEA1pOK/ehZqPUd7KUY s1yz3Bln7Ms0pMCsO8N0AIBVp2I/uvGGV9JCGO7zOE/YGZwsnpQfZ7Bd4GJNevvyB4Rn1KdCfK8T +nz/4u9nqfmxCQAAmki1fvTU97982exDqe9vh1++y5I/i/As8+fZrXt4HBzQMEuLSsIAHQBgtWms H70AzbdJC9Ow+V0BAADVwrruKwmrwgEAgEHFfnRYDAzBAQDApDXrugMAAKw17VjXHQAAYM3Bj74W 4HEHAGg9K7Y/erH9zouVKiO/7hpTsb+ex6gDALSc1fKjV7JCe+VkX3G9AFhiAADIRLV+9KWPTQEA ANaTitd1D2w45sO3ump41dXyG4b69js3dn116pNrkTif/EC6nOzJYlUbsHI7AEC7qeV79Oy7edr7 jofTjaOFTVRgY/UsjxQZ6824L7szPa60qq1XAQCg5dSxP3pEcmuW1Dzxn+F055814dsWpbCEcM5K BuJZasHYAwC0k/rWdc9oPHxj3wJj4voIzxlUQqPaCwAAK0ct36NH78dlnJfOlb5gnGrUoVtGmeWr 5jM2AIC2Usv+6LnGl1neFDN82/Z+51mEJ53TeWf7ja1a40cWn/xc+7KH+8G5SywAAIDJIvdHz54/ S3reKf06qi6gZ+q+73mP5oXHAgCAdsK67gAAAC2Add0BAADawIqt6w4AAABuVmtddwAAAHCDHx0A AKAF4EcHaC2sPQCwVrTcj85ecHUQWBdowfvQN19yGVhQCADyUd+67k2gqjtaxg3ixLMgjLHwji9D FuXDX5P78tur3zjVy75wrzNn3fajPvnNtHysww8A+ah2Xffym5w2E3tn1Sju3HE1bB6ccsTasM5p ZVOtji+/veadrUNy4zun5MCfUBP0MwBkZ/n7o+cldRVV58jGVqnyvc6MSmM1AmvW5hqE5R2uZcnv 3Bqn2hOX93zlPS+F85e5TuxHN+f6vqntMuRkvxKyZ2agD7A+LHl/9LwYMpPjy8BA1s7mk1NYq8Jl I5wz2IXl+/Iv/uZe4HzlOi95z2Pe68Snz2Fibf+k5oEplixyML0AUIrl7o9egCwzz6kpJat2TkHX 54jNK7+kPllm3SvEOUrOTuFmZrxOAvLDfZK9XXn7tkB+nhUA1oKl74+elyXemMKW0vemWFUK133f L1+wPPaYO7VIrdoW0KdWOQAAAZa8P3pNLOuN69RX042yBVzj2TP79DEcuoY+ueRXhbPeBSiTq4qq 9CkvJ/p95SoSflsTANrB8vdHz4V9Y0r6I43EWB/73TRffh/Ge232+26BzEYG43Uqo5Sc7EOn/Cx6 hvVP4tMnF87HgkA/Z0lP+pgzyk9tQpnrxNbH6Dejkw1nvFOO3aKA8tmbCQBrynL3R6+wCme68eJS FjkZhduvO6Vmzq5qMSUD+QP9UKCW7PVmVMmX7nw9LXvV2fNnvE7C+oRzVnUpVvjeAAC0DdZ1B1gt sM0A4IR13QGWRl6vimDOAcBPLd+jQ61kf9keGg6nDACqpN3rurcSzAAAADjAjw4AANAC8KMvgro/ BW79p8atbyAAQHlavj/6erJc+1dH7SyQAgCQTuv96AXWZavWUV338nkZ5YeXtYlxrnSbSz4AACwH 9kdvE86F5yKcw1xj5XljXbNkevicshEIAMDSWeH90X3WKFm1/b1vqmWy89vFkyt9JvPYwm1T59Tf SDTigYVaDfn2+qO5yDsWDzTNzmwXyXWdGKcbAAAMVnh/9MDMsL0Ae0b5zvy26Y1TjDW6c41l7ecG W2d7DfBU4oXHfbY//JCRmu7sZ1888NQFAAAVs3L7oyflJ/9cmLXIvi562BLnes7ILj+w4HyqfOeI X4IPUqlKiv+JocCS7AzTAQC8rNz+6FnqWsWxYGyu6uu38t1SrJ+NpwFMMgBAHaz2/uhOixIwM3lN WhkTmKUH6pZvZI6p5ImngBB7WiWvED5jAwDwsdr7o8cV2S+UGa5cI3/GKpK+8wJ+6Oz6J4/ag+Bc +tvY+sd/+uT70n397GtX6puJjNcBACqjlfujl/fXpkoOVCfBAXQxD3d2+alCwpqH0wPFnUWyONfz wkMAAIAb1nWvg8KD6YwF22HV2tEKAICGwLrupbBnlZsgaiXAnAMAVAv7o5eiQrOEhQMAgFLYY/SW resOAACwFuBHBwAAaAGr7Uev2+u8Pl7tiHVrLwBAm2jD/ugFFippZkULawgAALSQ1fWjJ9eQyZK5 sPyYul9eyyW/ctvPkukAAKtNtX70xo4ysVUAANBuVm9/9AjngNK5WmogMbA7XPYBq/EEs5hHB+fq qvZiq8bKr7naa6z2mpRjVJcUW3LBWgAAKMyK7Y8ewLk/t5x8yEhqmFz7vbCqefciszMUq9e5RZtt euOUvO01OtNZhR1n3h4AYJms4v7oTstRoJbyq6aHd17JXmMdZO+icHsLLyAPAAALpR37oy8RY4ze +iYf1r+POwAAFGD19kf3Sa7qjbxcmjfkNcAyamRpb0OaCQAAAVZsf/Rwpb59vo14cl9wIx6uwpYj lpu5TBOc8n3Y7TUaEn7ZLaxP2JtgD9CNN/UYuwMALIHV2h897EHP7jn2bezts+uVbHYeoPD7cb4/ nX2S65X+XCphwgEAls9qreveqDVeWkDd+7gDAMDCWO113SEj7OMOANB62B99LWAfdwCA9rO667oD AADAMavlRwcAAAAnLfGj49YFAIA1pyn7o5c0ycb30wAAAGsHfnQAAIA2sCb7owMAALSbiv3oyY07 yyuXSw4T7wAAsM7U4keP7XquIiUrBQAAWGvq86OXH6xHTwZ5ayxcHQAAwArD/ugAAAAtoNH7oxcY 4jNMBwCA9aTp+6MzygcAAMhEY/dHLzzU5iEAAADWkSav645tBgAAyEhz13XHnAMAAGSnKeu6AwAA QClY1x0AAKANNNmPDgAAABlprh8dAAAAsrNifnT2diuDr+vq7tX65DfzemigSgCwFlT7PXrdVLIk nCHBfqk+zmAcitfPSa6IZ2dOlZ+qUlwqKdxXkaFPAF/Ouhfaq09+M5cIzH5GAACqxLGuewkqXzOu DmJj6dTTsNZ23DbYThOe654eeEow4gF9nLbN0KHhp6Y10M8AsHi0PUYvM+uetDEZb2pJO5Qs4rNk yaPO/NmrdiqTLBtXnUyv+2ad5VHAqU+1iuU9L3n7v3D+MtdDclYjKc3ImdouQw72GwCagGNd9/Kz 7tkHqUae5LjTN4ntzOaTswB8OhQT5Uxf/CxugfOSq//znq+814NPn3iHX+dzm5w01XGRVDnMsQNA I7DH6FV9vZZxBJPqB3X6fUvqZutQ6x05u59bSrxXlWXWvUKco+TsVLhuv897kl1C4GhhOQAAi8bh R6/ozbhcZmylqfblrMIdssSetMfcqUUW+QhV5iGpEjkAAAvA8T16+a/X7InN8gKrEhXG8Koas6y2 PlGGmKr0dL76bjh0nfosGGe9C1AmVxX1nRQAgEZRsR8974tCvhfFne8rxfLjt9UkYVOzv2mV+nJ4 8rWpQHpSgeSfdkWp2GWNdOdUs1PPXDi1DT0Oh+8AABknSURBVPRnlvSkjzmj/NQmlLkebH1Sz2Nq u+wWBZQHAFgQ1frRC9zafEWc6YaJLVZ1as6MKhVWoFiNdbxPEJCQ67yIR9UC8nPlz3g9hPUJ56zk kgMAWASOdd0bvMIMAAAAOKnFjw7QbnxeEgCAJVLL9+jgJPC5+YI1gZJwygCgidT3PToYYAYAAKBG 8KMDAAC0APzoAAAAbcCxPzp+dAAAgNXDHqPjRwcAAFg98KMDAAC0APzoAAAAbQA/OgAAQCvAjw4A ANAG8KMDAAC0APzoAAAAbQA/OgAAQCvAjw4AANAG8KMDAAC0APzoAAAAbQA/OgAAQCvAjw4AANAG 8KMDAAC0APzoAAAAbaARfvSNjY2NjY0FV7oY2tquZVGyP1f9Slt1/QGgXir0o28cYaSkFjw8PCxW Yx3UesfcOEl9FZWkgJ5Nbk5Mo660AhTQP+95CedfibMMsL5U6EePbjfJm86q30ArJ+6iiMbeH1dF T1gw/KIBmkzSj94xksqwsbFh/PiTViHLfSHOH1mUuIgtx5kSyJ9aqbNIXv3zEqg02UzDvmZsr1G2 jP4B+b5Tk9Q5y3l0/plFn9TMRqlk5vquK1/bfbVIsN/CMp1NyH49Z8mf5Xdd4fUGANlJ+tE7RlKF GAbetveB/MY0vi0nafKTtxLjUSBLvXaRYvonBWbJ5pNv3NON1knm9kaHkqWK3WTD8m2ZRr1hOYYQ p8xUObla4euQaq8rO398KjOeL5/Y1H7wnRdf8dT8Rg/Xfb0BQD7sMXr579F9d71i0vLeCwJjiIaQ cfSZkeztzVudU88C/Zm9XsOIphZ0zlhUqE+gVLHrKpdt8+V0Pujk7YcF/C6w4gCLxh6j1/Q9+rJ+ 3g28rTiHO9UKr09U0/qz2NxJtfVmxPmkW6zq8OxFrjkwaeRTLwAUYDW+R1/WHafWeo1x1XKVqZYy qmaZcK6kopXGuHiyuxsyJuYSm5fo/NYhGWDNqdiPnhw92HEjp1g+8viQbxbRmW64JG1frF1vahOy 1FsAQ9W4iwLy40OxqYtFZW9vsl6nB9enp08ZW1VnvyXl+DJLif6Uk5dQqhxfP9R9XWX8XaT2m+3G NrS1lUm9no1HqMB5NOKB6zbv9QYA1VC5H924mzjj4cTwITvdWYsdyU59s80B5bN0RZbiqcpnaUiB 8xJWr6oqCue08wdmrQOZC19XlfwucgnJXkWurigpPCwNAErBuu4AAAAtYDX86AAAABCmEeu6AwAA QFnYHx0AAKAN4EcHAABoAfjRAQAA2gB+dAAAgFaAHx0AAKAN4EcHAABoAfjRAQAA2gB+dAAAgFaA Hx0AAKAN4EcHAABoAfjRAQAA2gB+dAAAgFaAHx0AAKAN4EcHAABoAfjRAQAA2gB+dAAAgFaAHx0A AKAN4EcHAABoAfjRAQAA2gB+dABYPhsbG8tWAWD1wY8OAADQBvCjAwAAtAD86ABQCxsbG9nn0g8P D5l4ByhJ0o/eMZIAACrEttmHh4dL0QSgnSTG6B0jCQCgMLa1xn4D1At+dAAAgBaAHx0AaiGXHx0A ysP36ABQF9mn2Tc2NpiTBygL36MDQOUwOgdYAvjRAaAOGHMDLBj86ABQPXnNOeYfoDz40QEAAFoB fnQAAIA2gB8dAACgBeBHBwAAaAOs674uxF8T5XoFKSpV5qvi5FdMthxbq2J6AgBAxeu6Gx+h2rfp 5CHf3Txwc3d+5OrctSlsD3z5kzUG1MuyGobTMgXkG4d8Tc7YLkO+ITCjsYxyZvyw2JnNqCv8p5HC kiMAAPmwx+hl/Og+4+G0UmFr4bu5x/YvaQjDVjCLnsn0cFviDL7HC1uUUa8tP9WEZzRvSZlGPLVs SYzOSQWDDQBQLdoeo9ftRzdu5bHhSY4IfXkKyK8kv/1IIbWZyZJijf4sLAeLCwCwWizUj15+Ycjw /ox55fvylzeHcnJMb4iy5RsD+qqMuq1SSeHV7m9tOyaczg4AAMhEHfuj+27KeSdm85JXfkl9wrPu eQk7mCsh+wR+PFNi6FNgIbBA9zo9GvjRAQAKUq0fPSJsKZ3j7Apv3wtbfjL7y3ELpvyse4WPF2Um UQAAIDs1fo8eGJ+lTt4aZQu4xrNn9uljTIMb+qQKPEyQKr/CnaSNN+OyKFxh7VkUAwCAOqjYj268 12a/7xbIbGTwuVQNK5WcD8j1orUzv/O9vLA+AeGGbr73/sLyne3NUnUyXtg/HVDYmVNc58VZr1Ml /OgAAMWp1o/ue3PNeXcOv+aWvZQvMZeednqqehmF+2Ta8fJNC+gfkFPsUJac4eKVnEoAAJjDuu4A AAAtgHXdAQAA2kCb13XP/rL9atHWdgEAQCnq+B69IbTVwrW1XQAAUAr86AAAAC0APzoAAEAbqNGP Xn4V8aXg+x46Nd04mneddp+cpcPKMAAAq0F9fvTwmt4xVRmMVMtqL4xqG2nfuuLh9cZt/e2KsrSx 2Lp44WVWnSvyFnjCAACAplPHuu5LwbkNiW9BOvvQyg1DA4vLpj7NpLZ3FTsEAGDNqX5/9Cyz04bJ CRxyiipGYNBccl+TqhYuDXddAeF5x+KpjobUBfkBAGBZVL+uu+/u7zSoAVNaYNbaKSTXk4FvXfHA euO59AxYxLztTa4bn9fl71ssNtXR4JsDAACA5bMwP3reu39V1iKvxS3gR3dW6tS/8HNJsfz2VISd XmC9GjZTAQBoIovxo/teSasqfwNZgP7lxRbrZ+NpALsOANAEavwe3WceAmbDeci552lG2+PLac8f FDNLVb3MH5ZjtyLeIzWikieGAkKw5QAAzaFiP7rhb45MkWF1kul2kbCcQNVxfmPgmMs1nteP7vPT 532tL5e/P36dMPll2oZrH3rfG4ip/RxuV+UvLQIAQAVU7kf3vXXli9t/ls9vJPqsTnY5VQkJECgS bn6go/IKTxWF/QYAaC6s6w4AANACWNcdAACgDSh7jN6a/dEBAADWCHuM3pr90QEAANYI/OgAAAAt AD86AABAG1hJP3r2FWaSRQKiVnFNOgAAgBNU7kdfwPrtub6KDhjs5MpreXUAAABoFq33o/sMduGV XwEAABpIxfujB1YJzbuqKEuNAgAAZKeWdd1tA2zv8eXcb9sQ5SteFewKCgAA7aG+/dFLsoC31XJt eQ4AANBoFrM/el5asD86AADAIqn3e/RK3nvHnAMAAKRSsR9dMuw7Ltaundn37U4KyegFz7tvOgAA wEpShx8979ba2fdHr3XfcQAAgBWm9d+jAwAArAOs6w4AANAGVnJddwAAADBhf3QAAIA2gB8dAACg BeBHBwAAaAPVf48OdcA6tbBI7OutmTsnVaVneTnhxS2MxTBKSitPoL2BfnAebc7FACINXtcdIlgy DxaJb93GAjsn5TJLeW1DVXpWIieZwWksjdWxUlUq0BXJXa8CZji1vXbtgWeUXBr6BKbqH1ADTJq5 rjvEBC5xgMqp6noLG4nyVKVnJXKWaGycVtDY0zIZTzX5GcnVbwF9wk8hYRsPNhXvj+4j+RQWpTgX YU2dm6pVTqGWNQtfu5IdYucR6/cj1g3CKX9hndbWdrUVw4Q7h192YjMn9m0CF4lvgJ5LspzspXD+ MutphgXaWlV+UvLqH/idBq4rgyZfWuWp2I9u9+BhYh/0wO88mbIsOYH8vvSm4WuX8xnIvvTjFN+s oyG/jrHXWrVr3Qg8WtHn4noAXTrO38siK02m+H6nvutKrC5t/1i/Wj96+HyHB82GSV6KHF/+5vzA slBM29SHm5Lyy9PWdjUfY+ajKpnVClwYPs19I4TkyHuRrc47tq5bvarG+oWtw1rQBD+6c/y0RDkg 7f1htLVddeOc4YQY521nKQNcZ+2pLEC9xf/0so/ZWgPfo68dbb0dt7VdTSPLrd8Y0/uK+E5Zw09l NPFrpPhmfWut1+7nwpKd+hcTaOvpoyr9bQUqkbOKLOh7dGP2Kfk2hOHLTH0TpFY5DSQ5ZScZ3pQR T7sMN7M9E5jsNHuWNemFiudCZCGP9tLedjUQ5/Vm+LyzyDFecbATxXMeM1bh1DMgf2FyAkezXFTJ Sz1Lvc5+Cwjx3U+c+gf6ofB9KfwqTBb5ua4rydP5bWAx36MHujK723sxcppGLlUzepgCk1GBPJKz kyukre1qIKn9U5+oSi71vKoWkFNgLje7VgX6J5c+VZ2UCvunEpWquq5WHtZ1BwAAaAH40QEAYAUw vG9gw7ruAACwAqzX/Hkx2B8dAACgDeBHBwAAaAH40QEAANoAfvTVYF0+poRl4/sovJmLN/gWXo3I rmqFcoz8ZeTkKlKSvOfdua6D5G+vT87SWdVbru979OSKquFwWZqvCbzYCQvDWDssNZ4qLYpkvLPn upk4fxeGkOwrupSXI4l7ZiVyUrPFmZN/2pbVvlE7V6QpcN5tJYu1t9h59z02JY8WeFxY+futb113 zHlDcF6aAHVQ1bItUvQhIDtV/S5W/fcV6+8zpUbT6j4vdXNoLfso1lOL72kmtb2r2CEG3v3Rqx2j x5NRRl/HcSPbUuRkaUjD8bUr2SF2HnHdF5yzZ0bZBU8Jtq9djcX30y42ykzeK5x3W/s74yafAudF UokxiHugwvtSYNBccmBWlZKV34TzjsVTHQ2+OYAG4vWjFzPnvpYfsj/6QvC1y/kMZN9SfSc3/tOQ v7BH2ra2a90IPFrR5+IZcBeTk+vxyDe2CYx5Ag8KNoH7Zy45yTyBu3eWdF+9zrhxfdrNaRDV+tHD 5yM8aPZ19yLl+PKv1r2mmLapDzcl5Zenre1qGiUH6BlZ3d72jWSSI+ylty6vxQ2btCxCxDMlLos6 1z5Vfc0JC7GpfC6hFprgR69KYOWKrTNt7cO2tqsqFmPOW0begWaLMbqijirKi7Xn6rKUMp4GmnmW vd+jZxyjL01xKEpbz1pb27VIfIOYvFOOxs0h8JTgUyO7zosnctA0uV5fzoznJYv8LHmyTKGHjxoZ IpkxlZyFAkKaacsjKvaj+zBmpZJOFJ+vYilyGkhyKk/SVA20K/4BHK7gPuJtbVcDqcrKJrva1//O 8yjZfo/O30VAft1ykkKMe1EBfbKPAn33B19/pp6XLCfF1668jc3VP0bfOn+zTn1S2xvdN+ynBJ+c jK1bDov5Hj2QzbhQli6naeRSNZw5eUGnHnKKytXJFdLWdjUNX9uL9UlqV5eppSpVC8jJdagqfXyH Aom5mpa3H/KeXB/Z2xv4s+RJTBW1SvcE37ruFZpzAAAAqBv86AAAAG1A2WP0OvzoAAAAUC++/dEZ owMAAKwS+NEBAABaAH50AACANrCg79GhJPQ2LBL7emvmx7hV6VleTvhj+uzfl2eRVgeLrxFqgf3R Gw4TIbBInNeb8UvP+MPPu2JMrptJVXpWIieZwflwkGtGM3tXGMukxHH7qF0keSisf6BeW35VJFeS cT5sJQ2Qs2/X1DY1YV13CBC4ZAEqp6rrLa+RyEtVelYiZ1l3QuM+7HsKsfOUPCNGvfWdX7H61mfF jXat7Q2T/dFbNdfka1eyQ+w84nlUN47aZRc8Jdi+drUV487gHE7Zic2c2LcJXCS+AXouyXKylzIW DEwqNGEAFjjvBvZ1khTis/ThSg3hLYb90b3Os2T+VbkyfO1yPgPZPy3fyY3/NOQv7DbR1natG4FH K/pcKhpAF6vXZ0HtnAXk+867WE12PrJn0d+Zknp7byHsj55F8mrda4ppm/3qX1ZvtLVdzceY+ahK ZrUCF4ZPc98IITnyrqPV5U+NYXEzjoPzTiQUyFyeVZn4qYwm+NGrEli5YutMW/uwre2qm/DQDZy3 ncBMeIUscWQv5S6G7GOqSqpYB9PA9+hrR1vPWlvb1TSy3BaNm4OviO+UNfxURg4aI8U3q1xrvUmc HihbvcqxDUFYTynRRXa7islpMeyPfkJOA0lO2Um2eTBnuww3sz0TaMy2+dxdknjak0U99ra1XQ3E eb0VmLp0umaN/neex4xVOPUMyF+YnMDRLBdV8lLPntmeM/f1Z2p7szc2+y033J/OVtgKF2iX88fe ctgfveFU6KNK3lhTDzlF5erkCmlruxpIav/UJ6qSSz2vqgXkBC6zvLVUW2/4z7D8kp2f+guqsD+z y1/H3zLrugMAALQA/OgAAABtgP3RAQAAWgH7owMAALQB/OgAAAAtAD86AABAG2B/9NWA3obFEP4u OeN30gvD/l0U+HS+EjnV9ltzlspojiaQCfZHbzhMhMDCcK5VYhzNfkHmXbQk183EqYYhJPuKLiXl VN5vGbsi2cPOeBJnepl21Uqx5YZiUtuVPfOKgR+94RweHtLPsBgqvNKi+0NEHU+lVf0uKpGzrF/o 4dEyakYoiXYlG5hMafhdJZd6edtl5G/TqIn90Vs1p+Rrl70yonEdx4eMPkwetcsurNPa2q7G4hto FiuevFcYv9xkYrEJ88UTuEjK95sRqakf6huP+U5i3vS88pOUkb/qsD+613mWzJ93VmdZ+NrlfAay b6m+kxv/achf2DxNW9u1bgQerehzcT2AlpHjS/ENgez8BcY8zt9XgXTfj9GX39muAvlXHvZHzyJ5 tU55MW1TH25Kyi9PW9vVNHxPuskRZPm+Wt3e9mm+mH4rT9JOxynOnE4TG8b3+8qbnle+nHxACTys hPOvPOyPDk7a2odtbVdVOH8+gYEORKxWv9WkiW8QnDfd+Wdq/uz6tBi+R1872nrW2tquRZJxcJOK cXPwGbOqxm0LJnLQGCmV9FveepdLWJ8yg/WNxGuVPkNT4eC+TbA/+gk5DST5PCtpqgbaFf8wDo98 xnER21/lm5eL5ccZFjPyaGu7Gkj4xpe9c5Jd7et/53mUbL9H5+8iIH9hcgJHs/Rb8lLPUq+v35zt qkp4xvzR79Gwyqnpsdr2b9MnJ2wXsudvA+yP3nByqRrOnLzQUw85ReXq5Appa7uaRrU/nNSurlx4 XiHF5AQus7y1lKw3kJ6386vSx/dTyhv3JTrz57ULbf6N8z06AABAC8CPDgAA0AbYHx0AAKAVsD86 AABAG8CPDgAA0ALwowMAALQB9kdvOr6PJlPTjaMlv6/lXAMANJ0Kv0dPtQFhI2QItDMXsDH2LMJh YtWCuFJnRRmfWlItaKCjsghPCkyN+8TaCmTpPaw4AMAqUeG67rGxdFqCVINkm0anscw1NxB4SvBZ XFsfp3PBWKwgYDKN4mFjDAAAUIzF7Y9urN1jS6jbtmUccNv6lFQsMDiuyXlR1eqG7VwlEQCgpTTX j54cK1dlmQzqa4UxwZB36j4u4nQKBNIl+ACRvd68cgAAYPnUuq77wqx+GOesfq5afDJTK40lhPP7 jhbzozvlF2sFAACsDE3YH91HtV/HFda2HWYv8A4jAAC0gAV9j25kjp8G7PRkhpiqLJBzktmYHnfq U6Ai35jY2Q9VkUXhAi/wAwBA86nSj576cnhGl/DGyb2E4z/tilKxyxrptm0LuKgDVcSRpB86rwvc Jq8Qn/8+l1M/IAcAAJpLhX70XK7lQHr4z1xkqdFp1EtWEc9A5NIqV+Zc6QX6ECsOALBisK47AABA C2BddwAAgDbQ3O/RsxP43HzBmgAAACyNWr9HXwxN0GEV4UkIAKBV4EcHAABoAfjRlwkdCAAAVaHs MfrK+dFjNo4wUpao0rJYz1YDAKw19hg9lx99WWrbJJeZy7VEzLIwHokq7EzfujoAANBm2uFHb5Qy yyV+slm2IgAAsFAq3h89XgnVubCrEbfXGU0KDKxmGpe17ZZvYGrnd9aeVx+f8FScA3SjioA+qf2Q Vx8AAFh1Kv4ePUq3Dxk2PmmQbBNlC4//NOT7shl23c7vLFhAnwDGQ0w4v7M/A/oE+iFs5gEAoLXU 8T16MVviHPhmyZlX8gL0sS2x82gZfZwpyXQ8EQAA60Vj90cvZvPqex0slz7JEXM96njBkAMArCcV +9GzUOs72EsxZrlmuTPO2JdpCLPuAABrSMV+dOMNr2QGw30e5wk7g5PFk/LjDLYLXKxJb1/+gPCM +lSI8apBWJ+4mbYyzjcJAACg/VTrR099/8uXzT6U6qF3vkcWEJKqqjNzlvnz7NY9PPgOaJilRQAA sNY01o9egKbpY7MwDZvfFQAAUC2s676SGN4NAACANuyPvobQ8wAAYNKC/dGhGJw7AIBWEVjXPWMI AAAASyfpR58PuJ99+XURrUTpozxKlHREz0QREhISEhISNiOUmSQttRa5eO85Ebn01SfnFv35V16X jshM5mHS/oso4sSJEydOnHgD4kfWXYsomWnpqMiiP/bHT8T7o4vW80i305UESrrEiRMnTpw48SbE VScK5+Zc7K/XJlrLTE+01jMZ67HMRM+0nmmZiZ7N/yROnDhx4sSJLzc+/1NrEaX1fDAuInp25Ee/ +uL1yMLrmaiO0pEfXSQa6B/9SZw4ceLEiRNfbvyEadYz/chnLojIpa8++V/+9E//VET+9Y1h5/91 Dma6c0vn4D8POtI5+M8DPdMix38SJ06cOHHixJcbT5rm2X/O5Bb5r780EJHnXrw2/x79sd+6RwAA AGA1UR3ZePSPvuF7Sz7K0YSX9QkJCQkJCQl10DT/fwkV6IOaO2LRAAAAAElFTkSuQmCC ------=_20041011113302_59241 Content-Type: image/png; name="ssh_session.KOI8-R.png" Content-Disposition: attachment; filename="ssh_session.KOI8-R.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAApsAAAFpCAIAAABcQnS8AAAgAElEQVR4nO2dX6hkx3ngv9a2TPUw Mt3DyEwbKcw1NugqzpIZErBEApGwYS2Th0hkIVL0YCm7YE9MSLT2vtjkn5Y8RMKw8ThkvSM/JFIg XisPRvKDgxRQkAwOM4ZNdA0RboGF+2IN0419mS6iZu8+nL5nzq1/p86/7tPn/n4PRfXpqq++qvPn O1Vfnare/77yf7SIEmk6nGk9+Zdr47PDL/7JFwW2nyvPfXM9Vw5hW8K+yFKkL3pZIq5kqWV1pFpc 9PN/+9zuzvnR6dFsPtNLrfpKL/V8Np/uT0XSQrXqKxFRSg3UYKEXo+HoqT94anx2rE4r1Vfz+Xx6 ffr8N14cqOHOPTuqP6y/zfpKjtSrEBd1VJ3tjNfQDoVafvbO3pOfeVKWMrpzJCKz2Wzv+3uXv3Z5 8lvzS/Loy/dcu/DOzviec7ovqi/X/uHahf90n9ZaLfXrr17TnxjK1ydv/Nb+w8MHxvujl7/28uI3 1c7Xx+NfOif7g+FpNVBD1V9dh24d6rnOS95rt+mlViJ6qUWk0figry5/9RnMeWd48olHLj3xyNqu H+Jl4qIzD5sqcVEieikiopfF433RS508eqRaXJZaRB765KOvvvrq7GA2OjtSp5VeaqWUukONhiPp y1H11Sqj1ouDxUANHv6Nh4dnh0opEZkfzKfz6cvffllrGZ4dKUnMuWRqHBNXOWmWWhI1YuKrB7od T1pge+OeehVpnwLnZalHZ0e3zPm7s2vfv3b5Ly/Pf0tEy+653Wl/sSvnJweTq9f3JnqifqYmB3tX r+9N9PTe5e6+nt5/9n71L4upnk+/P1VvK319rvVi9s5cH8y01rODuV5qObrLRMSM13Gdp2HRe623 tj76k088kliC2c9ken0mSz0/0EfWIT0laYR4W+N9Garh6LSMz47k9tUx+uudDJPTXapHnu1nVO2R O7WbvHXt+b+9cvGeixfuuyBL0Vqrvprr+ez6bP/dfVlKiuqrnY/sPPCrD9x7z73D4VAvtdb69e+9 fu2f92YHMr5rOD63o5QUaBt63i3uzeulLOb7lz79xGA0SHvnc5kvfkvtf2+y+4Pdyef1zp+rnS/t TPZn6i6Z/+F8+MdD/Y7s3jXe+8O9yZdk509l72OTC49fkC9r2VeTj7994bsXBkM1VCMV00d3h2vq tfe+8ld/42yg1ADXyGIhk3em+3OtjopPQxGxDxK2LTx2mkR27zo3vnNQ+3UCAAAl6Ku+0iLZ8NJ/ fayJkqbT2WR/7rMWIps3V4S5oXGa9t7en83Vzl3jAWYdAGDT9L7yV3+T9s4vZfrl1cfGE+fWhXvG g9tl8qPZZH8ushBJn/3OeG4C4huPm3+p/uDCPTuDgUzfnU3enms59gbQCk8BceLEiW9zXCklfRkP h8PhYHDk7hSR6XSq+iqdDXpb2jtPzfliIW/+2/TaDybz+Xx/rkVWw616qdNI9qAvrvqye9dwcLvM ZovJ/lxEVMYqOOO5CYhvPG7/pZey9/ZURMZ3jqS/GpBPR+kjrxbixIkTJ27Hk8j8QOsDvff2/rV/ mUynMzlCL9VReq1E3Zb8SL3m0+ns2g8mTle36hceoR2NBiKy9/b+YrmQpcyWC1mKM56bgHgb4r6/ pvPZ9N2FiOycOzc7WMiywHVCSEhISOgL7YOT/fnVvam8JyKyc/docl1r0UqUFr2a65500I+PjS9E 5CgyOHdWjYfDkRok/03ni9lB0oNPE5vhzrnxzt2j2Wzx+g8mAxksZBEIRSScwAi/+iefl76cv/v8 vXfd+8zXnnn6f14ZqnNyWrJpXv37557/2+e/8r9ektMy6o8MCZ+6714ReeWNSXLkwft2ROSlN940 yjKOG7nSIwn28eSIL41RShZbkzaEgdOklNx/YWexkFe+++ZAieoPtP/aICQkJGxPuHt+PDw9GvRl sZRwOD+Y7b2dWMlb9nH3/LB49oqlD1Rf7v/oTvLB0ZVvvf7QL+0oUb2v/NXfJFPhZrPFtbf2xWJ4 Wo1OD4enZXR6sNALvRS9XHX3tZbZQdbRfozd8+fGdw6u/tt0en2WnXzvDiUvgRW++PVndz+8Ozo7 2v3I7hf/5IuP/ZenhneOE2eDLOXad1688tdX/tsfP6P6Kns8DRMr+6n//ORnf/8pWcqnfvXo5+ee yqbMHk/jImLkEpGX/u5KYokN+clxZxq7lJU5T5K99mbRNmk8DJ6mB3/x3sFgVbtBX6Q/cF4YAACt Yvf8ufHpwUJkMJDFeyJL0cuFyECWCzkaAE++pBfRe2/PW5JdKbn/F3ZEZPKj2cuvXXv4gd3bkmWV JDM2vsgMsaq+GimllCg1kNtlcMdA9Qfq1ownUUqpvjIyJuF4OBARPdcrS7AUkYE3npvAil/8tYfn er5z944aqpdefOnqP708f3eqD7TW+tprL1756yuXPv/0QovcPlrV/ricl16bSGI7TYNqKSYicizN Zz/3RSPXZz/31EuvvSmyMuQrCcf57OeeSiJf/fKzpj6ZNLeS/cWzRduk8XgwmT5YiMjo9EhrLTJw XhWEhISEbQtnB3p6sNBaFgsZ3C6DvozUYKRkdHqg1GCoBiKrr8NnB7LQi8WRCzIJS2SvWHqSUR/I 9N2ZiOzcvTJztyUe9NlsMdPmOOpABomXXfVFLxfynsh7Mli9AEgylV1E66V2j9DeLiIy07feMvTS G89NYMfP3Tkan79v8qPJ7l27g9HgmT9+5vV/fHEynU6uvfLiX7946fNPa5HR6ZFSSinllLOywccN s12WQZrm+JFbP7/6F8/auVKZ2Xi2LDvN0ZECbdJ0PJxsrldXiyz1Yrl5HwEhISFhTLh/fZo8zbRe LN6T1dpZt4uIDPqikzH2pRZR+9fn8/l8IIOshBLZK5aeZp+8s+qyP/DLu89/6+ptyY/J9bmILJaL bJi8CCTmcDW9+XYRkZEaqL7IUrTWo9NDWcrsYGFnz1qpEs7/3FD6w3Pjse6fe+W7ryxmi7139ubv zgcHbz/3tece/swlvZTxcKjuGA6HKiAnS2KYzVJE5GgY3KhO+EjKN199M5HwyAO3Xh2cpYh4Jbck DCeYzrWIjM8OkyrY1wMhISFhC8PZXGS5MmqyFEnM6pFxVTLQWicfkiVbCSwS+3gkwZm91+v13tfz ZfeVfup9vV6vly39zPtPffADp3zZZweLxUJE5N7z48k7eyuLfnxsfBW+vT8fDpUWLcvVa8LiPRGR hYg6cpHqpVZK9udzO/sqgdYxYWSyY2FfRGR453hvqvf39y9/+fJDn3xocbBYHCzm85lSSg0GSqmw nCzhNFlHuC+vk9SQpxKe+MxTzlJe+rsrn/rVe7OGv3CbNByGEwyViMhkfz9N6bgqCAkJCVsWTqb7 IjI7mOuVD1sSM5mEifmbHcxF1GR6ZOwyEuzsvV4vSdJ7X8+d3VP6Klevl5SevBOEs88PFiIit4to WVn06cFCRIzP4Kaz2ei0UqI++MFTZ95/qve+3qn39Xrv65061Tv1/t6Hfu7Mh37ujBI1PK1m72qt dfpVXCpEJF2ZNi+MTGaESqm+PPLAxaf//Omde3Zm12eTdyYXf/Hi5T/7kmitJUJCFmcaEcnYVxF5 7i+fNfPa0gzJIiLyxGeeMiVYpWQLeuIzT5Vpk0bDYIKBUquL7D3H5UScOHHi7YzPDxZ6qUXUYimy HCyWMhBZLEWScDlYLEVE6aWeH9nKrBwje2qGE868/5SdPatDNvuNG4dJrsTUJvF//eENV/aVkKs/ mCTJ9FKvLLoS0avdim7Fp9fnqi96qX/4wxvi4oc/vKGXenBaTebT+cE82ewoFbIqo7k+uog+0A9+ dOfyly/v3HP/XKvJOxM911r0wx9/+Ev//Xdm70611vrAK+GRT1yUTOc7e/yRB+595BMXsz3vRz99 KY0X6qM70wRK+eZ3rhr6tCcMJ1gkFTm2+ZX70iJOnDjx9sSn83ny1JKkk52stCGr+FGoRWQ6n+v3 FkpUVk42+5kzx8x5ws9/6IyR/ZipPV76zZ8eZvP++Cc37dKNiiQpVf+oj568IGQsv9JLrZeitai+ Woj+8U9uGireuHFzIaL6ajbX+kCOiswKEZEjN/ytPXbc8dwEjriWhz628+yfPzu854IWOXduPL7n fjVUIjJfzh/6+ENf+r3fnr47laVOamHIeeyTt8x5YkQf++TFJM3z376adJdf+PrltL7J8cTWJnK+ +Z2VgzyRmX0/0EuxST8rSOKeUlSa94WvXy7cJg3Hw8kGp5WIaJ3sN2ReTsSJEyfeznjSGVF9kWQT 4eVCySATiohOHuBai8hAL/UxOZns4sHIntXBLv1YRlfpRkWSlHp5ZNFFHFvSqr66+vY0OTI70Dcy Rv3GTw/1MpmGpyf7M30w1YuFIWQ2WxxpuerDzTP9OSOem8COP/ZrF5/98rPq/K5oGQ6Hg+FwPB7v fPTB83efH/aHq5767/32ZDrRLvkpj3760vzoyAtfv5zEH3380qOfvvTw47fGwOeZXM997XIiJ7Hx j33y4iOfuOX8fvTxSxnxt94DsmkSHR5+/MlHP30pmz6rW+KzL9QmTcfDyZJzPZ3Pjl9zBXeJJk6c OPH1xqfzueqLFpG+0iIig+SL8FW4Oq5VX6bzuSwXIiorJ5v9xz+5eePG4Y0bN2/89PDGjZs3bhz+ +Cc3//WHN4zsWR2M0s+cOZW1IGc+cMpRulkRERHVV9k+uhnunB298r091VeDvgxE5kudDPHfvHko skhmPitRr1zbU5KsGnsse7LyzM65sSzT3VuVN56b4Hj8sY9ffPrPnlZnd2Up6uxwMBoP7xir/nB0 53j80QeHdw/lqKf+P576ndlsZstJusgiq+PPf+vq0Sz0Y2UZx9NchpzUBf7o45ds+b40aVlXjkox ZL7w9cvxbbKGeOivZF13kcnenshC+sp5URESEhK2LdRa9FJGSonIBz9w6syZ3pkzp868v3fmzKkz Z3of/MCpn//QmZFSybj1KktWQvHsgdJFRESSd4IkHs4uR+il7md+iMhq7lwS37l7eO2tyYv/dO3h X9nVIrIUrWc3btxMxiLmspC+ml6fv/rPk4c+rLQM1HEhb74z3bl7ND6nrv0gKVXp1dC/Iy4i4QRG /Mo/vK7P7ojo4fDc4I6BWr3CKBEZDcfy0QdHd81neiYyuHTfg7JqfVPOo49f0rJqFCXq4cefdJZl HH/48UsiaVNm5SjPcQmkSct6+PEnXboVaJO1xL2nafeusYhMfjTTWid99JWxd11axIkTJ96e+Hw+ S9a+HGS+JTbpixKZz2eL5fmhHJNTJntGBzv7jRs3kzXjbv708NT7e3Z2R0XE9KNbLw5LfeGec1e+ 9fqL/7SXdKNl5TodJNJf/Mdrv/Nnzw9lrk6P1MDsk83nejZbjO4Y7Nw1UplRAmc8N4Ed39nZ2fnI hdGdo6EaSmr8+koNZHz3zs7u7v2//ODFCxd2f+G+0XhcQj5xOx7468KHd0Tk6lvT4emhiBz3oxMS EhK2N1wsRI5Gi3/8k5s//snNGzdurkbOf3p48+bhjRs3kx7j6nu24330EtnDpYuIyEL6Ay2Sm12O 0Kkf/WjWXNrlkuTxPb5z9NAv7lz5+1d+98svvPzq3t7b+7KUa29NX/yHq7/75RcuP/f8UE8u3KXG Z89JX1lC9N7b+yJy/0d30vnPIjLP6JHGnQeJty3u+2v3w+PBHTKZTN947VXdF3X7rWvAeWkRJ06c eHvicz23Hcd6KVovZLnQy4VSA9UXdXo01/PUPqZySmTP6lAq+zEhKzveV73Dw0MRufL3rx99WJx4 iI+c7X0RLbPZ7NXvX5v8aD49EL0U1ZdhfzY+rXbuHAzPnhvftTO6c6TUUJbaFvLQxy6Mx4PFz+SF f7wqS5FkzFlEiTLizoPEWxV3/rV7fnT/hR0RufKN1yeTvfG5HXVHMiv++OVEnDhx4q2MP/+da2/8 39VX3WF2hvLorz+QzBlK5Tz/7TcKZ8/oUKb04xV58tcvisiTf/D0kUX/1tWMPT4KRVYRrWcLPd+f zA60nk91Ms9vOB6dVsNzO6OBEqXs7HqplYj05eFfuTAaDRY/kxe/ezX5XjxxJytRWdeyfZB4++LH TpPqqwsf3bn4kbGIfPM7V994441z584NTo9Usvp/33FVEBISErYuFJm9O528tTe/vh9OPDx7bufD u6M7x7fs41JLXxXOXrH048ef/I37ReTSF44s+uVvvO5c8/zYz/f0Qi9kqZMj0lcDNZDblX+t75Wp Vn310Md2R3cOROTNyWzvren+u/tyu5L3tLpd6fe03K6USBLJHiTetrgcnSbVl527xvfdszO4Q0Tk m99585XXXh6f3VFDNRqMjpwszS4yT0hISFhLmDCbzWSpZZl2vl1hX41Gq43ODAmFslcs3ahCYtEz ffRvvJ52lgOh5CU4HmY6ee/pB355997z42Tp+cVCJu9MpS/713VapTacV8KcUMnw9HCgZGe8uqbf nExffW3vzbeujs+O1enhQA1ERN2ujs5+/NVCSEhISGiGMWb30m8mffRnjvroL7yS9MOOtnzxxEVy EljxbCdveMfwwj3j8bnh6I5b+47DljL50ezqW5NXvvPK4PRgODynlErM+fHzXuxqIU6cOHHiRc1u YtFv9dEvv/CKiBzZe/HHcxPcii9EUrudxJPl72d6Nr5zfO7sUETGw0GSXousXLOELQ71wWKm9Xyu J/+2NzuYjU6PpK+Gp1XiglksZdDPnvcCVwtx4sSJEy9ndi89+qCIXPrC06sP2qfXp0cTmFePb09c 8hJk4qvZzivvvU5DUZPJZDIRrbUSSSbri/g9B4TtCeVWZKRGyTU1P9CqL/pgfuwsJ+c9/mohTpw4 ceIlza6IiF6uHtKi+uqLn31Eoun1Vp17AAAA2BRPf/WbafzYmnEAAACwTRyZb5WuApvd6BMAAAC2 g/6tUfej3VTpowMAAGwb2u6jC330ddHr9U64AgAAUBfK7qNvrx+9d4RxZIMqbYrIWh8eHp7M9gEA 6CCd8aMnU+4TUivV5kn4xjcCNVrWRBSmGgDgZNENPzpf0KWkbzabVgQAANZK1o+++h69ih896Rfa veT0uDNN9q/UFNn/2nltu+XrmNrpnaUX1ccnPBdnB90oIqBPbjvE65MI4Q0AAGDbyfrR+0ex8n30 xDzYFsKw8VmDZJso28akPw35vmSGXbfTOzOW0CeA8RITTu80qwF9Au0QNvMAANBZ7D56dT96OVvi 7PjWIn/9+tiW2PlvFX2cR7LH40uhmw4A0AXsPnpL/OjlbF5z08EK6ZPtMTejjhdsMwDAyaRmP3oM jc7B3ogxKzTKHTliX6UiJUbd6aYDAGw7NfvRjRleWQthuM/TNGFncDZ7Vn6awHaBizXo7UsfEB6p T434phP6fP/ib2dp+LUJAADaSL1+9Nz5X75k9l+587fDk+9i0scIjxk/j7fu4X5wQMOYGlWEDjoA wHbTWj96Cdpvk9amYfubAgAA6oV13bcSVoUDAACDmv3osB7oggMAgEln1nUHAAA40XRjXXcAAIAT Dn70EwEedwCAzrNl+6OX2++8XK4q8psuMRf763mMOgBAx9kuP3otK7TXTvyK6yXAEgMAQBT1+tE3 3jcFAAA4mdS8rntgwzEfvtVVw6uuVt8w1LffubHrq1OfQovE+eQHjsvxlixXtAErtwMAdJtGvkeP 383T3nc8fNz4t7SJCmysHvNKEVlu5L7szuNpoXVtvQoAAB2nif3RE7Jbs+SmSX+Gjzt/NoRvW5TS EsIpa+mIx5SCsQcA6CbNreseaTx8fd8SfeLmCI8Z1EKr6gsAAFtHI9+jJ/PjIselCx1fM041mtAt Umb1ovmMDQCgqzSyP3qh/mXMTDHDt23vdx4jPOucLjrab2zVmr6y+OQX2pc93A7OXWIBAABM1rk/ enz6mONFh/SbKLqEnrn7vhf9tyi8FgAAdBPWdQcAAOgArOsOAADQBbZsXXcAAABws13rugMAAIAb /OgAAAAdAD86QGdh7QGAE0XH/ejsBdcEgXWB1rwPffslV4EFhQCgGM2t694G6nqiRW4QJ54FYYyF d3wJYpQPf03uS2+vfuNUL37hXmfKpu1Hc/LbaflYhx8AilHvuu7VNzltJ/bOqkncueNq2Dw45Yi1 YZ3TyuZaHV96e807W4fsxndOyYGf0BC0MwDEs/n90YuSu4qqs2djq1T7XmdGoakagTVrC3XCinbX YtI7t8ap98QVPV9Fz0vp9FWuE/vVzbm+b269DDnxV0J8Yjr6ACeHDe+PXhRDZrZ/GejI2sl8ckpr VTpvgnMEu7R8X/r1P9xLnK9C56XoeSx6nfj0Ocys7Z/VPDDEEiMH0wsAldjs/ugliBl5zj1SsWjn EHRzjtii8ivqEzPqXiPOXnI8pasZeZ0E5IfbJL5eRdu2RHreFQBOBBvfH70oG3wwhS2lb6ZYXQo3 /dyvnrE6dp87N0uj2pbQp1E5AAABNrw/ekNsasZ17tR0I28J13h8Yp8+hkPX0KeQ/LpwlrsGZQoV UZc+1eUk91ehLOHZmgDQDTa/P3oh7AdT1h9pHEz1seem+dL7MOa12fPdAomNBMZ0KiOXHG9Dp/wY PcP6Z/HpUwjna0GgnWOOZ33MkfJzq1DlOrH1MdrNaGTDGe+UY9cooHx8NQHghLLZ/dFrLMJ53Ji4 FCMnUrg93Sk3cbyq5ZQMpA+0Q4lS4suNVMl33Dk9Lb7o+PSR10lYn3DKui7FGucNAEDXYF13gO0C 2wwATljXHWBjFPWqCOYcAPw08j06NEr8ZHtoOZwyAKiTbq/r3kkwAwAA4AA/OgAAQAfAj74Omv4U uPOfGne+ggAA1en4/ugnk83avyZKZ4EUAIB8Ou9HL7EuW72O6qaXz4uUH17WJsW50m0h+QAAsBnY H71LOBeeS3B2c42V5411zbLHw+eUjUAAADbOFu+P7rNG2aLt731zLZOd3s6eXekzm8YWbps6p/7G QSMeWKjVkG+vP1qIon3xQNXsxHaWQteJcboBAMBgi/dHD4wM2wuwR8p3prdNb3rEWKO7UF/Wfm+w dbbXAM8lXXjcZ/vDLxm5x53t7IsH3roAAKBmtm5/9Kz87M+1WYv4ddHDlrjQe0a8/MCC87nynT1+ Cb5I5Sop/jeGEkuy000HAPCydfujx5S1jX3B1Fw1127Vm6VcOxtvA5hkAIAm2O790Z0WJWBmipq0 KiYwpgWalm8kTqnljaeEEHtYpagQPmMDAPCx3fujpwXZE8oMV66RPrKIrO+8hB86Xv/sv3YnuJD+ Nrb+6U+ffN9xXzv76pU7M5H+OgBAbXRyf/Tq/tpcyYHiJNiBLufhjpefKySsefh4ILszS4xzvSi8 BAAAuGFd9yYo3ZmOzNgNq9aNWgAAtATWda+EParcBlFbAeYcAKBe2B+9EjWaJSwcAABUwu6jd2xd dwAAgBMBfnQAAIAOsN1+9Ka9zifHq51w0uoLANAlurA/eomFStpZ0NoqAgAAHWR7/ejZNWRiEpeW n9L05LVC8mu3/SyZDgCw3dTrR29tLxNbBQAA3Wb79kdPcHYonaulBg4GdoeL77AabzDreXVwrq5q L7ZqrPxaqL7Gaq9ZOUZxWbEVF6wFAIDSbNn+6AGc+3PL8ZeMrIbZtd9Lq1p0LzI7QblynVu02aY3 PVK0vkZjOouw44zbAwBskm3cH91pOUqUUn3V9PDOK/ElNkF8E4XrW3oBeQAAWCvd2B99gxh99M5X +bD5fdwBAKAE27c/uk9yXTPyCmnekmmAVdSIqW9LqgkAAAG2bH/0cKG+fb6NeHZfcCMeLsKWI5ab uUoVnPJ92PU1KhKe7BbWJ+xNsDvoxkw9+u4AABtgu/ZHD3vQ4z3Hvo29fXa9ls3OA5SeH+f76WyT QlP6C6mECQcA2Dzbta57q9Z46QBN7+MOAABrY7vXdYdI2McdAKDzsD/6iYB93AEAus/2rusOAAAA t9guPzoAAAA46YgfHbcuAACccNqyP3pFk2x8Pw0AAHDiwI8OAADQBU7I/ugAAADdpmY/enbjzurK FZLDwDsAAJxkGvGjp3a9UJaKhQIAAJxomvOjV++sJ28GRUssXRwAAMAWw/7oAAAAHaDV+6OX6OLT TQcAgJNJ2/dHp5cPAAAQRWv3Ry/d1eYlAAAATiJtXtcd2wwAABBJe9d1x5wDAADE05Z13QEAAKAS rOsOAADQBdrsRwcAAIBI2utHBwAAgHi2zI/O3m5V8DVd063anPx2Xg8tVAkATgT1fo/eNLUsCWdI sCfVpwmMv9L1c7Ir4tmJc+XnqpTmygr3FWToE8CXsumF9pqT384lAuPPCABAndS7rnvta8Y1QWos nXoa1tqO2wbbacILPdMDbwlGPKCP07YZOrT81HQG2hkANsuRRa+8Zlwhu561Q9ksPkuW/deZPr5o pzLZvGnR2eNNP6xjXgWc+tSrWNHzUrT9S6evcj1kRzWy0oyUufUy5GC/AaAV2KPuteyPLsUtkxzv d/oGsZ3JfHLWgE+HcqKcx9c/ilvivBRq/6Lnq+j14NMn3eHX+d4mx011miVXDmPsANAK7FH3evdH l7weTK4f1On3raibrUOjT+R4P7dUmFcVM+peI85ecjw1rtvv857ESwj8W1oOAMCa0XYffc37o3fg sVjv5KzSDbLBlrT73LlZ1vkKVeUlqRY5AABrwPH1Wnv2R88KrEtUGMOraoyy2vokCVLq0tM59d1w 6Dr1WTPOctegTKEimjspAADtol4/etGJQr6J4s75Sqn8dLaaZGxq/Eyr3Mnh2WlTgeNZBbI/7YJy sfMax51DzU49C+HUNtCeMcezPuZI+blVqHI92Prknsfcetk1CigPALAm6vWjl3i0+bI4jxsmtlzR uSkjVSqtQLkSm5hPEJBQ6LyIR9US8gulj0Ik8zUAABi+SURBVLwewvqEU9ZyyQEArAHXKrAtXjMO AAAAnDTiRwfoNj4vCQDAJmnie3RwEvjcfM2aQEU4ZQDQRpr7Hh0MMAMAANAc+NEBAAC6AH50AACA TmD30fGjAwAAbB92Hx0/OgAAwNaBHx0AAKAL4EcHAADoBPjRAQAAugB+dAAAgA6AHx0AAKAL4EcH AADoBPjRAQAAugB+dAAAgA6AHx0AAKAL4EcHAADoBPjRAQAAugB+dAAAgA6AHx0AAKAL4EcHAADo BG3wo/d6vV6vt+ZC10NX67UpKrbntl9p264/ADRLjX703hHGkdyMh4eH5UpsgkafmL3jNFdQRUro 2ebqpLTqSitBCf2Lnpdw+q04ywAnljr96MnjJvvQ2fYHaO2kTZTQ2ufjtugJa4Y7GqDNZP3o/dWx OvzovV7PuPmzViHmuZCmTyxKmsWW4zwSSJ9bqDNLUf2LEig0W03DvkbW18hbRf+AfN+pyeoccx6d P2P0yU1s5Mombu668tXdV4oE2y0s01mF+Os5Jn3MfV3j9QYABcj00VcWvQk/umHgbXsfSG8M49ty siY/+ygxXgViyrWzlNM/KzAmmU++8Uw3aifR9U3+yuYq95ANy7dlGuWG5RhCnDJz5RSqha9B6r2u 7PTpqYw8Xz6xue3gOy++7LnpjRZu+noDgGLYffTq36P7nnrlpBV9FgT6EC0hsvcZSXx9ixbn1LNE e8aXaxjR3IzOEYsa9QnkKnddFbJtvpTOF52i7bCG+wIrDrBmtN1Hb+h79E3d3i18rDi7O/UKb05U 29qz3NhJveVG4nzTLVd0ePSi0BiYtPKtFwBKsB3fo2/qidNouUa/arPK1EsVVWMGnGspaKsxLp54 d0PkwUJii5Kc3yYkA5x06vWjZ3sPdtxIKZaPPP3LN4roPG64JG1frF1ubhViyi2BoWraRAH56V+p qUtFxdc3W67Tg+vT06eMraqz3bJyfImlQnvK8UsoV46vHZq+riLvi9x2s93Yhra2MrnXs/EKFTiP Rjxw3Ra93gCgHmr3oxtPE2c8fDD8l33cWYodiae50eaA8jFNEZM9V/mYipQ4L2H16iqidEo7fWDU OpC49HVVy31RSEh8EYWaoqLwsDQAqALrugMAAHSB7fCjAwAAQA5tWNcdAAAAqsL+6AAAAB0APzoA AEAXwI8OAADQCfCjAwAAdAH86AAAAB0APzoAAEAXwI8OAADQCfCjAwAAdAH86AAAAB0APzoAAEAX wI8OAADQCfCjAwAAdAH86AAAAB0APzoAAEAXwI8OAADQCfCjAwAAdAH86AAAAB0APzoAAEAXwI8O AADQCfCjA8DG6fV6m1YBYPvBjw4AANAB8KMDAAB0AfzoANAIvV4vfiz98PCQgXeAqmT66P0khh8d AJrAttmHh4cb0QSgm2T66CuLjh8dAKpjW2vsN0Cj4EcHAADoAvjRAaARCvnRAaAG+B4dABoifpi9 1+sxJg9QFb5HB4DaoXcOsH7wowNAI9DnBlgz+NEBoH6KmnPMP0AN4EcHAADoAvjRAQAAOgB+dAAA gC6AHx0AAKATsK77CSH9mqjQFKQkV5WvirNfMdlybK3K6QkAADWv6258hGo/prN/+Z7mgYe78yNX 565NYXvgS58tMaBezGoYTssUkG/85atyZL0M+YbASGOZpIz8sNiZzCgr/NM4wpIjAACF0HYfvYof 3Wc8nFYqbC18D/fU/mUNYdgKxuiZPR6uS5rA93phizLKteXnmvBI85aVacRz81bEaJxcMNgAAPWi 7D56035041GeGp5sj9CXpoT8WtLbrxTSmJmsKNZoz9JysLgAAFvGOv3o1ReGDO/PWFS+L311cyjH +/SGKFu+0aGvy6jbKlUUXu/+1rZjwunsAACAKJrYH933UC46MFuUovIr6hMedS9K2MFcC/ED+OlI iaFPiYXAAs3r9GjgRwcAKEfNfvSEsKV09rNrfHyvbfnJ+Mlxa6b6qHuNrxdVBlEAACCeBr9HD/TP cgdvjbwlXOPxiX36GMPghj65Ag8z5MqvcSdpY2ZcjMI1lh6jGAAANEK9fnRjXps93y2Q2Ejgc6ka Vio7HlBoorUzvXNeXlifgHBDN9+8v7B8Z31jis7GS/unAwo7U4rrvDjLdaqEHx0AoDz1+tF9M9ec T+fwNLf4XL6DhfS0j+eqFyncJ9OOV69aQP+AnHJ/xaQMZ6/lVAIAQALrugMAAHQB1nUHAADoBB1e 1z1+sv120dV6AQBAJZr4Hr0ldNXCdbVeAABQBfzoAAAAXQA/OgAAQCew++h1+dHXs25J7fSO2LQi VelAFQAAoADN+dHDa3qn1LKUWHZZEnuJkvDKLdm/iq4r7hQSr6pPTlaf0vIBAOBE0ci67uvHWMbc tyy5nab6ouVFXwICi8I6X0EKyWelVQCAE0v9+6P7VvF0Lghqr8bqWxE2vvTALiP1bgkTo4yUmppe tC/ua2pnY8YXAQAA20Tt67r7rIjT0AZMbMAwN0fu4upO9QqRXe891xIHjseMQ/jamZF5AIAOsjY/ evX90JrIYksIDNHnlhu/lLoT3+i6z1qHhcTrCQAAHWBNfnR7MLze9Am1uMZL4JzFFqDeN494gcbb AHYdAKBLNPg9us/MBMyP8y/nnqcBIcbIuTFO0JwZs6e82Xqme5sm1DL6XUIIthwAoIPU60e3ralz f+70uJ0lLMdXbjrDzudCNuRLxhBmO6y+xJHlhmfeGYmzP40Zgr6Zg7ntY7wlxMxABACAjlC7H903 e8sXt3+WSB9OkCs/5nhk4ni1AyljlIls21w5AADQDVjXHQAAoAuwrjsAAEAnaG5ddwAAAFgfdh+9 M/ujAwAAnBzwowMAAHQB/OgAAACdYBv96OEVZnxZAqJY5xwAALae2v3oa1i/vdDX1QGDnV3BragO AAAAraL7fnSfwV7/8u8AAADNUfP+6EX3Oy+aHgAAANw0sa67bYDtvcJyF0L37f9dI+wuCgAA3aG5 /dErsobZar79yAEAALaONe2PXpRy+38DAACcWJr9Hr2Wee+YcwAAgHzq9aNLxH7nYu3+Gb//d1ZI pBfcuQ+6r1wAAIBtpQk/etEtuuP3Ry9heouWCwAAsI10/3t0AACAkwDrugMAAHSCbVzXHQAAAEzY Hx0AAKAD4EcHAADoAvjRAQAAOkHt36NDE7BOLawT+3pr585JdelZXU54cQtjMYyK0qoTqG+gHZz/ Nn0x8OgrRmvXdYcElsyDdeJbt7HEzkmFzFLRB3ddetYiJ5vAaSyN1bFyVSrRFNldrwJmOLe+dumB d5TmsOUbl5PxkuS82GwhnX85aOm67pDivEUBGqKu6y1sJKpTl561yNmgnXBacWNPy2w81+RH0uhz yXnBGK8sRsT5zmS3QxPatoqa90f3kX2LTI44F2HNHZtqVE6pmrULX72yDWKnyf4Vs599mndtjdbV enUV44ns7D7aB9s5sG8TuEh8HfRCkuV4K4XTV1lPMyzQ1qpcETHPaqf82h/Obb6oaqNeP7pvlCO7 Nnv2L+eRTckJpN+W0RtfvZzvQPYjNT3iG3U05DfR9zpR9TppBF6taHNxvYBuHOf9UlSCffdlbz2n /EDcWUrg5u1Yty2Hev3o4SYLd5oNk7wROb7023UplNM29+WmovzqdLVe7cc5pFldZr0C14ZPc58t yfa811nropasUfUClth5PPwoLnQ1Ot8Mukor/OjO/tMG5YBs8wM3TFfr1TRGX2qDmrQT52Onege3 CoWKa1o950uhPWZWpQguS+F79BNIV6/7rtarbcQ8+o3Hty9L0X5bS0gcNMaR3GHhJsq127m0ZKf+ 5QTaekbmKlFWmvcwQ8uvn2ZZz/foxuhTdjaH4csMPyyaltNCskN2EjFTRjz1MtzM9khgttHsuyI7 2JWOhUjc8706Xa1XC3Feb4bPO0aOMcXBPiie8xhZhFPPgPy1yQn8G3NRZS/1mHKd7RYQ4nueOPUP tEP8c8m+ucTVzoeZuSzOcrNyjLtejt/vYt3Ltv6dZT3foweaMt7tvR45baOQquHE2Qdr7l9OUYUa uUa6Wq8Wkts+zYmq5VIvqmoJOeHR9YpalWifQvrUdVLis4RvLt+/uZXy3dEn/F5mXXcAAIAugB8d AACgE7A/OgAAbAuGdzz3uO9gN2F/dAAAgA6AHx0AAKAL4EcHAADoBOyPvhWc2M+jYc34Pt5t50e9 9n1R4tP5WuSE2yf++/IYaU1Q9Lw713WQCu0WnwVC+L5H72VWVA2HG1P9ZHCC5nTApjHWDsuN50pL IpFP9kIPE98EKGMVlMgVXSrKCbePsbhKLoWaItey2g9q54o0Jc67rWSJ9nfKgdJ413XHnLeE7EJI AI1S17ItUvYlIJ667ota5GzwSZjq7zOlRtWaPi+wWbz7o9fbRzdW7LPjRrKNyImpSMvx1SvbIHYa cT0XnKNnRt41Dwl2r16tpeKz3siefVY4+472d0dtPgWBi8TXQS8kWY63UnlFLQmB81KCupTcoIsh i+8dKPtY2ILng8+PXs6c2y2VpDlkf/S14KuX8x3IfqT6Tm7605C/tnf8rtZru6j+OAu8WtHm4ulw l5NT6PXI17cJ9HkCLwo2gednITmROA22UbpvrMIZ36bnQ71+9HA9w51m40raiBxf+vaePxfltM19 uakovzpdrVfb8D2w6n2cbW9r+zT39RCyPe+11bqoxY03b+FCw93fenG+YvrGTqoXtxVXbCv86HUJ rF2xk0xX27Cr9aoLbp9yONutiQ5oyzGqvLay6irU91KyLXi/R4/so29KbyhNV89aV+u1Tnyj4kXb 1ng4+IyZT2zLT2UyAGsccbZb0+UWTRl5XmLkx6TJFR6WE19fg0OL+LyJ2kVztYh6/eg+jNGnrBPF 8FXE+GOak9NCskN2kqdqoF7pzZz6hNIs9miq/bqWpklTZuOVa5lDV+vVQnItQWSzOLMY7e88j5FF OO+LgPy1yQn8G2/kYm52o1wji689c89LzEnxtU/RRivRzrXgu9/tt1jnu1qrnwzr+R49kMy4UDYu p20UUjWcOHsD5/7lFFWokWukq/VqG5H3VxVpdRXhS1xUzxJyApdZ0VIqlhs+WKhqRduh6Mn1Ue8l V6LQmHjT+tSId133Gs05AAAANA1+dAAAAC+G16/VrMePDgAAsI1sk6Xz7Y9OHx0AANqGb5ZAYPbA NpnkauBHBwAA6AL40QEAADoBfvStgNaGdWJfbxv5bjiXuvSsLif8sXL89+Ux0ppgOz62juCkPyrZ H73lMBAC68R5vRl3euSNX3TFmEIPk7r0rEWOsQ6J/XJQaEQzvimyLWy3trP9DTUOrVWYSjRa6YvB bpNUn9LyTzitWNcdAjgvcYCGqOt6K2okilKXnrXI2dST0HgO+95C7DQVz4hRbow05zuNLaecfIxR Cvujd2SsKcFXr2yD2GnE86pu/GvnXfOQYPfq1VWMJ0P2WeF8aves733bfAoCF4mvg15IshxvpciM gUGFbemAFe2L+xwlzps9vojthv3RY/TflivDVy/nO5D9SPWd3PSnIX9tj4mu1uukEXi1os2lpg50 uXKd7xA1PvcCN5fv9cV53Pfi4oz7xgC6DPujx0jermdNOW1zX24qyq9OV+vVfoyRj7pk1itwbfg0 99mqbM+7iVpXPzU+0xjWtuhAgg9n0b7jvsqGjUItem4FrfCj1yWwdsVOMl1tw67Wq2nCXTdwPnZ8 Hcp62WDPXopcDPW+ecQLNN4Guv0E4Hv0E0dXz1pX69U2YiyH8XDwZfGdspafysRBYxxZw9CuXW4W pwfKVq92bEPga5+UWpqohJBu2/IV7I8u7T7T2SE7iRsH8/mfsk5leyTQGG0zbpjs+3j2fW49PYOu 1quFOK+3bKNFNothYOyD4jmPkUU49QzIX5ucwL8xF1X2Uo9PbA9Q+9ozt77xlY185BqJnfeaUXT4 OZ+Np+8KzvNlyIms3XbD/ugtp5Cq4cTZGyP3L6eoQo1cI12tVwvJbZ/mRNVyqRdVtYScwGVWtJR6 yw3/DMuv2PiBOyjws2Lj54o6gfcy67oDAAB0AfzoAAAAncDuo7OuOwAAbBbbC15v+qKJtwP2RwcA AOgA+NEBAAC6AH50AACATsD+6FsBrQ3rIfxdcuR30mvDvi/KfXxcXU697Vbo6/BGaY8mEAX7o7cc BkJgbTjXKjH+LTpTSaItYqGHiVMNQ0j8ii4V5dTebpFNYSy3YsezOI9XqRe0EPzobefw8JB2hvVQ 45WWLubVkHuurvuiFjmbukMPj5ZsM0LJ1CtbwewRniqdhP3ROzWm5KtXtkHsNNm/jDbM/mvnXVuj dbVercXX0SyXPfusMO7c7MFyA+brJ3CRVG83I9JQOzTUH4sfGwgfLyq/rvRdgP3RY/QvOlq1KXz1 cr4D2Y9U38lNfxry1zZO09V6nTQCr1a0ubheQKvI8R3xdYHs9EX7PMZ5NO6v+ONF5Rukd70zvdPM dwf2R4+RvF3PmnLa5r7cVJRfna7Wq2343nSzPcjqbbW9re3TfD3tVh3bqsXUaIPKFxo5y03mfLnp DOyPDm662oZdrVddOG8f58AGZNmudmuPJjEU0jZ3UKF7VjwL36OfOLp61rpar3XiGxUvivFwCI+O xh9vCYmDxjhSS7sVLXeztE2flGS8PfxvOM0Ww/7o0u431uyQneSpGqhX+pA9PPIZp1kOLe+db1wu lZ8mWE/Po6v1aiHhZ3R842Sb2tf+zvMocfej874IyF+bnMC/Me2WvdRjyvW1m7NedQnPVd64j4rG i8qvK30XYH/0llNI1XDi7IM19y+nqEKNXCNdrVfbqPfGyW3q2oUXFVJOTuAyK1pKxXIDx4s2fi36 +O6jovGYEptI3wH4Hh0AAKAL4EcHAADoBOyPDgAA0AXYHx0AANpGOkuxofRFE28F+NEBAAC6AH50 AACATsD+6C1hKz6OBwCA9lLj9+jOtTuy+IxWdoWQ9C87ca58G3sU4TCz0kJaqLOgmLeWGDmGqr4V TrK5cqtWoikAAKDb1Lmuu22csviMVhq3rVSu8csl8JZgxAP6OJ0L6SyMbF7DcjvrW6IWMfXCqAMA nHDWtz+6sXyPLaFpmxTZ97X1iRwM8JlzievuAwAAVKK1fvRsX7liQb4ZfO0xtM5Be/F7DQAAAEwa Xdd9bVY/jHNUv1ApPpmBBEWLCAzR5yqGmQcAgFbsj+6j3q/jSmubm7GusYSiVHxTAQCALrGm79GN xKnxs49nE6TUZbScg9jZgz59YrBn22XlNGfsa2wfAADYYmr0o+dODneOEtvHe8c3sk1/2gXlYuc1 jtuG1qdnWL49Zp7rGu959mOOnIhnl8XYOwDAiaZGP3rk6HTu8fDPQsSU6DTq5eTHaB7ZCIXKLZod AAC6B+u6AwAAdAHWdQcAAOgErf0ePZ7A5+Zr1gQAAGBjNPo9+npogw7bCG9CAABdAj86AABAF8CP vkloQAAAqA27j751fvSU3hHGkQ2qtClOZq0BAE40dh+9kB99Y3pbZJeZK7Ray6YwXolqbEzfujoA ANBhOuJHb5UymyV9s9m0IgAAsFZq3h89XdnUubCrEc92ItO/ssupGv/aeW275euY2umdpRfVxyc8 F2cH3SgioE9uOxTVBwAAtp56v0dPjtt/GTY+a5BsE2ULT38a8n3JDLtup3dmLKFPAOMlJpze2Z4B fQLtEDbzAADQWZr4Hr2cLXF2fGNSFpW8Bn1sS+z8t4o+ziPZ43giAABOFO3dH72czWtuOlghfbI9 5mbU8YIhBwA4mdTsR4+h0TnYGzFmhUa5I0fsq1SEUXcAgJNIvX50Y4ZXNoHhPk/ThJ3B2exZ+WkC 2wUu1qC3L31AeKQ+NWJMNQjrk1bTVsY5kwAAALpPvX703PlfvmT2X7keeuc8soCQXFWdiWPGz+Ot e7jzHdAwpkYAAHCSaa8fvQRt08dmbRq2vykAAKBeWNd9KzG8GwAAAF3YH/0EQssDAIBJB/ZHh3Jw 7gAAukRoXffIEAAAADZO1o++6nB/89U3RbQStbL1opUo6YteiiIkJCQkJCRsRyhLyVpqLfLIA/eK yKUvPLOy6C+99qb0RZayCjNoEUWcOHHixIkTb0H8yLprESVLLX2VWPQn/+DpdNRdtF5FBv2BZFAy IE6cOHHixIm3Ia76Sbgy52L70eday1LPtdZLmemZLEUvtV5qWYpern4SJ06cOHHixDcbX/3UWkRp veqMi4hO/ejPf/tqYuH1UlRf6cSPLpJ09I9+EidOnDhx4sQ3Gz9mmvVSP/bJiyJy6QvP/Ic/+qM/ EpHv/WDS/3/9g6Xu39Y/+PeDvvQP/v1AL7XIrZ/EiRMnTpw48c3Gs6Z5+e9LuU3+40fGIvLit19Z fY/+5K/fLwAAALCdqL70nvj9P/XNkk9StGGyPiEhISEhIaEOmub/D38+iinhTUKQAAAAAElFTkSu QmCC ------=_20041011113302_59241 Content-Type: image/png; name="ssh_session.CP1251.png" Content-Disposition: attachment; filename="ssh_session.CP1251.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAApsAAAFpCAIAAABcQnS8AAAgAElEQVR4nO2dX6hkx3ngv/b2mNPD yHQPozBtpKBrbNAozpIZCMQigUjED5bww0psHuT4wVK8YE9MSLTxvjiQP1ryEAmzu5EhyY794EgL Tqw8mLEfFEYGBSmQZWZhNxpDhFqshO9giduNc5kuombvPpy+Z+rWv1PnX/c5p3+/h6L6dNVXX9X5 81XVd07V4L9f+RslkogEwstPPi4iV39w9dHPPCoig8Hg6OgoHGbJBHYD/XRv8tT7ynLq44sEFN5W vbbFtZevPfzph6Xu29yZLCB2K3JaS7y2fb0d+lqv2vmQWqlERK2UiPjiKaPhSOLu88FgsK36ABhw NRZiuVoKt3l/6etZ62u9ijJMhokSCYcp6a0ec5+HOzjzf5H99+eyUovDTHY6F6BHiLc+PpRxMp6c kem5iZwSvYcrm+rnZmWlP/USM5OTRrI0zsGlbZ+yNKKZN+l4/z2GtONe/TbX8Z0mXU7kwLpROS1E v24lT9W+3g59rVcTDP7sz/9KhomsVDJM1Epl8aeefLz2wpZLmb27f2uhkqGoleihiNgHCbsRily4 5/z07lHtFwwAAMTjGKNf/g+fa6Kk/f357NbCZxVEtm2WCCuEN9++NV8ke/dMR5h1AIAtMfizP/+r bHR+WRuXV58bVyuVJMnF+6ejUzJ7Zz67tRBZimSPfGc8NwHx9saT4eji/Xujkey/N5+9vVDavIuI bN9N0Od4S9QgTpx4I/EkSWQo0/F4PB6NTomPD2Wj88ycL5fyxj/v3/jRbLFY3FooEVErERG1UllE P+iLJ0O5cM94dErm8+Xs1kJEkjtPf3c8NwHxNsfVSm6+vS8i07snMlxPyKdGXaIvG+JF4y1Rgzhx 4k3E08jiUKlDdfPtWzf+z2x/fy7HzN65E5f0XXcRybzm+/vzGz+aOV3dybDYTKyITCYjEbn59q3l aikrma+WshJnPDcB8U7E9xfz/feWIrJ3/vz8cCmrAhcMYblw6woQEhI2F9oHZ7cW12/uywciInv3 Tl7737PMog/S79HTAfrJufGliBxHRufPJdPxeJKM0v/2F8v5YTqCzxKb4d756d69k/l8+dqPZiMZ LWUZCEUknMAIv/FHvydDue/e+x6454Fn//LZZ/7rlXFyXs6InuaVv/3mC//jhT/7i6tyRibDiSHh 0U89ICLXXp+lRx7+1J6IXH39DWeJ6b8Zaa5Ugn3cyJXJ1NMb5TolGBp2JUwSefDi3nIp1/7hjVEi yXCk/BcJYR2hbFsBQsJuhxfum47PTEZDWa4kHC4O5zffTq3knfvuwn3j4tkrlj5KhvLgJ/fklIjI le+99tRnH5TUj56+CjefL2+8eUssxmeSyZnx+IxMzoyWaqmOZ/lElFIyP9Qd7Se4cN/56d2j6/+8 v//+XFYiQwmFkpfACl/61nMXPn5hcm5y4RMXvvZHX/vcF58e3z1NnQ2ykhsvv3Tl21f+4x8+mwwT /XgWpvby0V9/6su/87Ss5NFfOf75lad9KdN6Xf3OldRO+47ruTKZmXwjpX48RddH17Bo+2wxfPgX HhiN1hUcDUWGI+cVAgDQBi7cd356ZrQUGY1k+YHIStRqKTKS1VKOJ8Al/RZM1M23Fy3JniTy4M/v icjsnfn3X71x+YmHP5QMk/S/bG48C5erZTJMJkmSJJIkIzklo7tGyXCU3HnRSZIkSYaJkTENp+OR iKiFWhvslYiMvPHcBFb80q8+tlCLvXv3knFy9aWr1//++4v39tWhUkrdePWlK9++cvn3nlkqkVOT de1Pyrn66kxS42qa1RNl6Wb7y195+stfefrqq288+utPfePrz2XNmh5P4+lxa/g+SnOJyJe/8rUs pV7ul7/ytbUczZxrmhduny3G1eFSRCZnJkopkZHz8iCsK9y6AoSEXQ/nh2r/cKmULJcyOiWjoUyS 0SSRyZlRkozGyUhE0k+754eyVMvlyfuuRPaKpacZ1aHsvzcXkb1712buQ6kHfT5fzpU5fTqSUepl T4aiVkv5QOQDGa07AJK+yi6i1Eq5J9JPiYjM1Z1ehlp547kJ7Pj5uyfT+z41e2d24Z4Lo8no2T98 9rUfvjTb35/duPbSt1+6/HvPKJHJmUmSJEmSOOVcffUNETlpVp+2y0p58ktPZ8ef/NIdE37cGmZc H3anctJcusyUq9+5cvU7Vx79lT1djp49vk1aEl+o9WUjK7Vcbd8R0O9w6woQEnY9vPX+fvoQU2q5 /EBS45WGo6GodI59pUSSW+8vFovF6OR9VyJ7xdKz7LN310P2h37xwrN/cfVD6Y/Z+wsRWa6Weph2 BFJzuH6r+ZSIyCQZJUORlSilJmfGspL54dLOrlujEs7/3FCG4/PTqRqev/YP15bz5c13by7eW4wO 3/7mX37zsS9dViuZjsfJXePxOAnI0fnyV552lHJMIK+d8ruvvKFL1nM9/pA5zf7orz+V/nz0Vx5I 06RdjUIN2Kpwf6FEZHpunLaSfWEQ1hhuXQFCwq6H84XIam3UZCWSmtVj45rISCmVfkg2X8zVSi1P 3nfO7IPBYPDhgS+7r/TTHx4MBgO99LMfOf3Rnzntyz4/XC6XIiIP3DedvXtzbdFPzo2vw7dvLcbj RImS1bqbsPxARGQpkhx7RtVKJYncWizs7OsESsWEkclOhEMRkfHd05v76tatW89//flHPvPI8nC5 PFwuFvMkSZLRKEmSsBydcBrf8avfufL4Qw/oA/303ye/eNnOm5rzlCe/9PR3X76eZkknAETkG//t uTRldqRQM7YkHCciIrNbt7Iz67g8COsKt64AIWHHw9n+LRGZHy7U2octqZlMw9T8zQ8XIsls/9jY aRLs7HfWo/3wwJ3dU/o612CQlp72CcLZF4dLEZFTIkrWFn3/cCkixmdw+/P55EySSPLRj54++5HT gw8PTn94MPjw4PTpwemPDD72s2c/9rNnE0nGZ5L5e0opdZz9jhCR9ex/fhiZzAiTJBnK4w9deuZP n9m7f2/+/nz27uzSL1x6/k9+X5RSEiFBx5km8K+IHI+ws3H2k1+8HMp7nEVE0iNPfvHyk196+oQm tm4lWmar4ShJ1lfbB47rini98ZaoQZx4d+OLw6VaKZFkuRJZjZYrGYksVyJpuBotVyKSqJVaHNtK XY6RPTPDKWc/ctrOruugZz84ON4g48OD06fXcv7prQNX9rWQ6z9af72mVmpt0RMRtVKJpBPs6/j+ +4tkKGql3nrrQFy89daBWqnRmWS22F8cLpJ0nbhjIesymhuji6hD9fAn957/+vN79z+4UMns3Zla KCXqsV977Pf/02/O39tXSqlDr4THP31JtPfP9eOPP/TA45++FDNGF5Env3j5iS9cTkNnmjSuz7f7 Uurp7SNdCZep/uvFfc3rini98ZaoQZx4d+P7i0X6sJJ0kJ0usCHr+HGoRGR/sVAfLI37Ts9+9qxj F7if+9hZI/sJU3uy9Ns/PbFJzI9/ctsu3ahImjIZHo/R0w6CZvkTtVJqJUpJMkyWon78k9uGigcH t5ciyTCZL5Q6lOMidSEicuyGH+rObEc8N4EjruSRX9p77k+fG99/UYmcPz+d3v9gMk5EZLFaPPJr j/z+b//G/nv7slJpLQw5n/vMHXP+3Zevi8jnPnMpTfPCD66nY+4Xv/X8Cz+4LiJXv3Mly/v4py+l Ke+YW4+eGclQ9N7DE1+4nOnw+KcvpfGT0iRGfmvjozOJiCglSiSxrivi9cZbogZx4t2Np2OQZCgi 6Tbiy0RGWigiKv0uTCkRGSnjvtOyiwcj+4lb2Cr9REZX6UZF0pRqdWzRJZ2gXidax5Nhcv3t/fTI /FAdaEb94KdHapW+hqdmt+bqcF8tl4aQ+Xx5rOV66LbQhnFGPDeBHf/cr1567uvPJfddECXj8Xg0 Hk+n071PPnzfvfeNh+P1SP23f2O2P1Mu+RlPfOHy4vjIi996Po0/8fnLT3zh8mOff0pEXvjedRFJ Dfnjn16Ps1/81vO6EJ+eKVk8fa09k3Ple6+JyOOffkDvXhh5w/LbGU9P+v5ifvLic1xjxKvHW6IG ceLdje8vFslQlIisNxAfpV+Er8P1cZUMZX+xkNVSTt53evYf/+T2wcHRwcHtg58eHRzcPjg4+vFP bv/TWwdGdl0Ho/SzZ0/rD/+zP3PaUbpZERGRZHg8kFSrdNlXJcM78b1zk2v/ePPB+/dElKxksVIH B0dnzw5u3z5Sq2UyTKdVk2s3biayzqILWRyqyWS0d35640czOR7AyUrccclLcDL+uV+79MwfP5Oc uyArSc6NR3dNxkkiK5ncnahPPixybfHOIh2p/+enf/OP/8vfTO+dGnJe+MH11Cqnx1/43vUXv/18 2ih2uVe+d/2lb58w4U98/nImwaenLjOLnxDyhcvG8Se+cDmTkyu/nXFJ13UXmd28OTk3luHYuK6I 1xwXaYUaxIl3Nq6UqJVMkmS5ko/+zGlx8db/PUjnrWU9MtbuuxLZNR2c2Q8ObstwdPYjAxH5uY+d NbIbFcns+J2p4fU07+pOfO/e8Y03Zy/9/Y3HfvmCEpGVKDU/OLidzkUsZCnDZP/9xSv/c/bIxxMl o+SkkDfe3d+7dzI9n9z4UVr/RK2n/h3xtIcRSGDEr/zda+rcnogaj8+P7hol6y5MIiKT8VQ++fDk nsVczUVGlz/1sKxnSEw5T3z+shK1biBJHvv8U4FyH/v8U4kk64nk41yPff5yFnfm1WWmcRGVyXEc PyknV34L4xfumYrI7J25Uiodo6+NvesaI15DvCVqECfe2fhiMZehSLrGpY+hJCKLxXy5um8sJ+SU ya7pYGc/OLidrhl3+6dHpz8ysLM7nwPJST+6GaqVunj/+Svfe+2lv7+ZDBMZiqw9pqNU+ks/vPGb f/LCWBbJmUkySozsi4Waz5eTu0Z790wSbZbAGc9NYMf39vb2PnFxcvdknIwlM5DDJBnJ9N69vQsX HvzFhy9dvHjh5z81mU5LyCdeLn7x43sicv3N/fGZsYic9KMT1h9uXQFCwq6Hy6VIOtE4lB//5PaP f3L74OD2eub8p0e3bx8dHNxOR4zr79lO3nclsodLFxGRpQxHSiQ3uxyjMj/68Vtz2UhL0nf5pndP HvmFvSt/e+23vv7i91+5efPtW7KSG2/uv/R313/r6y8+/80Xxmp28Z5keu68DBNLiLr59i0RefCT ezK8o8dC0yOLOw8S71z8wseno7tkNtt//dVX1FCSU3cuBuc1Rrx6vCVqECfe3fhCLTIfVhaqlSi1 lNVSrZZJMkqGkpyZLNTCvu9KZNd1KJX9hJC1HR8mg6OjIxG58revHX9PnHptj53tQxEl8/n8lf91 Y/bOYv9Q1EqSoYyH8+mZZO/u0fjc+ek9e5O7J0kylpWyhTzySxen09HyX+TFH16XlUg6hyySSGLE nQeJdyh+4b7Jgxf3ROTKX782m92cnt9L7kqSYaKM64p4vXGRVqhBnHhn4y+8fON1bU/SAHtjeeKz D6WvCmVyXvjB64WzazqUKf1kRZ767CUReep3nzm26N+7rtnj41BkHVFqvlSLW7P5oVKLfSWSiCTj 6eRMMj6/NxklkiR2drVSiYgM5bFfvjiZjJb/Ii/9w/X0e3HDnSzrN/7Ng8S7Ek+GycVP7l36xFRE vvvy9ddff/38+fOjM5Mk3QZg6Lg8CGsLs/uUkJCwXCgyf29/9ubNxfu3wonH587vffzC5O6pcd8V zl6x9JPHn/p3D4rI5a8eW/Tn//q14++J74QiJ39+oJZqKSuVHpFhMkpGciqxMx6Ha1OdDJNHfunC 5O6RiLwxm998c//We7fkVCIfqORUoj5QcipJRNKIfpB4++PJUPbumX7q/r3RXSIi3335jWuvfn96 bi8ZJ5PR5Njb0vhK8rscGvcpISFh0TBlPp/LSskqG3y7wmEymaw3OjMkFMpesXSjCqlF18bof/1a NlgOhJKX4GSoDeY+UA/94oUH7pumS88vlzJ7d1+Gcut9lVWpDeeVMDKUoYzPjEeJ7E3XF/cbs/1X Xr35xpvXp+emyZnxKBmJSHIqOb4M4i8bwmJhwbuSkJCwS2HMDX7536dj9GePx+gvXkvHXsdbvnji IjkJrLg+sBvfNb54/3R6fjy5axTjM4BOMHtnfv3N2bWXr43OjMbj80mSpOb85AVQ7LIhXiAuhe9K 4sSJdyYecYOnFv3OGP35F6+JyLG9F388N8Gd+FIks9tpPF3+fq7m07un58+NRWQ6HqXplcjaI0vY hXBxOJ8rtVio2T/fnB/OJ2cmMkzGZ5LUF7NcyWioXwAFLhvixePSDjWIEyfeRDw/8eUnHhaRy199 Zv1B+/77+8fvLa8f2Z645CXQ4uuXnNfee5WFksxms9lMlFKJSPqyvojfc0DY5lBkkkzSi2txqJKh qMPFidOdXgDxlw3xwvEidyVx4sQ7Fo+5wUVE1ErWFj0ZJl/78uMSzWCwHtwDAADAtnjmG9/N4ifW jAMAAIAucWy+k2wV2HSFOQAAAOgSwzuz7se7qTJGBwAA6BrKHqMLY/RNMRgMdlwBAACoi8Qeo3fX jz44xjiyRZW2RWStj46OdrN9AAB6SG/86Okr9ymZlWrzS/jGNwI1WtZUFKYaAGC36IcfnS/oMrKe zbYVAQCAjaL70dffo1fxo6fjQnuUnB13ptH/ykyR/a+d17ZbvoGpnd5ZelF9fMJzcQ7QjSIC+uS2 Q7w+qRB6AAAAXUf3ow+PY+XH6Kl5sC2EYeN1g2SbKNvGZD8N+b5khl230zszltAngNGJCad3mtWA PoF2CJt5AADoLfYYvbofvZwtcQ58a5G/eX1sS+z8t4o+ziP68fhSGKYDAPQBe4zeEj96OZvX3Otg hfTRR8zNqOMF2wwAsJvU7EePodF3sLdizArNckfO2FepSIlZd4bpAABdp2Y/uvGGl24hDPd5libs DNaz6/KzBLYLXKxJb1/6gPBIfWrE9zqhz/cv/naWhrtNAADQRur1o+e+/+VLZv+V+/52+OW7mPQx wmPmz+Ote3gcHNAwpkYVYYAOANBtWutHL0H7bdLGNGx/UwAAQL2wrnsnYVU4AAAwqNmPDpuBITgA AJj0Zl13AACAnaYf67oDAADsOPjRdwI87gAAvadj+6OX2++8XK4q8psuMRf763mMOgBAz+mWH72W FdprJ37F9RJgiQEAIIp6/ehbH5sCAADsJjWv6x7YcMyHb3XV8Kqr1TcM9e13buz66tSn0CJxPvmB 43KyJcsVbcDK7QAA/aaR79Hjd/O09x0PHzf+LW2iAhurx3QpIsuN3JfdeTwrtK6tVwEAoOc0sT96 ir41S26a7Gf4uPNnQ/i2RSktIZyyloF4TCkYewCAftLcuu6RxsM39i0xJm6O8JxBLbSqvgAA0Dka +R49fT8ucl660PEN41SjCd0iZVYvms/YAAD6SiP7oxcaX8a8KWb4tu39zmOE687porP9xlatWZfF J7/QvuzhdnDuEgsAAGCyyf3R49PHHC86pd9E0SX0zN33vei/RaFbAADQT1jXHQAAoAewrjsAAEAf 6Ni67gAAAOCmW+u6AwAAgBv86AAAAD0APzpAb2HtAYCdoud+dPaCa4LAukAb3oe+/ZKrwIJCAFCM 5tZ1bwN1PdEiN4gTz4IwxsI7vgQxyoe/Jvelt1e/caoXv3CvM2XT9qM5+e20fKzDDwDFqHdd9+qb nLYTe2fVNO7ccTVsHpxyxNqwzmllc62OL7295p2tg77xnVNy4Cc0BO0MAPFsf3/0ouSuouoc2dgq 1b7XmVFopkZgzdpCg7Ciw7WY9M6tceo9cUXPV9HzUjp9levE7ro51/fNrZchJ/5KiE/MQB9gd9jy /uhFMWTq48vAQNZO5pNTWqvSeVOcM9il5fvSb/7hXuJ8FTovRc9j0evEp8+Rtra/rnlgiiVGDqYX ACqx3f3RSxAz85x7pGLRzino5hyxReVX1Cdm1r1GnKPkeEpXM/I6CcgPt0l8vYq2bYn09BUAdoKt 749elC0+mMKW0vemWF0KN/3cr56xOvaYOzdLo9qW0KdROQAAAba8P3pDbOuN69xX0428JVzj8Yl9 +hgOXUOfQvLrwlnuBpQpVERd+lSXk95fhbKE39YEgH6w/f3RC2E/mHR/pHEw08d+N82X3ofxXpv9 vlsgsZHAeJ3KyCUn29ApP0bPsP46Pn0K4ewWBNo55rjuY46Un1uFKteJrY/RbkYjG854pxy7RgHl 46sJADvKdvdHr7EI53HjxaUYOZHC7dedchPHq1pOyUD6QDuUKCW+3EiVfMedr6fFFx2fPvI6CesT TlnXpVjjewMA0DdY1x2gW2CbAcAJ67oDbI2iXhXBnAOAn0a+R4dGiX/ZHloOpwwA6qTf67r3EswA AAA4wI8OAADQA/Cjb4KmPwXu/afGva8gAEB1er4/+m6yXfvXROkskAIAkE/v/egl1mWr11Hd9PJ5 kfLDy9pkOFe6LSQfAAC2A/uj9wnnwnMpzmGusfK8sa6Zfjx8TtkIBABg63R4f3SfNdKLtr/3zbVM dno7u77Sp57GFm6bOqf+xkEjHlio1ZBvrz9aiKJj8UDV7MR2lkLXiXG6AQDAoMP7owdmhu0F2CPl O9Pbpjc7YqzRXWgsa/cbbJ3tNcBzyRYe99n+cCcj97iznX3xQK8LAABqpnP7o+vy9Z8bsxbx66KH LXGhfka8/MCC87nynSN+CXakcpUUf4+hxJLsDNMBALx0bn/0mLK6OBbMzFVz7Va9Wcq1s9EbwCQD ADRBt/dHd1qUgJkpatKqmMCYFmhavpE4o5YeTwkh9rRKUSF8xgYA4KPb+6NnBdkvlBmuXCN9ZBG6 77yEHzpef/1fexBcSH8bW//sp0++77ivnX31yn0zkfE6AEBt9HJ/9Or+2lzJgeIkOIAu5+GOl58r JKx5+HgguzNLjHO9KHQCAADcsK57E5QeTEdm7IdV60ctAABaAuu6V8KeVW6DqE6AOQcAqBf2R69E jWYJCwcAAJWwx+g9W9cdAABgJ8CPDgAA0AO67Udv2uu8O17tlF2rLwBAn+jD/uglFippZ0EbqwgA APSQ7vrR9TVkYhKXlp/R9MtrheTXbvtZMh0AoNvU60dv7SgTWwUAAP2me/ujpzgHlM7VUgMHA7vD xQ9YjR7MZroOztVV7cVWjZVfC9XXWO1Vl2MUp4utuGAtAACUpmP7owdw7s8tJzsZuob62u+lVS26 F5mdoFy5zi3abNObHSlaX6MxnUXYcebtAQC2SRf3R3dajhKlVF81PbzzSnyJTRDfROH6ll5AHgAA Nko/9kffIsYYvfdVPmp+H3cAAChB9/ZH90mu6428Qpq35DXAKmrE1Lcl1QQAgAAd2x89XKhvn28j ru8LbsTDRdhyxHIzV6mCU74Pu75GRcIvu4X1CXsT7AG68aYeY3cAgC3Qrf3Rwx70eM+xb2Nvn12v ZbPzAKXfj/P9dLZJoVf6C6mECQcA2D7dWte9VWu89ICm93EHAICN0e113SES9nEHAOg97I++E7CP OwBA/+nuuu4AAABwh2750QEAAMBJT/zouHUBAGDHacv+6BVNsvH9NAAAwM6BHx0AAKAP7Mj+6AAA AP2mZj+6vnFndeUKyWHiHQAAdplG/OiZXS+UpWKhAAAAO01zfvTqg/W0Z1C0xNLFAQAAdBj2RwcA AOgBrd4fvcQQn2E6AADsJm3fH51RPgAAQBSt3R+99FCbTgAAAOwibV7XHdsMAAAQSXvXdcecAwAA xNOWdd0BAACgEqzrDgAA0Afa7EcHAACASNrrRwcAAIB4OuZHZ2+3KviarulWbU5+O6+HFqoEADtB vd+jN00tS8IZEuyX6rMExl/Z+jn6inh24lz5uSpluXThvoIMfQL4Uja90F5z8tu5RGD8GQEAqJN6 13Wvfc24JsiMpVNPw1rbcdtgO014oWd6oJdgxAP6OG2boUPLT01voJ0BYPMoe4xecX90KWjXdTuk Z/FZMv1fZ/r4op3K6HmzovXjTT+sY7oCTn3qVazoeSna/qXTV7ke9FkNXZqRMrdehhzsNwC0gZrX dU+JH6QaafRxp28S25nMJ2cD+HQoJ8p5fPOzuCXOS6H2L3q+il4PPn2yHX6d/TY5aaqzLLlymGMH gFbQnB89cgST6wd1+n0r6mbr0OgTOd7PLRXeq4qZda8R5yg5nhrX7fd5T+IlBP4tLQcAYNNsfX/0 HjwW6305q3SDbLEl7TF3bpZNdqGqdJJqkQMAsAFavT+6LrAuUWEMr6oxy2rrkybIqEtP56vvhkPX qc+GcZa7AWUKFdHcSQEAaBVb3h/d96K4832lTH72tppoNjX+Tavcl8P116YCx3UF9J92QbnYeY3j zqlmp56FcGobaM+Y47qPOVJ+bhWqXA+2PrnnMbdedo0CygMAbIit74/uy+I8bpjYckXnpoxUqbQC 5Ups4n2CgIRC50U8qpaQXyh95PUQ1iecspZLDgBgE7CuOwAAQA9gXXeAwvi8JAAAW6SR79HBSeBz 8w1rAhXhlAFAG+nWuu6dBjMAAAANgh8dAACgB+BHBwAA6AMd2x8dAAAA3NhjdPzoAAAA3QM/OgAA QA/Ajw4AANAH8KMDAAD0AvzoAAAAfQA/OgAAQA/Ajw4AANAH8KMDAAD0AvzoAAAAfQA/OgAAQA/A jw4AANAH8KMDAAD0AvzoAAAAfQA/OgAAQA/Ajw4AANAHWuFHHwwGg8Fgw4Vuhr7Wa1tUbM+uX2ld 1x8AmqVGP/rgGONIbsajo6NyJTZBo0/MwUmaK6giJfRsc3UyWnWllaCE/kXPSzh9J84ywO5Sox89 fdzoD52uP0BrJ2uilNY+H7uiJ2wY7miANqP70YfrY3X40QeDgXHz61Yh5rmQpU8tSpbFluM8Ekif W6gzS1H9ixIoVK+mYV8j62vkraJ/QL7v1PQV++YAABczSURBVOg6x5xH588YfXITG7n0xM1dV766 +0qRYLuFZTqrEH89x6SPua9rvN4AIB7djz48jtXvRzcMvG3vA+mNaXxbjm7y9UeJ0RWIKdfOUk5/ XWBMMp9845lu1E6i65v+pecq95ANy7dlGuWG5RhCnDJz5RSqha9B6r2u7PTZqYw8Xz6xue3gOy++ 7LnpjRZu+noDgGLYY/Tq36P7nnrlpBV9FgTGEC0hcvQZSXx9ixbn1LNEe8aXaxjR3IzOGYsa9Qnk KnddFbJtvpTOjk7RdtjAfYEVB9g09hi9oe/Rt3V7t/Cx4hzu1Cu8OVFta89ycyf1lhuJs6dbrujw 7EWhOTBpZa8XAErQje/Rt/XEabRcY1y1XWXqpYqqMRPOtRTUaYyLJ97dEHmwkNiipOe3CckAO07N fnR99GDHjZRi+cizv3yziM7jhkvS9sXa5eZWIabcEhiqZk0UkJ/9lZm6TFR8ffVynR5cn54+ZWxV ne2my/EllgrtKScvoVw5vnZo+rqKvC9y2812Yxva2srkXs9GFypwHo144Loter0BQD3U7kc3nibO ePhg+C/7uLMUOxJPc7PNAeVjmiIme67yMRUpcV7C6tVVROmUdvrArHUgcenrqpb7opCQ+CIKNUVF 4WFpAFAJ1nUHAADoAd3wowMAAECYVqzrDgAAAFVhf3QAAIA+gB8dAACgB+BHBwAA6AP40QEAAHoB fnQAAIA+gB8dAACgB+BHBwAA6AP40QEAAHoBfnQAAIA+gB8dAACgB+BHBwAA6AP40QEAAHoBfnQA AIA+gB8dAACgB+BHBwAA6AP40QEAAHoBfnQAAIA+gB8dAACgB+BHBwAA6AP40QFg+wwGg22rANB9 8KMDAAD0AfzoAAAAPQA/OgA0wmAwiJ9LPzo6YuIdoCK6H314HGOMDgD1Y9vso6OjrWgC0E+0Mfrw OMYYHQCqYltr7DdAs+BHBwAA6AH40QGgEQr50QGgOnyPDgBNET/NPhgMmJMHqArfowNA7TA6B9gC +NEBoAkYcwNsGPzoAFA/Rc055h+gOvjRAQAAegF+dAAAgD6AHx0AAKAH4EcHAADoA6zrvitkXxMV egUpzVXlq2L9KyZbjq1VOT0BAKDmdd2Nj1Dtx7T+l+9pHni4Oz9yde7aFLYHvvR6iQH1YlbDcFqm gHzjL1+VI+tlyDcERhrLNGXkh8XOZEZZ4Z/GEZYcAQAohj1Gr+JH9xkPp5UKWwvfwz2zf7ohDFvB GD314+G6ZAl83QtblFGuLT/XhEeaN12mEc/NWxGjcXLBYAMA1Iuyx+hN+9GNR3lmePQRoS9NCfm1 pLe7FNKYmawo1mjP0nKwuAAA3WKjfvTqC0OG92csKt+Xvro5lJNjekOULd8Y0Ndl1G2VKgqvd39r 2zHhdHYAAEAUTeyP7nsoF52YLUpR+RX1Cc+6FyXsYK6F+An8bKbE0KfEQmCB5nV6NPCjAwCUpF4/ ekrYUjrH2TU+vje2/GT8y3Ebpvqse43diyqTKAAAEE+D36MHxme5k7dG3hKu8fjEPn2MaXBDn1yB Rxq58mvcSdp4My5G4RpLj1EMAACaoGY/uvFem/2+WyCxkcDnUjWslD4fUOhFa2d653t5YX0Cwg3d fO/9heU76xtTtB4v7Z8OKOxMKa7z4izXqRJ+dACA8tTrR/e9ueZ8Oodfc4vP5TtYSE/7eK56kcJ9 Mu149aoF9A/IKfdXTMpw9lpOJQAArGFddwAAgB7Auu4AAAB9oM/ruse/bN8t+lovAACoRBPfo7eE vlq4vtYLAAAqgR8dAACgB+BHBwAA6AMN+tGrryK+AewvrX3fQzu3RAvI2TotVAkAABqkOT96eE3v jBoNT9aHMFZ30VUyEgeUce6w4iu0qJK5yuTqnysfAAB2iybWdd8KTituLG9ub4pawmQahBexd6b3 LQprr50X0N8J43IAgJ2l/v3RY2atDdMV+MspylmoYaorEtiNNL6I0n6HomPxXMdB7kL6AADQdepf 191nRYxJZmPhd1uUM/0WqUsf586h2V92Wb7jPn2ccd8cAAAA9IeN+dGr74dWmhJj61o6EKVXmzcU 8FnrooWyCQoAQJ/ZjB/dMFGRu5HGpw9TdLexpg1e9c5KufYxegPYdQCAPtHg9+g+MxMwP773z+0j 9pR+lfkAPaNzEFxOoK1ntrdpSi3zECWEYMsBAPpHzX50Y3/r1KQZ1ks/bmcJy4kvOo3ob975nNPG v04DaVhf5/g4d+CbKaO/Hj9w7R/ve3Mwt318egbeQAQAgJ5Qux/d9/aWL27/LJfeeTxgt3ILjfwr PkvgZ0XhuaKw3wAA/Yd13QEAAHoA67oDAAD0gcQeo/dmf3QAAIAdwh6j92Z/dAAAgB0CPzoAAEAP wI8OAADQBzrpR7dXbonJEhDFOucAANB5avejb2D99qKrugbMebZ8W1EdAAAA2kXv/eg+g92G/dwA AADqoub90Yvud17X/ugAAAA7TiPrutsG2N4rrA37o7O7KAAA9Ifm9kevyAbeVvPtRw4AANA9NrM/ elHq3R8dAACg9zT7PXot771jzgEAAHKp2Y8uEfudi7X7Z/z+37qQSC+4b/9yZ7kAAABdpQk/ei1b jzv3/C5hektseQ4AANA9ev89OgAAwC7Auu4AAAB9oJPrugMAAIAJ+6MDAAD0AfzoAAAAPQA/OgAA QB+o/3t0aALWqYVNYl9v7dw5qS49q8sJL25hLIZRUVp1AvUNtIPz3/ZcDCktVGmjtHZdd0hhyTzY JL51G0vsnFTILBV9ENelZy1y9AROY2msjpWrUomm0He9Cpjh3PrapQf6KEWVzFUmV/9c+btOO9d1 hwznJQ7QEHVdb2EjUZ269KxFzhYHhU4rbuxpqcdLm0yDou3m7NPYeubq72TXx+UaNe+P7kPvRaZH nIuw5s5NNSqnVM3aha9eeoPYafS/Yvazz/JurNH6Wq++YjxhncNH+2A7J/ZtAheJb4BeSLKcbKVw +irraYYF2lo1fVKKjsVzHQe+OYAeU7Mf3deC+trs+l/OI9uSE0jflSvDVy9nH8h+pGZHfLOOhvyN dY37Wq9dI9C1os3F1QHdOs77pQSBm8vXY3Ae9+njjPvmAPpMvX708PkOD5p9p22Tcnzp23ODxVBO 29zOTUX51elrvdqPMfNRl8x6BW4Mn+Y+W6WPvDdZ66Jj6231JJxW2Xfcdx3mzsiG0/SHNvjRneOn LcoB6e/V39d6NY0xNtqiJu3E+dipa4BbjkLFbUC96peNPccWk8t2rlVUo83wPfrO0dfHcV/r1TZi Hv3GmN6XxXfKWn4qUweNcWQDU7t2uXY7l5bs1L+cQF/7ZNTSRCWE9NuWp2zoe3Rj9ilrWX1IHTO8 blpOC9Gn7CTiTRnx1MtwM9szgXqj2Xed7pbO5kIk7vlenb7Wq4U4rzfD5x0jx3jFwT4onvMYWYRT z4D8jckJ/BtzUemXeky5znYLCPE9T5z6B9oh/rlk1N15rwX0F8/1c6S9++LT05AT1rMnbOZ79EA7 xru9NyOnbRRSNfK9gcD0YCCNFGzkGulrvVpIbvs0J6qWS72oqiXkhGfXK2pVon0K6VPXSYnPEvhZ UXiuqF28l1nXHQAAoAfgRwcAAOgD7I8OAADQC9gfHQAAoA/gRwcAAOgB+NEBAKAz2N+7Qwb7o3eD nf08GjaM76Pwdi7eYN8X5T4+ri4n3D5FVyvbfGsXPe/OdR2kQrtFZnGuMwF38H2PPtBWVA2HW1N9 N6A3ChvDWDssN54rLY1EPtkLPUyc94UhJH5Fl4pywu2jr6YSQ6GmyLWs9oPauaJLifNuK1mi/Z1y ShPumWVlhbsR+opVzvTOXG3Bt6475rwlBC4pgHqpa9kWKdsJiKeu+6IWOVt8EjoHrEbj6+mbPi9N c6StERmZXqyaGvbLGfd1BVr+QPbuj17vGF3v9aRHjvyLFwZkNionpiItx1cvvUHsNOK67gOrKha9 qarT13q1lorP+sAD1Dl27NZqnYGLxDdALyRZTrZSeUUtCWHDVpS6lCwqp7lrQ2+NNl+BAbx+9HLm 3O65pGmO2B99I/jq5ewD2Y9U38nNfhryN9bH72u9ukX17k6ga0Wbi2dAWU5Ooe6Rb2wTGPMEOgo2 gednITkx8psYpNmi2nut1utHD9czPGg2rqStyPGlb+/5c1FO29zOTUX51elrvdqG78Fab3enu63t 09w3QtBH3hurdVGLq/e0cuOBQp33V9O1LqRkRhO2f/u0wY9el8DaFdtl+tqGfa1XXXD7lMPZbrUM QLuFUeUtapJLL0+H93v0yDH6tvSG0vT1rPW1XpvENytetG2Nh4PPmPnEtvxUpg4a44iz3Zout2jK yPMSIz8mTa7wsJz4+taF3T6bLL0Wavaj+zBmn3QniuHLjPHHNCenhehTdpKnaqBehpvZngnUG83u ruluab0/t5mRR1/r1UJyLUFkszizGO0f6bIN66nfFwH5G5MT+DfeyMXc7Ea5RhZfe+ael5iT4muf oo1Wop2dOM2wfmvLyfYJNLKvyoWew9tkM9+jB5IZF8rW5bSNQqqGE+s3cO5fTlGFGrlG+lqvthF5 f1WRVlcRvsRF9SwhJ3CZFS2lYrnhg4WqVrQdip5cH7VcD7U0WpUsLcK3rnuN5hwAAACaBj86AABA H/Duj84YHQAAoEv49kdnjA4AANAl8KMDAAD0APzoAAAAfWBD36NDRWht2CT29VbLd8O1U5ee1eWE P6Yv+hHz5pfK2FiJPMqahf3RWw4TIbBJnNebcadH3vhFV4wp9DCpS89a5OgJnJ2DQjOa8U2ht7Dd 2uGVUvS/wvoHyrXlR2Yphy0k09+pT7h9+kkb1nWHAM5LFqAh6rreihqJotSlZy1ytvUkNJ7Dvl6I nabiGTHKLdTjqYJdblgf/fiO2Cz2R+9Vx81XL71B7DTius+ds45G3g1PCfavXn3FeDLozwrnU3hw cpVfafcpCFwkvgF6IclyspUiMwYmFVpizAKzCBm+e1xcTbH1GrUQ9kf3Os/09L7jbcNXL2cfyH6k +k6u0c/Vc22mHfpar10j0LWizaWmAXS5cp2Gs8bnXu4YWqy7VdfNqZXv6b3TFxL7o8dI7tYlUk7b 3M5NRfnV6Wu92o8x81GXzHoFbgyf5r4Rgj7ybqLW1U+N09xK3jkqZEHDD+1AmkCvwve0jxxt9pM2 +NHrEli7YrtMX9uwr/VqmvDQDZyPHeeEUO1scWQv9b3KINoYXU6a+SpFGFN3FVVtP3yPvnP09az1 tV5tI8ZyGA8HXxbfKWv5qUwdNMYRpzeh6XJ1nB4oW73asQ1BWM+wqCySUYuGu9OPZ3/0E3JaiD5l J3HzYM56GX1VeybQ9l3pkvWOs96f28zIoK/1aiHO601vtMhmMQyMfVA85zGyCKeeAfkbkxP4N+ai 0i/1+MT2hLOvPXPrG1/Z+Eeurz2N+9pZuvPeDMsJdB/7f1+zP3rLKaRqOLH+YM39yymqUCPXSF/r 1UJy26c5UbVc6kVVLSEncJkVLaXecsM/w/IrNn7uHVT6uoq5N4vK6TOs6w4AANAD8KMDAAD0AfZH BwAA6AXsjw4AANAH8KMDAAD0APzoAADQOvSPUSES9kfvBrQ2bIaYj3rbcyna90WJT+drkVNvuxX6 OrxRtqWJcz0JyIf90VsOvVTYGM61Sox/4y/IoouWFHqYONUwhMSv6FJRTu3tFtkUegs74zrO41Xq FdDHEF70eFH5ToXD6YsW3RnasK47BMg6qttWBPpPjXd0UWNQlLrui1rkbOtJqD+HjWeyMcDNJgmM 89KcPnrpRY+L1v8wVpgpdF2F5cdI6Bzsj96W2a1a8NVLbxA7jbiub+eso5F3Y43W13q1Ft9As1x2 /Vlh3Ln6wXIT5psncJFUbzcj0lA7dMKStV/DFsL+6F7nmZ6+6GzVtvDVy9kHsh+pvpNr9Kn1XJtp h77Wa9cIdK1oc6lv4GhnNy5742D4OemT2R50/TuhcIOwP3qM5G5dHOW0ze3cVJRfnb7Wq234err6 CLJ6W3W3tX2ab6bdqmPMY0lcjeKV99nUosfj5YeV3C0b3wY/el0Ca1dsl+lrG/a1XnXhvH2cExug 0612a1STouOioso0nb7T8D36ztHXs9bXem0S36x4UYyHg8+Y+Ypo+alMHTTGkVrarWi526Vt+oCw P7ohp4XoU3aSp2qgXoab2Z4J1BvNNy+Xyc8SbGbk0dd6tZDwMzq+cZwuWKP9nedR4u5H530RkL8x OYF/Y9pNv9RjyvW1m7NedQkvqnzR4+XkG3H9XrblF3qudgn2R285hVQNJ7bdToG/nKIKNXKN9LVe baPeGye3qWsXXlRIOTnh2fWKWpVon/h2LnFt19IO2zpZdV1sXYJ13QEAAHoAfnQAAIA+wP7oAAAA vYD90QEAAPoAfnQAAIAegB8dAACgD7A/+nawW8/33afz++mAHAAA2FFq/B49bHskz2gZAu3EufJt 7FmEI22lhaxQZ0HxvRY7fUBV58SGUXGjUKcOTJAAAMAJalzXPTNmPgvkNFoBK+i0i4VGpYFeghEP 6OO0nWH9fTLF6lIY0uJxygEAgJ1lc/uj6ymdEpqePY7R1qlPIFft+juV9M1tAAAAZLTXj66PfSsW 5BvIduJtAGPGvuXaAgDA1mh0XfeNWf0wFSeow7PuMRnLzWQAAAAUoA37o/uo10lcWtvNZMScAwBA FTb0PbqROLNe9nE9QUZdpt356rv9RlsgfTh7lWkA5yv9vPgGAACR1OlHz3053DkLbR8fnNxLOPtp F5SLndc4bg+LfXr6cKbXyw23ktOQO4WL5VN3ygEAgB2lRj96rlHxJTCOh38WIqZEp1GvWEpAgvOv ounDWQAAYBdhXXcAAIAewLruAAAAfaC936PHE/jcfMOaAAAAbI1Gv0ffDG3QoYvQEwIA6BX40QEA AHoAfvRtQgMCAEBdJPYYvXN+9IzBMcaRLaq0LXaz1gAAO409Ri/kR9+a3hb6MnOFlojZFkaXqMbG 9K2rAwAAfaYffvRWKbNdsp7NthUBAICNUvP+6NmKpM6FXY24vb6pLtC5+qmR17ZbvoGpnd5ZelF9 fMJzcQ7QjSIC+uS2Q1F9AACg69T8PXp63P7LsPG6QbJNlC08+2nI9yUz7Lqd3pmxhD4BjE5MOL2z PQP6BNohbOYBAKC3NPE9ejlb4hz4xqQsKnkD+tiW2PlvFX2cR/TjeCIAAHaL1u6PXs7mNfc6WCF9 9BFzM+p4wZADAOwmNfvRY2j0HeytGLNCs9yRM/ZVKsKsOwDADlKzH914w0tPYLjPszRhZ7CeXZef JbBd4GJNevvSB4RH6lMjxqsGYX2yatrKON8kAACA/lOvHz33/S9fMvuvXA+98z2ygJBcVZ2JY+bP 4617ePAd0DCmRgAAsNO01o9egrbpY7MxDdvfFAAAUC+s695JDO8GAABAH/ZH30FoeQAAMOnB/uhQ Ds4dAECvCKzrHhkCAADA1tH96OsB93dfeUNEJZKo4zSJJDIUtZKEkJCQkJCQsB2hrES31Erk8Yce EJHLX312bdGvvvqGDEVWsg51+y+SECdOnDhx4sRbED+27kokkZWSYZJa9Kd+95ls1l2UWkdGw5Fo JDIiTpw4ceLEibchngzTcG3Oxf56baGUrNRCKbWSuZrLStRKqZWSlajV+idx4sSJEydOfLvx9U+l RBKl1oNxEVGrYz/6Cz+4nlp4tZJkmKjUjy6SDvSPfxInTpw4ceLEtxs/YZrVSn3uM5dE5PJXn/03 f/AHfyAi//ij2fD/DQ9Xavih4eG/Hg5lePivh2qlRO78JE6cOHHixIlvN66b5tW/ruRD8m8/MRWR l35wbf09+lOffVAAAACgmyRDGTz5O3/se0s+TdGGl/UJCQkJCQkJVdA0/3+ysAEHq5SMIwAAAABJ RU5ErkJggg== ------=_20041011113302_59241-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 09:02:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03854 for ; Mon, 11 Oct 2004 09:02:11 -0400 (EDT) Received: (qmail 27656 invoked by uid 605); 11 Oct 2004 13:02:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27647 invoked from network); 11 Oct 2004 13:02:08 -0000 Received: from mail1.panix.com (166.84.1.72) by mail.netbsd.org with SMTP; 11 Oct 2004 13:02:08 -0000 Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 8EA6448719; Mon, 11 Oct 2004 09:02:07 -0400 (EDT) Received: (from atlunde@localhost) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i9BD27L06033; Mon, 11 Oct 2004 09:02:07 -0400 (EDT) Date: Mon, 11 Oct 2004 09:02:07 -0400 From: Albert Lunde To: ietf-ssh@NetBSD.org Subject: Re: Text file type hint proposal for filexfer Message-ID: <20041011130207.GA28489@panix.com> References: <20041010225614.GA30626@chiark.greenend.org.uk> <00be01c4af3c$b76dee30$6302a8c0@Nucleus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00be01c4af3c$b76dee30$6302a8c0@Nucleus> User-Agent: Mutt/1.4.2.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Oct 11, 2004 at 04:47:56AM +0200, denis bider wrote: > My above proposal is ill-conceived only if there is a platform where: > * file type (text/bin) is not determined, and > * line endings are not one of LF/CR or a combination (CRLF, LFCR). > > If anyone is aware of such a platform, please let me know. If there isn't one > though, I suggest the server shouldn't have to support SSH_FXF_TEXT if file > type isn't determined. The client can read binary and convert line endings if > it so pleases. If your are looking for cases that are unlike Unix semantics, I'd suggest looking at the IBM mainframe operating systems: CMS, TSO, MVS, etc. One of the cases that appears there is fixed-length records with no delimiters in the binary representation. This may be blocked (though that's more common on tape devices). I think there are also variable-length records with a none-of- the-above line representation. There are various file attributes, but I wouldn't promise that there are no cases where the file format is ambiguous. (And of course, the default encoding was EBCDIC.) (I, thankfully, haven't had to work on those systems for several years, so I can't provide too many details.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 11:17:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13821 for ; Mon, 11 Oct 2004 11:17:27 -0400 (EDT) Received: (qmail 13197 invoked by uid 605); 11 Oct 2004 15:17:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13175 invoked from network); 11 Oct 2004 15:17:24 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Oct 2004 15:17:24 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id BEB2C1FBF7C; Mon, 11 Oct 2004 17:07:51 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 2E6381FBE42; Mon, 11 Oct 2004 16:57:20 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9BEvEih023929; Mon, 11 Oct 2004 16:57:14 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9BEuuKO023920; Mon, 11 Oct 2004 16:56:56 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> <41686AB6.60302@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 11 Oct 2004 16:54:06 +0200 In-Reply-To: <41686AB6.60302@vandyke.com> Message-ID: Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > I would definitely prefer to see the server do the translation > when it can... that's why we went to UTF-8 in the first place. I think there's one more use case that you need to consider, which I expect is quite common: The remote filesystem using the foo charset. The local system using the same foo charset. Why do I think this is common? Because on both sides, it's the same user's files, and the user is likely to use his or her favourite charset (iso-8859-1, utf-8, euc-jis, whatever) on most or all systems where he or she has an account. What you call "raw mode" will work fine in this case, no matter if the sftp implementation on server or client side knows about the foo charset. I like Jeffrey Hutzelman's proposal: Have two modes of operation, and let the client select which mode it prefers, 1. Server tells client the server's best guess as to what character set is used for filenames, and doesn't convert filenames in any way. 2. All filenames on the wire are utf-8. Server converts filenames to and from utf-8 on a best effort basis, according to it's best guess of the actual charset. (What's the right thing to do if/when conversion fails, I don't know yet). In both cases, server can tell client what charset is used on the server side (or "unknown") at startup. Client can select mode of operation either as a global protocol state, or a per request-flag. I don't think I care very much if the mode selection is global or per request; I'd expect most clients to choose one mode and stick to that. The reasons I like this are: * It is fairly simple. * The client has the final say on whether or not the server should do any conversion. * The use case above is easily supported, without requiring any special server (or client) support for the obscure foo charset. * I don't see any use cases where the above scheme fails, and a more complicated scheme could do better. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 11:53:15 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17130 for ; Mon, 11 Oct 2004 11:53:14 -0400 (EDT) Received: (qmail 7308 invoked by uid 605); 11 Oct 2004 15:53:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7266 invoked from network); 11 Oct 2004 15:53:13 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 11 Oct 2004 15:53:12 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa28738; 11 Oct 2004 11:52 EDT Date: Mon, 11 Oct 2004 11:52:41 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Joseph Galbraith cc: ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... Message-ID: <992340000.1097509961@minbar.fac.cs.cmu.edu> In-Reply-To: References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> <41686AB6.60302@vandyke.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Monday, October 11, 2004 16:54:06 +0200 Niels M=F6ller=20 wrote: > Joseph Galbraith writes: > >> I would definitely prefer to see the server do the translation >> when it can... that's why we went to UTF-8 in the first place. > > I think there's one more use case that you need to consider, which I > expect is quite common: > > The remote filesystem using the foo charset. The local system using > the same foo charset. Why do I think this is common? Because on both > sides, it's the same user's files, and the user is likely to use his > or her favourite charset (iso-8859-1, utf-8, euc-jis, whatever) on > most or all systems where he or she has an account. > > What you call "raw mode" will work fine in this case, no matter if the > sftp implementation on server or client side knows about the foo > charset. > > I like Jeffrey Hutzelman's proposal: Have two modes of operation, and > let the client select which mode it prefers, > > 1. Server tells client the server's best guess as to what character > set is used for filenames, and doesn't convert filenames in any > way. > > 2. All filenames on the wire are utf-8. Server converts filenames to > and from utf-8 on a best effort basis, according to it's best > guess of the actual charset. (What's the right thing to do if/when > conversion fails, I don't know yet). IMHO it is important that the server identify its character set up front,=20 so that the client is able to use that information in deciding which mode=20 to use. Also, the server needs to be able to indicate that it is incapable = of performing Unicode conversion. I'd like to be able to say that the=20 server MUST be capable of performing the conversion, but I don't think=20 that's realistic. If the server is capable of doing conversion, then conversion from the=20 local character set to unicode should not be able to fail. If it does,=20 something is very wrong. I can think of only two cases in which the conversion from UTF-8 to the=20 local character set can fail. The first is when the input is somehow=20 invalid (bad UTF-8, contains illegal Unicode code points, etc). We could=20 handle this in a number of ways, up to and including terminating the=20 connection. :-) The second case is when the input is valid, but contains characters not=20 present in the local character set. The server's mapping should be good=20 enough to handle cases where the same local character can be represented in = multiple ways in unicode (for example, there are at least two ways to write = =C5 in unicode, but only one way in iso-8859-1). For characters which are=20 genuinely not in the local character set, the server can return an=20 appropriate error depending on context. For example, trying to open a file = whose name contains an untranslateable character will always fail with=20 something ENOENT-like. Trying to create such a file should fail with an=20 illegal filename. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 13:11:15 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23056 for ; Mon, 11 Oct 2004 13:11:15 -0400 (EDT) Received: (qmail 28716 invoked by uid 605); 11 Oct 2004 17:11:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28668 invoked from network); 11 Oct 2004 17:11:12 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 11 Oct 2004 17:11:11 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA01200; Mon, 11 Oct 2004 13:11:09 -0400 (EDT) From: der Mouse Message-Id: <200410111711.NAA01200@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. Date: Mon, 11 Oct 2004 12:39:41 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... In-Reply-To: <992340000.1097509961@minbar.fac.cs.cmu.edu> References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> <41686AB6.60302@vandyke.com> <992340000.1097509961@minbar.fac.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > IMHO it is important that the server identify its character set up > front, [...] What about cases where there is no well-defined character set, such as most Unix variants? (Suppose I have a file whose name consists of the octets 0xc3 0xa1 0xd0 0xbf. Is that a file named LATIN SMALL LETTER A WITH ACUTE - CYRILLIC SMALL LETTER PE (UTF-8), a file named LATIN CAPTIAL LETTER A WITH TILDE - INVERTED EXCLAMATION MARK - LATIN CAPITAL LETTER EDH - INVERTED QUESTION MARK (8859-1[%]), a file named GREEK CAPITAL LETTER GAMMA - some character whose name I'm not sure of - GREEK CAPITAL LETTER PI - GREEK CAPITAL LETTER OMEGA WITH TONOS (8859-7[%]), a file whose name represents the integer 3173013909 rather than any character sequence (base 254 with digits 0x01-0x2e and 0x30-0xff), or what? (Given how nonsensical the others are, the last of those may actually be the most plausible.) Nobody but the entities (software and/or humans) the file was created for and used by can tell. Certainly ssh/sshd can't, not without being told somehow. Anything predicated on the assumption that every filename consists of characters will run into this problem. I strongly believe there needs to be some provision for filenames to be treated as opaque octet sequences rather than insisting that they are character sequences. /~\ 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 [%] Names taken from Unicode 0080-00FF and 0370-03FF; I don't have a handy reference to the names 8859 uses. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 16:34:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20281 for ; Mon, 11 Oct 2004 16:34:33 -0400 (EDT) Received: (qmail 15022 invoked by uid 605); 11 Oct 2004 20:34:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15007 invoked from network); 11 Oct 2004 20:34:30 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Oct 2004 20:34:30 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id E3B1E1F9CB; Mon, 11 Oct 2004 22:27:48 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 3AB0060698; Mon, 11 Oct 2004 22:26:17 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9BKOFih003230; Mon, 11 Oct 2004 22:24:15 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9BKO9IX003227; Mon, 11 Oct 2004 22:24:09 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> <41686AB6.60302@vandyke.com> <992340000.1097509961@minbar.fac.cs.cmu.edu> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 11 Oct 2004 22:23:17 +0200 In-Reply-To: <992340000.1097509961@minbar.fac.cs.cmu.edu> Message-ID: Lines: 73 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > On Monday, October 11, 2004 16:54:06 +0200 Niels Möller > wrote: > > I like Jeffrey Hutzelman's proposal: Have two modes of operation, and > > let the client select which mode it prefers, > > > > 1. Server tells client the server's best guess as to what character > > set is used for filenames, and doesn't convert filenames in any > > way. > > > > 2. All filenames on the wire are utf-8. Server converts filenames to > > and from utf-8 on a best effort basis, according to it's best > > guess of the actual charset. (What's the right thing to do if/when > > conversion fails, I don't know yet). > > IMHO it is important that the server identify its character set up > front, so that the client is able to use that information in deciding > which mode to use. Agree. > Also, the server needs to be able to indicate that it is incapable > of performing Unicode conversion. I'd like to be able to say that > the server MUST be capable of performing the conversion, but I don't > think that's realistic. The server can be incapable of doing a proper conversion in at least two ways: Either the server has no idea whatsoever which charset to use to interpret its local filenames. Or it knows somehow that it should use a prticular characterset (say, euc-jis), but it hasn't been compiled with support for that conversion. I don't think it is possible to forbid the first failure mode; we must allow the server to say charset "unknown" or "" in this case. We could forbid the second case, in effect forcing the server to say "unknown" when it in fact knows the character set, but isn't able to convert it. But I don't think it is a good idea to do that; it is better to at least tell the client what the charset is. > I can think of only two cases in which the conversion from UTF-8 to > the local character set can fail. I don't think conversion utf-8 -> local is a big problem. Some filenames can't be represented, and they must simply be treated as non-existing files. And invalid utf-8 should be a protocol error (under no circumstances should an implementation be allowed to say that it's using utf-8, and then send invalid utf-8 filenames). Conversion the other way is more difficult. The problem is, when the server thinks it should convert from A to utf-8 (based, for example, on examining the user's $LC_CTYPE), but in fact some file names are stored using a different charset B, where B sequences are invalid when interpreted as A-characters. Only example I can come up with off the top of my head is A = utf-8 and B = latin1, but I'm pretty sure there are some other examples where neither A nor B is utf-8. I could think of some ways to deal with this: (i) pretend the files don't exist, or (ii) replace unexpected characters or character sequences with uniquely chosen private use characters. I think (i) will be a very confusing failure mode for users, and (ii) seems quite ugly. Telling the client "sorry, here's some strange filename I can't convert to utf-8, you can try again with raw filenames, if you like" seems simpler to udnerstand. Note that this can happen even (or perhaps it's even more likely to happen) when the local character set is believed to be utf-8, and some file names violate this assumption. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 16:59:13 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26582 for ; Mon, 11 Oct 2004 16:59:12 -0400 (EDT) Received: (qmail 1196 invoked by uid 605); 11 Oct 2004 20:59:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1187 invoked from network); 11 Oct 2004 20:59:10 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Oct 2004 20:59:09 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 5472F4B1D2; Mon, 11 Oct 2004 22:59:04 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id D82301FB48; Mon, 11 Oct 2004 22:52:44 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9BKqfih013485; Mon, 11 Oct 2004 22:52:41 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9BKqXxw013476; Mon, 11 Oct 2004 22:52:33 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes (fwd) References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 11 Oct 2004 22:50:43 +0200 In-Reply-To: Message-ID: Lines: 69 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > In [CONNECT], we describe the opening of a channel. This message has the > format of: > byte SSH_MSG_CHANNEL_OPEN > string channel type in US-ASCII only > uint32 sender channel > uint32 initial window size > uint32 maximum packet size > ... channel type specific data follows > where the 'channel type' "is a name as described in [SSH-ARCH] and > [SSH-NUMBERS], with similar extension mechanisms." (Not much to go on > there.) I think the intention is fairly clear. Names like "foo@example.com" can be defined by whoever owns the "example.com" domain. Names without "@" in them needs standardization. > Further in the document, we say, "Many 'channel type' values have > extensions that are specific to that particular 'channel type'. An > example is requesting a pty (pseudo terminal) for an interactive session." channel types and channel request types are different. But I think the intention is that they should live in one single name space. So if "pty-req" is a channel request type, that name should not be reused for a channel type. And a channel request type like "pty-req" is intended to imply *one* operation, with *one* format for the corresponding message. Currently, the channel type "session" is the only standardized channel type where "pty-req" make sense. But it is fully possible to define a new channel type, say "session-ng@example.com", where the request type "pty-req" is also meaningful. It is however *not* approproate to define a new channel type "session-ng@example.com", and say that for channels of this type, "pty-req" has a different unrelated meaning, or that requests of type "pty-req" should use a different format. That is my understanding of the spec, do you agree with this? I know it's technically possible to let "pty-req" have a totally different meaning and a totally different request format for each channel type (like we do for the numerical open failure codes), but I don't think that's how the name space is intended to be used. > I'll suggest that the mechanism be the IETF CONSENSUS method [RFC > 2434] I think "IETF CONSENSUS" is reasonable, since the namespace is for all practical purposes unlimited, but we still want some level of review to keep the namespace from cluttering up. > This is the IANA controlled namespace which, as Jeffrey notes below, > may contain the "@example.com" extension space if they are defined > through an appropriate method. I can make no sense out of this comment. I think the context for Jeffrey's comment was the allocation of the *numerical* reason codes in SSH_MSG_CHANNEL_OPEN_FAILURE, where the point was that the specification for any channel type (no matter if it's standardized or a local "foo@example.com" type) can allocate open failure codes from the "channel-type specific" range in > > >> > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > > >> > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, > > >> > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 17:02:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27340 for ; Mon, 11 Oct 2004 17:02:20 -0400 (EDT) Received: (qmail 4284 invoked by uid 605); 11 Oct 2004 21:02:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4275 invoked from network); 11 Oct 2004 21:02:19 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 11 Oct 2004 21:02:19 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa30007; 11 Oct 2004 17:01 EDT Date: Mon, 11 Oct 2004 17:01:55 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= cc: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... Message-ID: <1049560000.1097528515@minbar.fac.cs.cmu.edu> In-Reply-To: References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> <41686AB6.60302@vandyke.com> <992340000.1097509961@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Monday, October 11, 2004 22:23:17 +0200 Niels M=F6ller=20 wrote: >> Also, the server needs to be able to indicate that it is incapable >> of performing Unicode conversion. I'd like to be able to say that >> the server MUST be capable of performing the conversion, but I don't >> think that's realistic. > > The server can be incapable of doing a proper conversion in at least > two ways: Either the server has no idea whatsoever which charset to > use to interpret its local filenames. Or it knows somehow that it > should use a prticular characterset (say, euc-jis), but it hasn't been > compiled with support for that conversion. > > I don't think it is possible to forbid the first failure mode; we must > allow the server to say charset "unknown" or "" in this case. > > We could forbid the second case, in effect forcing the server to say > "unknown" when it in fact knows the character set, but isn't able to > convert it. But I don't think it is a good idea to do that; it is > better to at least tell the client what the charset is. Agree. >> I can think of only two cases in which the conversion from UTF-8 to >> the local character set can fail. > > I don't think conversion utf-8 -> local is a big problem. Some > filenames can't be represented, and they must simply be treated as > non-existing files. And invalid utf-8 should be a protocol error > (under no circumstances should an implementation be allowed to say > that it's using utf-8, and then send invalid utf-8 filenames). Agree. > Telling the client "sorry, here's some strange filename I can't > convert to utf-8, you can try again with raw filenames, if you like" > seems simpler to udnerstand. Note that this can happen even (or > perhaps it's even more likely to happen) when the local character set > is believed to be utf-8, and some file names violate this assumption. I think it is more likely that the local character set is believed to be=20 UTF-8 and actually is not, than that we will believe the local character=20 set to be something "flat" like iso-8859-1 and then find characters which=20 are invalid in that set. In any case, I agree the behaviour you describe seems to be the most sane=20 thing to do in this situation. FWIW, it is worth noting that it is possible to tell with fairly high=20 probability whether a particular string is UTF-8 or some flat 8-bit=20 character set, because valid UTF-8 is fairly well structured and the=20 sequences which represent non-7-bit characters are fairly unlikely to occur = in flat character sets. So when conversion to UTF-8 is being done by the=20 server, it is possible for an implementation to apply a heuristic to allow=20 support of filesystems containing both UTF-8 and an 8-bit character set,=20 even in separate components of the same pathname. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 11 17:19:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29317 for ; Mon, 11 Oct 2004 17:19:20 -0400 (EDT) Received: (qmail 15486 invoked by uid 605); 11 Oct 2004 21:19:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15475 invoked from network); 11 Oct 2004 21:19:16 -0000 Received: from ajax.cnchost.com (207.155.248.31) by mail.netbsd.org with SMTP; 11 Oct 2004 21:19:16 -0000 Received: from Nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by ajax.cnchost.com id RAA21969; Mon, 11 Oct 2004 17:19:11 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Albert Lunde'" , Subject: RE: Text file type hint proposal for filexfer Date: Mon, 11 Oct 2004 23:18:59 +0200 Message-ID: <014a01c4afd7$eeb0cc50$6302a8c0@Nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20041011130207.GA28489@panix.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I guess then it would be wise to shorten my proposed addition and remove = this part: Files not advertised by the server as textual in the attrib flags MUST NOT be opened with the SSH_FXF_TEXT flag. And leave only this: A server MAY fail textual open requests for files which were not advertised as textual in attrib-flags. I.e. make it clear that the server only NEEDS to support SSH_FXF_TEXT = for files it advertises as textual in attrib-flags. For files of unknown text/bin disposition, the server MAY support SSH_FXF_TEXT, but does not need = to... > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org=20 > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Albert Lunde > Sent: Monday, October 11, 2004 15:02 > To: ietf-ssh@netbsd.org > Subject: Re: Text file type hint proposal for filexfer >=20 >=20 > On Mon, Oct 11, 2004 at 04:47:56AM +0200, denis bider wrote: > > My above proposal is ill-conceived only if there is a=20 > platform where: > > * file type (text/bin) is not determined, and > > * line endings are not one of LF/CR or a combination (CRLF, LFCR). > >=20 > > If anyone is aware of such a platform, please let me know.=20 > If there isn't one > > though, I suggest the server shouldn't have to support=20 > SSH_FXF_TEXT if file > > type isn't determined. The client can read binary and=20 > convert line endings if > > it so pleases. >=20 > If your are looking for cases that are unlike Unix semantics, I'd > suggest looking at the IBM mainframe operating systems: CMS, > TSO, MVS, etc. One of the cases that appears there is fixed-length > records with no delimiters in the binary representation. > This may be blocked (though that's more common on tape devices). >=20 > I think there are also variable-length records with a none-of- > the-above line representation. >=20 > There are various file attributes, but I wouldn't promise > that there are no cases where the file format is ambiguous. > (And of course, the default encoding was EBCDIC.) > (I, thankfully, haven't had to work on those systems for several > years, so I can't provide too many details.) >=20 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 12 02:20:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21078 for ; Tue, 12 Oct 2004 02:20:07 -0400 (EDT) Received: (qmail 27385 invoked by uid 605); 12 Oct 2004 06:20:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27331 invoked from network); 12 Oct 2004 06:19:59 -0000 Received: from srv04.zergon.net (67.15.0.20) by mail.netbsd.org with SMTP; 12 Oct 2004 06:19:59 -0000 Received: from srv04.zergon.net (localhost.localdomain [127.0.0.1]) by srv04.zergon.net (8.12.10/8.12.10) with ESMTP id i9C6Lgob029092; Tue, 12 Oct 2004 09:21:42 +0300 Received: (from apache@localhost) by srv04.zergon.net (8.12.10/8.12.10/Submit) id i9C6Lf2N029090; Tue, 12 Oct 2004 09:21:41 +0300 X-Authentication-Warning: srv04.zergon.net: apache set sender to roumen@roumenpetrov.info using -f Received: from 213.91.169.3 (proxying for 192.168.15.67) (SquirrelMail authenticated user roumen@roumenpetrov.info) by srv04.zergon.net with HTTP; Tue, 12 Oct 2004 09:21:41 +0300 (EEST) Message-ID: <40287.213.91.169.3.1097562101.squirrel@srv04.zergon.net> In-Reply-To: <1049560000.1097528515@minbar.fac.cs.cmu.edu> References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> <41686AB6.60302@vandyke.com> <992340000.1097509961@minbar.fac.cs.cmu.edu> <1049560000.1097528515@minbar.fac.cs.cmu.edu> Date: Tue, 12 Oct 2004 09:21:41 +0300 (EEST) Subject: Re: SFTP and unicode file names... From: roumen@roumenpetrov.info To: "Jeffrey Hutzelman" Cc: Niels =?iso-8859-1?Q?M=F6ller?= , "Joseph Galbraith" , ietf-ssh@NetBSD.org Reply-To: roumen@roumenpetrov.info User-Agent: SquirrelMail/1.4.2-1.7.ct MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > > > [SNIP] > in flat character sets. So when conversion to UTF-8 is being done by the > server, it is possible for an implementation to apply a heuristic to allow heuristic ??? This is inpossible. As example a valid cyrillic name in UTF-8 can be converted into valid name in more that one charset (ISO-8859-5, KOI8-R, CP1251). Client with help from user should tell server how to convert "utf-8" <-> 8-bit character set, i.e. prefered charset for filename on server(remote host). > support of filesystems containing both UTF-8 and an 8-bit character set, > even in separate components of the same pathname. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 12 05:09:53 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01801 for ; Tue, 12 Oct 2004 05:09:53 -0400 (EDT) Received: (qmail 6657 invoked by uid 605); 12 Oct 2004 09:09:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6648 invoked from network); 12 Oct 2004 09:09:50 -0000 Received: from neo.nbg.net (62.181.151.227) by mail.netbsd.org with SMTP; 12 Oct 2004 09:09:50 -0000 Received: (from uucp@localhost) by neo.nbg.net (8.11.7p1+Sun/8.11.7) id i9C8Xtw02816 for ; Tue, 12 Oct 2004 10:33:55 +0200 (MEST) Received: from mail.berlin.nbg.net(172.23.109.21) by neo.nbg.net via csmap (V6.0) id srcAAAOAaOFf; Tue, 12 Oct 04 10:33:55 +0200 Received: from esafe3.berlin.nbg.net (esafe3.berlin.nbg.net [172.23.109.19]) by s005mhb1.berlin.nbg.net (8.12.10/8.12.10) with SMTP id i9C8hVK4031859 for ; Tue, 12 Oct 2004 10:43:31 +0200 Received: from ns51429.i514.de ([IP=172.23.109.21]) by eSafe SMTP Relay 1097490604; Tue Oct 12 10:40:44 2004 Message-ID: Date: Tue, 12 Oct 2004 10:43:31 +0200 To: ietf-ssh@NetBSD.org From: Autoreply@ospa.de Subject: Re: Mail Delivery (failure kbartsch@ospa.de) X-MIMETrack: Serialize by Router on NS51429/OSPA_Rostock/DE(Release 5.0.11 |July 24, 2002) at12.10.2004 10:43:32 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Sehr geehrte OSPA-Kundin, sehr geehrter OSPA-Kunde, sehr geehrte Damen und Herren, Sie haben soeben eine E-Mail an die OstseeSparkasse Rostock (OSPA) gesendet. Herzlichen Dank. Leider k=F6nnen wir aus rechtlichen und Sicherheitsgr=FCnden =FCber das E-Mail-Verfahren keine Auftr=E4ge oder Weisungen entgegennehmen. Zur =DCbermittlung von beispielsweise =DCberweisungen und Wertpapierorders nu= tzen Sie bitte unser Onlinebanking/Brokerage-Verfahren oder unsere Gesch=E4ftsstellen. Einw=E4nde gegen Rechnungsabschl=FCsse und Belastungsbuchungen aus Lastschriften oder Widerspr=FCche jeglicher Art richten Sie bitte schriftlich an uns oder m=FCndlich =FCber eine unserer Gesch=E4ftsstellen. Gern nehmen wir Ihren Anruf unter unserer Service-Hot= line 01805 700 101 entgegen. Wir weisen darauf hin, dass per E-Mail =FCbermittelte Nachrichten ver=E4n= dert oder verf=E4lscht werden k=F6nnen. Herk=F6mmliche E-Mails sind nicht gege= n den Zugriff Dritter gesch=FCtzt und deshalb ist m=F6glicherweise die Vertraulichkeit nicht gewahrt. Von der =DCbermittlung sensitiver Gesch=E4ftsdaten sollten Sie daher abse= hen. Sollten Sie diese Nachricht irrt=FCmlich erhalten haben, bitten wir Sie, = sich telefonisch mit uns in Verbindung zu setzen. Freundliche Gr=FC=DFe OstseeSparkasse Rostock Diese Mail wurde automatisch erzeugt, antworten Sie bitte nicht an die Absenderadresse. OSPA Zentrum Am V=F6genteich 23 18057 Rostock Telefon: 01805 700 101 Fax : 0381 643-8209 Amtsgericht: HRA 1770 Steuernummer: 079/144/01741 http://www.ospa.de From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 12 08:12:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12607 for ; Tue, 12 Oct 2004 08:12:11 -0400 (EDT) Received: (qmail 20506 invoked by uid 605); 12 Oct 2004 12:12:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20452 invoked from network); 12 Oct 2004 12:11:59 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 12 Oct 2004 12:11:59 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2004 05:20:42 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9CCBtOE011232; Tue, 12 Oct 2004 05:11:56 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA06992; Tue, 12 Oct 2004 05:11:55 -0700 (PDT) Date: Tue, 12 Oct 2004 05:11:55 -0700 (PDT) From: Chris Lonvick To: =?iso-8859-1?q?Niels_M=F6ller?= cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes (fwd) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, On Mon, 11 Oct 2004, [iso-8859-1] Niels M=F6ller wrote: > Chris Lonvick writes: > > > This is the IANA controlled namespace which, as Jeffrey notes below, > > may contain the "@example.com" extension space if they are defined > > through an appropriate method. > > I can make no sense out of this comment. I think the context for > Jeffrey's comment was the allocation of the *numerical* reason codes > in SSH_MSG_CHANNEL_OPEN_FAILURE, where the point was that the > specification for any channel type (no matter if it's standardized or > a local "foo@example.com" type) can allocate open failure codes from > the "channel-type specific" range in I was saying that the IANA can control values for 'channel type' of "session" and even "session@example.com", as long as "session@example.com" is registered with the IANA through an RFC - even an Informational RFC. From=20that: > > >> > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer "session" and "foo@example.com" get to use this range (as long as any 'reason code' values have been registered with the IANA through an RFC action). > > >> > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, "bar@example.com" gets to use this range. Others may choose to also use "bar@example.com" and honor the associated codes. These are not registered with the IANA. > > >> > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way No one cares what is used in this range and it will not be honored by others. There's also nothing to register with the IANA. Make sense? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 12 09:04:18 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17609 for ; Tue, 12 Oct 2004 09:04:18 -0400 (EDT) Received: (qmail 22066 invoked by uid 605); 12 Oct 2004 13:04:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22057 invoked from network); 12 Oct 2004 13:04:15 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Oct 2004 13:04:15 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 6BA0C32D11; Tue, 12 Oct 2004 15:04:13 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 2997E32D11; Tue, 12 Oct 2004 15:04:09 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9CD48ih027091; Tue, 12 Oct 2004 15:04:08 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9CD3uFi027087; Tue, 12 Oct 2004 15:03:56 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: SFTP and unicode file names... References: <4162D042.3010305@vandyke.com> <467630000.1097251530@minbar.fac.cs.cmu.edu> <41686AB6.60302@vandyke.com> <992340000.1097509961@minbar.fac.cs.cmu.edu> <1049560000.1097528515@minbar.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 12 Oct 2004 15:03:52 +0200 In-Reply-To: <1049560000.1097528515@minbar.fac.cs.cmu.edu> Message-ID: Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > I think it is more likely that the local character set is believed to > be UTF-8 and actually is not, than that we will believe the local > character set to be something "flat" like iso-8859-1 and then find > characters which are invalid in that set. I agree, with the reservation that I don't have much experience with character sets that use eight-bit characters, and lots of different shift states. > FWIW, it is worth noting that it is possible to tell with fairly high > probability whether a particular string is UTF-8 or some flat 8-bit > character set, That may be correct (at least that's an advertised property of utf-8), but as far as I can see, that doesn't help much unless you have some clue about *which* flat 8-bit character set was used. If you know that a file system contains mixed latin-1 and utf-8 filenames (and no other character sets), you can probably make the heuristics work most of the time, but if you have a filesystem with mixed utf-8, iso-8859-1, iso-8859-5 and koi8, it gets rather difficult. I don't think heuristic decoding is a good idea. One problem is that you really need to be able to convert both ways: Say you have a directory containing filenames in utf-8 and iso-8859-1. The client asks for a directory listing, and you give it a utf-8 listing, using some working heuristic for converting the latin-1 names to utf-8 on the fly. Next, the user selects one file using the client's ui, and the client tries to open it. Now the server has to figure out if the filename to be opened should be converted to latin-1 or not (in the worst case, there exists files with both the utf-8 name and the corresponding latin1 name). I think this gets ugly. The hack I mentioned, to replace the sequences that are invalid utf8 with uniquely chosen private use characters, have a better chance of surviving the roundtrip to the client, but I'm sure that has other problems. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 12 09:34:03 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19787 for ; Tue, 12 Oct 2004 09:34:01 -0400 (EDT) Received: (qmail 10444 invoked by uid 605); 12 Oct 2004 13:33:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10425 invoked from network); 12 Oct 2004 13:33:57 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Oct 2004 13:33:57 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 9B0E01F15D0; Tue, 12 Oct 2004 15:33:55 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 9CC8C1F16E0; Tue, 12 Oct 2004 15:33:51 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9CDXjih027582; Tue, 12 Oct 2004 15:33:45 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9CDXdFQ027577; Tue, 12 Oct 2004 15:33:39 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes (fwd) References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 12 Oct 2004 15:33:35 +0200 In-Reply-To: Message-ID: Lines: 57 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,J_CHICKENPOX_21 autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: Sorry, but I still find this utterly confusing. > I was saying that the IANA can control values for 'channel type' of ^^^^^^ > "session" and even "session@example.com", as long as "session@example.com" > is registered with the IANA through an RFC - even an Informational RFC. Exactly what "values" are you talking about here? 1. Channel type id:s, example: "session"? 2. Channel request type id:s, example: "pty-req"? 3. Channel open failure reason codes in the "IETF / connection layer" range (0x0000 0000 - 0xFDFF FFFF), example: 0x0000 0001? 4. Channel open failure reason codes in the "channel-type specific" range (0xFE00 0000 - 0xFEFF FFFF), example: 0xFE00 0017? None of the alternatives make much sense to me (in particular, any IANA registration of the id "session@example.com" seems absurd), but I'd like to know exactly which values you are talking about before I write more about it. > From that: > > > > >> > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > "session" and "foo@example.com" get to use this range (as long as any > 'reason code' values have been registered with the IANA through an RFC > action). Ok, I only have one clarification: These reason codes should have a meaning that is reasonably independent of any particular channel-type. Ideally, the definition of any code in this range should not refer to any particular channel type, except possibly for examples. Currently defined values have this character, including SSH_OPEN_CONNECT_FAILED, which is applicable to all the channel types which perform some kind of forwarding. > > > >> > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, > "bar@example.com" gets to use this range. Others may choose to also use > "bar@example.com" and honor the associated codes. These are not > registered with the IANA. Ok. Values in this range are defined in the specification for the corresponding channel type. > > > >> > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way > No one cares what is used in this range and it will not be honored by > others. There's also nothing to register with the IANA. Ok. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 13 22:57:10 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09305 for ; Wed, 13 Oct 2004 22:57:10 -0400 (EDT) Received: (qmail 5323 invoked by uid 605); 14 Oct 2004 02:57:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5313 invoked from network); 14 Oct 2004 02:57:03 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 14 Oct 2004 02:57:03 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2004 20:06:03 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9E2uvk2022964; Wed, 13 Oct 2004 19:56:58 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA03476; Wed, 13 Oct 2004 19:57:00 -0700 (PDT) Date: Wed, 13 Oct 2004 19:57:00 -0700 (PDT) From: Chris Lonvick To: =?iso-8859-1?q?Niels_M=F6ller?= cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes (fwd) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Niels, On Tue, 12 Oct 2004, [iso-8859-1] Niels M=F6ller wrote: > Chris Lonvick writes: > > Sorry, but I still find this utterly confusing. > > > I was saying that the IANA can control values for 'channel type' of > ^^^^^^ > > "session" and even "session@example.com", as long as "session@example.c= om" > > is registered with the IANA through an RFC - even an Informational RFC. > > Exactly what "values" are you talking about here? I'd like to try to clarify the "parameter" from the 'value' that fills the "parameter" in the packet in the documents. Currently, there are places where the characters of ` and ' set off the 'values', and in other places, nothing sets off the values. I'd like to make that consistent throughout the documents. Do these examples work: -------current text in [CONNECT]-------- There are several kinds of requests that affect the state of the remote end "globally", independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. All such requests use the following format. byte SSH_MSG_GLOBAL_REQUEST string request name in US-ASCII only boolean want reply ... request-specific data follows Request names follow the DNS extensibility naming convention outlined in [SSH-ARCH]. ---------------------------------------- "Request names" in the last sentence is not distinguished. -------proposed text in [CONNECT]------- There are several kinds of requests that affect the state of the remote end globally, independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. All such requests use the following format. byte SSH_MSG_GLOBAL_REQUEST string request name in US-ASCII only boolean want reply ... request-specific data follows The value of 'request name' follows the DNS extensibility naming convention outlined in [SSH-ARCH]. ------------------------------------------ 'request name' is denoted as a parameter. In another place: -------current text in [CONNECT]-------- If want reply is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned. ---------------------------------------- I first thought that the first sentence was a grammatical error. :) -------proposed text in [CONNECT]------- If 'want reply' is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned. ---------------------------------------- This qualifies 'want reply' as a parameter. Does this clarify things? Does anyone have a better suggestion? > > 1. Channel type id:s, example: "session"? Yes. The values are in the left-hand column in the table in Section 4.2.2.1 in [NUMBERS]-06. They are "session", "x11", "forwarded-tcpip", and "direct-tcpip". > > 2. Channel request type id:s, example: "pty-req"? Yes. Section 4.2.2.3 in [NUMBERS]-06. > > 3. Channel open failure reason codes in the "IETF / connection layer" > range (0x0000 0000 - 0xFDFF FFFF), example: 0x0000 0001? Yes. This will be included in the next set of IDs. > > 4. Channel open failure reason codes in the "channel-type specific" > range (0xFE00 0000 - 0xFEFF FFFF), example: 0xFE00 0017? Yes. This will be included in the next set of IDs. > > None of the alternatives make much sense to me (in particular, any > IANA registration of the id "session@example.com" seems absurd), but > I'd like to know exactly which values you are talking about before I > write more about it. Sorry. I took my finger off of the statement in [ARCH] where we say that names that contain the "@" character will not be registered with the IANA; Section 6 in [ARCH]-16 and in various places in [NUMBERS]-06. (Which is why I ask for clarification. :) > > > From that: > > > > > > >> > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > > "session" and "foo@example.com" get to use this range (as long as any > > 'reason code' values have been registered with the IANA through an RFC > > action). Change that. It should be 0x0000 0000 - 0xFDFF FFFF IETF / connection layer "session" and the other values will use this range as long as they are registered with the IANA through an RFC action. > > Ok, I only have one clarification: These reason codes should have a > meaning that is reasonably independent of any particular channel-type. > Ideally, the definition of any code in this range should not refer to > any particular channel type, except possibly for examples. Currently > defined values have this character, including SSH_OPEN_CONNECT_FAILED, > which is applicable to all the channel types which perform some kind > of forwarding. OK. That should just be a few sentences in the appropriate places. Does anyone disagree with this? > > > > > >> > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, > > "bar@example.com" gets to use this range. Others may choose to also us= e > > "bar@example.com" and honor the associated codes. These are not > > registered with the IANA. > > Ok. Values in this range are defined in the specification for the > corresponding channel type. > > > > > >> > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any wa= y > > No one cares what is used in this range and it will not be honored by > > others. There's also nothing to register with the IANA. > > Ok. > > Regards, > /Niels > Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 15 18:36:07 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00843 for ; Fri, 15 Oct 2004 18:36:07 -0400 (EDT) Received: (qmail 20396 invoked by uid 605); 15 Oct 2004 22:36:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20387 invoked from network); 15 Oct 2004 22:36:04 -0000 Received: from unknown (HELO aol.com) (211.110.87.150) by mail.netbsd.org with SMTP; 15 Oct 2004 22:36:03 -0000 Message-ID: From: "Mildred Fink" To: ietf-ssh@NetBSD.org Subject: Swiss watches online - only $150 Date: Fri, 15 Oct 2004 22:30:49 +0000 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Do you want a Rolex Watch? http://yzr.vievv.com/replica/sales/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 15 19:47:03 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06324 for ; Fri, 15 Oct 2004 19:47:03 -0400 (EDT) Received: (qmail 2961 invoked by uid 605); 15 Oct 2004 23:47:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2949 invoked from network); 15 Oct 2004 23:47:00 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 15 Oct 2004 23:47:00 -0000 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 i9FNkxs3013370 for ; Fri, 15 Oct 2004 16:46:59 -0700 (PDT) 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 i9FNkwJf029445 for ; Fri, 15 Oct 2004 17:46:58 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9FNkjU0001394 for ; Fri, 15 Oct 2004 18:46:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9FNkiZs001393 for ietf-ssh@NetBSD.org; Fri, 15 Oct 2004 18:46:44 -0500 (CDT) Date: Fri, 15 Oct 2004 18:46:44 -0500 From: Nicolas Williams To: ietf-ssh@NetBSD.org Subject: Locale negotiation Message-ID: <20041015234644.GP19142@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Our users need to be able to have local locale settings propagated to remote sessions. The SSHv2 protocol does not provide a sufficiently general facility for this purpose. It does provide for language negotiation, but locales are more than just a language -- for example, locales typically specify a language, for L10N, and a codeset. The language negotiation in the SSHv2 protocol is sufficient for localization of UTF-8 display strings in the SSHv2 protocol. It is not sufficient for negotiation of locales for sessions. Currently we may use the environment variable passing facility of SSHv2 to pass POSIX locale variables (LANG, LC_ALL, LC_CTYPE, ...). This approach will work for platforms that support the same locales and implementations for POSIX platforms or, for non-POSIX platforms, which can map these variables and POSIX locale names to non-POSIX equivalents. Even where this approach works it only works if the server has support for the locales that its clients may so reference. There is no way to determine that a server may have support other locales that may satisfy its clients. So, I'll be posting, post-IETF 61, several I-Ds to address this. My current plan is to define RFC3066-like namespaces of locale categories and codesets, define an abstract description of locales, roughly matching the POSIX locale concept, and, finally, two extensions to SSHv2: - a global request for locale negotiation - a channel request for setting the locales for the various categories for a given channel Comments? Which of these I-Ds, if any, should be SECSH WG work items? Which WG, if any, is the most appropriate home for the more generic of these items? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 16 07:17:18 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12996 for ; Sat, 16 Oct 2004 07:17:17 -0400 (EDT) Received: (qmail 8990 invoked by uid 605); 16 Oct 2004 11:17:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8981 invoked from network); 16 Oct 2004 11:17:14 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 16 Oct 2004 11:17:13 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 0DCA11FFEB5; Sat, 16 Oct 2004 13:17:12 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 2B166201934; Sat, 16 Oct 2004 13:17:08 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9GBH7ih022996; Sat, 16 Oct 2004 13:17:07 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9GBH4Fv022993; Sat, 16 Oct 2004 13:17:04 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Nicolas Williams Cc: ietf-ssh@NetBSD.org Subject: Re: Locale negotiation References: <20041015234644.GP19142@binky.central.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 16 Oct 2004 13:17:03 +0200 In-Reply-To: <20041015234644.GP19142@binky.central.sun.com> Message-ID: Lines: 74 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Nicolas Williams writes: > My current plan is to define RFC3066-like namespaces of locale > categories and codesets, define an abstract description of locales, > roughly matching the POSIX locale concept, I'm not very familiar with these issues, but standardized naming of locales and locale properties seems somewhat out of scope for the secsh wg. > and, finally, two extensions to SSHv2: > > - a global request for locale negotiation > - a channel request for setting the locales for the various categories > for a given channel A channel request makes sense, and if the naming issues are solved, I hope it should be fairly simple. I don't know how the negotiation is supposed to work, if you want to transfer the settings from the local environment to the remote session, then how it ought to work is: 1. Client encodes the information in some standard form for transmission over the wire. 2. Server decodes the information. 3. Server applies the information to the session, as good as it can. 4. Server reports back to the client to which extent the locale settings could be applied. In the case that the server can't support your settings, to me there seems not to be much to negotiate about. One could provide a preference lists for things like languages and charsets and negotiate about that, but I'm not sure that really helps in practice. I would expect the applications on the server side to have verying levels of localization, which the ssh server won't have much control or knowledge about. So if you have a preference lists, what you should do is to propagate that list to the applications; negotiating with the server seems pointless. Anyway, I think the channel request should be specified so that it is independent of the negotiation/locale-query mechanism. > Which of these I-Ds, if any, should be SECSH WG work items? The channel request, and the global request (if one really is needed) would fit here, I guess. Personally, I'd encourage you to start with a "locale-req@sun.com", share the spec informally with other implementors who are interested, and take it to the wg for standardization when there's some more experience with it. Or perhaps you've done that already? I think the handling of "keyboard-interactive" in the wg was somewhat unfortate; there's a draft and one early implementation. At the time other implementors read the spec carefully, the installed base is already large enough that it is a serious argument against all changes, improvements and bug-fixes of the spec. The effect is that much of the implementation experience can't easily be taken into account. > Which WG, if any, is the most appropriate home for the more generic of > these items? No idea, I don't know very much about localization. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 18 05:24:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01099 for ; Mon, 18 Oct 2004 05:24:01 -0400 (EDT) Received: (qmail 1583 invoked by uid 605); 18 Oct 2004 09:23:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1550 invoked from network); 18 Oct 2004 09:23:36 -0000 Received: from unknown (HELO yahoo.com) (211.209.133.250) by mail.netbsd.org with SMTP; 18 Oct 2004 09:23:36 -0000 Message-ID: From: "Quincy B. Odom" To: ietf-ssh@NetBSD.org Subject: designer replicas Date: Mon, 18 Oct 2004 09:19:41 +0000 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Genuine Replicas Watches - http://xwd.metk.com/replica/sales/ We have the following brands available in our wide selection as well: Rolex Carrier Bvlgari Frank Muller Harry Winston Chopard Patek Philippe Vacheron Constantin Breguet A.lange & Sohne Glashute Original Audemars Piguet Roger Dubuis Blancpain Jaeger-lecoultre IWC Zenith Officine Panerai Alain Silberstein Chronoswiss Breitling Omega Tag Heuer Ikepod Eberhard Tudor Sinn Visit: - http://mch.metk.com/replica/sales/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 18 05:48:39 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02269 for ; Mon, 18 Oct 2004 05:48:39 -0400 (EDT) Received: (qmail 18507 invoked by uid 605); 18 Oct 2004 09:48:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18497 invoked from network); 18 Oct 2004 09:48:37 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 18 Oct 2004 09:48:37 -0000 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 i9I9mas3012354 for ; Mon, 18 Oct 2004 02:48:36 -0700 (PDT) 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 i9I9mZJh009515 for ; Mon, 18 Oct 2004 03:48:35 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9I9mLD1005459; Mon, 18 Oct 2004 04:48:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9I9mKHi005458; Mon, 18 Oct 2004 04:48:20 -0500 (CDT) Date: Mon, 18 Oct 2004 04:48:20 -0500 From: Nicolas Williams To: Niels =?unknown-8bit?Q?M=F6ller?= Cc: ietf-ssh@NetBSD.org Subject: Re: Locale negotiation Message-ID: <20041018094820.GE19141@binky.central.sun.com> References: <20041015234644.GP19142@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Oct 16, 2004 at 01:17:03PM +0200, Niels M?ller wrote: > Nicolas Williams writes: > > > My current plan is to define RFC3066-like namespaces of locale > > categories and codesets, define an abstract description of locales, > > roughly matching the POSIX locale concept, > > I'm not very familiar with these issues, but standardized naming of > locales and locale properties seems somewhat out of scope for the > secsh wg. I think so too, but this may be the first WG where some of these issues come up. > > and, finally, two extensions to SSHv2: > > > > - a global request for locale negotiation > > - a channel request for setting the locales for the various categories > > for a given channel > > A channel request makes sense, and if the naming issues are solved, I > hope it should be fairly simple. I think so too. The channel request should be very simple: a request to set some locale category (e.g., LC_TIME) to a given locale. Quite similar to what we may do with environment variables. > I don't know how the negotiation is supposed to work, if you want to > transfer the settings from the local environment to the remote > session, then how it ought to work is: I see two aproaches: - a global request through which the client may list the locales available on the server - a global request through which the client may ask the server for the locales that match a given specification (e.g., "tell me what locales are available that best match this list of RFC3066 language tags and this list of codesets" [I think we can ignore "modifiers"]) The former can be a subset of the latter, but it's much simpler to implement, even if it may be very chatty (I've seen Solaris systems with more than 200 locales available). > In the case that the server can't support your settings, to me there > seems not to be much to negotiate about. Oh, but there is. I might want a french locale with ISO8859-1 as the codeset but might settle for spanish and/or UTF-8. > One could provide a preference lists for things like languages and > charsets and negotiate about that, but I'm not sure that really helps > in practice. I would expect the applications on the server side to > have verying levels of localization, which the ssh server won't have > much control or knowledge about. It helps multi-lingual users. > So if you have a preference lists, what you should do is to propagate > that list to the applications; negotiating with the server seems > pointless. > > Anyway, I think the channel request should be specified so that it is > independent of the negotiation/locale-query mechanism. Yes, this was my thinking also. > > Which of these I-Ds, if any, should be SECSH WG work items? > > The channel request, and the global request (if one really is needed) > would fit here, I guess. > > Personally, I'd encourage you to start with a "locale-req@sun.com", > share the spec informally with other implementors who are interested, > and take it to the wg for standardization when there's some more > experience with it. Or perhaps you've done that already? I have not written or published such a draft yet. > I think the handling of "keyboard-interactive" in the wg was somewhat > unfortate; there's a draft and one early implementation. At the time > other implementors read the spec carefully, the installed base is > already large enough that it is a serious argument against all > changes, improvements and bug-fixes of the spec. The effect is that > much of the implementation experience can't easily be taken into > account. Point taken. I'm concerned that while language negotiation (through use of RFC3066 language tags) and codeset for use on the wire in Internet protocols (UTF-8) are fairly well-covered matters at the IETF, localization is less well covered, thus my post -- there may be issues here that deserve consideration outside SECSH. > > Which WG, if any, is the most appropriate home for the more generic of > > these items? > > No idea, I don't know very much about localization. Thanks! Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 22 23:23:09 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07402 for ; Fri, 22 Oct 2004 23:23:08 -0400 (EDT) Received: (qmail 10277 invoked by uid 605); 23 Oct 2004 03:23:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10268 invoked from network); 23 Oct 2004 03:22:59 -0000 Received: from valiant.concentric.net (HELO valiant.cnchost.com) (207.155.252.9) by mail.netbsd.org with SMTP; 23 Oct 2004 03:22:59 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id WAA24035; Fri, 22 Oct 2004 22:01:44 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Joseph Galbraith'" Cc: Subject: SFTP v6? Date: Sat, 23 Oct 2004 04:00:58 +0200 Message-ID: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hello Joseph, any information on when the SFTP v6 draft will be available? I will be starting implementation of a new module soon and my design is pending availability of the SFTP v6 specification. What is the current progress? When can the v6 draft be anticipated? Thanks! denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 25 16:02:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29076 for ; Mon, 25 Oct 2004 16:02:27 -0400 (EDT) Received: (qmail 12280 invoked by uid 605); 25 Oct 2004 20:02:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12271 invoked from network); 25 Oct 2004 20:02:22 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 25 Oct 2004 20:02:22 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6777278; Mon, 25 Oct 2004 13:02:20 -0600 Message-ID: <417D4DBC.4030606@vandyke.com> Date: Mon, 25 Oct 2004 13:02:20 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> In-Reply-To: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I made the deadline (sent to IETF at 3:00 AM this morning my time.) I put a big ** DO NOT IMPLEMENT ** in it though. My plan is to spend some time @ IETF and to publish a revision on the monday after we meet. Here are the changes (a rough list anyway): - Added NOFOLLOW option. - Made TEXT_HINT an attrib of it's own. Servers that 'know' might include this information as part of the directory read; if the server is going to have to do lots of work to figure it out, it should wait for a stat request expressing interest in the data. - Added 'filename-charset' and 'filename-translation-control' extensions (which still need some polishing in the language.) Also added the ability for the server to set an attrib-bits flag if the filename translation to UTF-8 failed, and to include the untranslated name in the attributes. - Add 'versions' extension to allow server to express non-contigous set of supported versions to client, and 'version' extension from client-to-server for server to pick one. (Because the client to server request isn't allowed to fail w/o closing the channel, it doesn't require a round trip. The client can fire it and move on without waiting.) - Added link-count attribute and mime-type attribute. - Added space available extension. - Added DIR_NOT_EMPTY, NOT_A_DIRECTORY, INVALID_FILENAME and LINK_LOOP error codes. Please, everyone, look at the list of error codes and suggest errors codes that we should have but aren't there. If something can go wrong on your OS and we can't represent it, now is the time to have a dialog about it. So... draft should appear shortly, and we WILL HAVE another draft on Monday after the IETF meets. (I'll be available for anyone interested in helping with edits or chatting about the draft from Monday evening through Tuesday.) Thanks, Joseph denis bider wrote: > Hello Joseph, > > any information on when the SFTP v6 draft will be available? > > I will be starting implementation of a new module soon and my design is > pending availability of the SFTP v6 specification. > > What is the current progress? When can the v6 draft be anticipated? > > Thanks! > > denis > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 25 19:22:51 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13448 for ; Mon, 25 Oct 2004 19:22:51 -0400 (EDT) Received: (qmail 27912 invoked by uid 605); 25 Oct 2004 23:22:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27894 invoked from network); 25 Oct 2004 23:22:47 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 25 Oct 2004 23:22:47 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2004 16:33:53 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9PNLwYJ007566 for ; Mon, 25 Oct 2004 16:22:04 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA07315 for ; Mon, 25 Oct 2004 16:22:39 -0700 (PDT) Date: Mon, 25 Oct 2004 16:22:39 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: IDs Submitted Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, The IDs for the core drafts have been submitted to the ID Editor. I expect it will take a few days before they get into the repository. I've posted them here: http://www.employees.org/~lonvick/secsh-wg/2004-oct-24/ This directory contains the IDs along with the xml and the diffs (using htmlwdiff) from the prior versions. Some notes: - The Authors (Tatu Ylonen for [ARCH], [CONNECT], [TRANS] and [USERAUTH], and Sami Lehtinen for [NUMBERS]) expressed a concern about the new boilerplates required for 3667/3668 compliance. The IESG is investigating that. Their names are not listed as Authors in this set of IDs until that is resolved. - The discussion of diffie-hellman-group14-sha1 has been noted in the appropriate places with an "Editor's Note". Let's talk about that in DC. - I separated the information in [NUMBERS] to show the registry, the current allocations, and the method(s) for future allocations. As such, the diff file shows a lot of red and green. As always, comments are welcome and suggested text is especially appreciated. :) Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 26 12:38:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21142 for ; Tue, 26 Oct 2004 12:38:37 -0400 (EDT) Received: (qmail 3054 invoked by uid 605); 26 Oct 2004 16:38:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3044 invoked from network); 26 Oct 2004 16:38:31 -0000 Received: from pix-fw.wan.aol.com (HELO wicked.office.aol.com) (152.163.190.1) by mail.netbsd.org with SMTP; 26 Oct 2004 16:38:31 -0000 Received: from [10.2.178.29] (wicked.office.aol.com [10.2.178.29]) by wicked.office.aol.com (8.12.11/8.12.11) with ESMTP id i9QFVlo4016433 for ; Tue, 26 Oct 2004 11:31:47 -0400 Subject: future SFTP version question From: jason bailey To: ietf-ssh@NetBSD.org In-Reply-To: <417D4DBC.4030606@vandyke.com> References: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> <417D4DBC.4030606@vandyke.com> Content-Type: text/plain Message-Id: <1098804707.16258.9.camel@wicked.office.aol.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 26 Oct 2004 11:31:47 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Would it be within scope to suggest that a future version of the SFTP server provide a signed receipt of the file transfer(on request)? This feature, would do much to alleviate a lot of our issues with secure file transfers. thanks -Jason From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 02:31:10 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07948 for ; Wed, 27 Oct 2004 02:31:10 -0400 (EDT) Received: (qmail 10705 invoked by uid 605); 27 Oct 2004 06:31:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10696 invoked from network); 27 Oct 2004 06:31:04 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 27 Oct 2004 06:31:04 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 0F5A34343F; Wed, 27 Oct 2004 08:01:26 +0200 (CEST) Message-ID: <417F3D22.1020905@siliconcircus.com> Date: Wed, 27 Oct 2004 08:16:02 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jason bailey Cc: ietf-ssh@NetBSD.org Subject: Re: future SFTP version question References: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> <417D4DBC.4030606@vandyke.com> <1098804707.16258.9.camel@wicked.office.aol.com> In-Reply-To: <1098804707.16258.9.camel@wicked.office.aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, jason bailey wrote: > Would it be within scope to suggest that a future version of the SFTP > server provide a signed receipt of the file transfer(on request)? > > This feature, would do much to alleviate a lot of our issues with secure > file transfers. I'm not in a position to answer your question wrt. scope, but I'm curious as to what exactly the signature would signify? That the server has definitely received the file at a given time? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 08:10:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28438 for ; Wed, 27 Oct 2004 08:10:01 -0400 (EDT) Received: (qmail 12839 invoked by uid 605); 27 Oct 2004 12:09:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12830 invoked from network); 27 Oct 2004 12:09:51 -0000 Received: from pix-fw.wan.aol.com (HELO wicked.office.aol.com) (152.163.190.1) by mail.netbsd.org with SMTP; 27 Oct 2004 12:09:51 -0000 Received: from [10.2.178.29] (wicked.office.aol.com [10.2.178.29]) by wicked.office.aol.com (8.12.11/8.12.11) with ESMTP id i9RC9e6N000495; Wed, 27 Oct 2004 08:09:40 -0400 Subject: Re: future SFTP version question From: jason bailey To: Jon Bright Cc: ietf-ssh@NetBSD.org In-Reply-To: <417F3D22.1020905@siliconcircus.com> References: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> <417D4DBC.4030606@vandyke.com> <1098804707.16258.9.camel@wicked.office.aol.com> <417F3D22.1020905@siliconcircus.com> Content-Type: text/plain Message-Id: <1098878980.32562.31.camel@wicked.office.aol.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 27 Oct 2004 08:09:40 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Exactly. A receipt provides proof that a given file was delivered at a specific time. Receipts usually contains information like file name, a fingerprint(hash), and a time stamp which is then signed by the servers private key. It's part of a non-repudiation process. To give an example. I deal with the transfer of data from my companies production network to a variety of third party organizations. For the majority of file transfers SFTP fits my needs. However there are occasions where the data is sensitive enough, or we have some sort of time based contractual obligation, where it is necessary for us to get a receipt of transfer. Right now my options are to go with some heavy weight B2B protocol which requires a team of engineers and an architect to get set up properly. Or implement our own solution, which inevitably results in placing some form of server (of our devising) on another companies network. This tends to make their network people very antsy. If I could get a receipt capability into a standard like SFTP. It would allow me promote SFTP over all the other options. It would make my management happy, and would make my company dealings with other companies a lot smoother. Jason On Wed, 2004-10-27 at 02:16, Jon Bright wrote: > Hi, > > jason bailey wrote: > > Would it be within scope to suggest that a future version of the SFTP > > server provide a signed receipt of the file transfer(on request)? > > > > This feature, would do much to alleviate a lot of our issues with secure > > file transfers. > > I'm not in a position to answer your question wrt. scope, but I'm > curious as to what exactly the signature would signify? That the server > has definitely received the file at a given time? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 10:18:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06670 for ; Wed, 27 Oct 2004 10:18:32 -0400 (EDT) Received: (qmail 27428 invoked by uid 605); 27 Oct 2004 14:18:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27419 invoked from network); 27 Oct 2004 14:18:29 -0000 Received: from thunderer.concentric.net (HELO thunderer.cnchost.com) (207.155.252.72) by mail.netbsd.org with SMTP; 27 Oct 2004 14:18:29 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by thunderer.cnchost.com id JAA19475; Wed, 27 Oct 2004 09:54:55 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'jason bailey'" , "'Jon Bright'" Cc: Subject: RE: future SFTP version question Date: Wed, 27 Oct 2004 15:54:03 +0200 Message-ID: <000001c4bc2c$6cdaad70$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1098878980.32562.31.camel@wicked.office.aol.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Technically speaking, an extension to the SFTP protocol could be implemented in which the server would testify (with a digital signature) that a file of a certain name, attributes and contents existed on the server at a certain time. Whether or not this file was uploaded entirely by a certain user would be a more complex challenge because SFTP has no such concept as "uploading" or "downloading" a whole file. You have random access and you can pretty much scratch anywhere you want in the remote filesystem. An extension that would produce a certificate of a file's existence at a certain time would be fairly straightforward. Provide an extension request type for requesting the certificate, and define the contents of a receipt. If providing a certificate of the file's existence on the server is insufficient, and you must really provide a receipt which includes information about the act of uploading, this could be done, too. For example, a file for which you require an upload receipt must be opened with a certain flag or set of flags which signal that you're going to do receipted-uploading. When you open the file, you are allowed to append to the file only (like uploading in TEXT mode). When you close it, the server sends a RECEIPT message rather than STATUS. The format of the RECEIPT message is what needs to be defined. Whether or not this is something for a separate Internet-Draft (documenting the SFTP extension) or something that can be added to SFTP itself as an optional feature is, I guess, up for the workgroup or the SFTP draft editor to decide. In my view, the first solution type (certificate of file's existence) would be more apt for a separate draft because it is fairly orthogonal to existing functionality. The second solution type (certificate of the upload act with special flags for opening the file) might be better documented in SFTP itself because of the flag's definition. If the 2nd solution (upload receipt) is required, a question to answer is: what if the user needs to upload an extremely large file and the connection breaks? Should the "upload receipt" process allow for a file to be resumed? If so, how do you know that the file being resumed is one that was actually uploaded in a previous session by the same user, and that it wasn't lying there on the server belonging to someone else? denis > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of jason bailey > Sent: Wednesday, October 27, 2004 14:10 > To: Jon Bright > Cc: ietf-ssh@NetBSD.org > Subject: Re: future SFTP version question > > > Exactly. > > A receipt provides proof that a given file was delivered at a > specific time. > > Receipts usually contains information like file name, a > fingerprint(hash), and a time stamp which is then signed by > the servers private key. It's part of a non-repudiation process. > > To give an example. I deal with the transfer of data from my > companies production network to a variety of third party > organizations. For the majority of file transfers SFTP fits > my needs. However there are occasions where the data is > sensitive enough, or we have some sort of time based > contractual obligation, where it is necessary for us to get a > receipt of transfer. > > Right now my options are to go with some heavy weight B2B > protocol which requires a team of engineers and an architect > to get set up properly. Or implement our own solution, which > inevitably results in placing some form of server (of our > devising) on another companies network. This tends to make > their network people very antsy. > > If I could get a receipt capability into a standard like > SFTP. It would allow me promote SFTP over all the other > options. It would make my management happy, and would make my > company dealings with other companies a lot smoother. > > Jason > > > On Wed, 2004-10-27 at 02:16, Jon Bright wrote: > > Hi, > > > > jason bailey wrote: > > > Would it be within scope to suggest that a future version of the > > > SFTP server provide a signed receipt of the file transfer(on > > > request)? > > > > > > This feature, would do much to alleviate a lot of our issues with > > > secure file transfers. > > > > I'm not in a position to answer your question wrt. scope, but I'm > > curious as to what exactly the signature would signify? > That the server > > has definitely received the file at a given time? > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 10:48:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10532 for ; Wed, 27 Oct 2004 10:48:29 -0400 (EDT) Received: (qmail 19597 invoked by uid 605); 27 Oct 2004 14:48:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19587 invoked from network); 27 Oct 2004 14:48:28 -0000 Received: from groucho.itss.auckland.ac.nz (HELO smtpa.itss.auckland.ac.nz) (130.216.190.11) by mail.netbsd.org with SMTP; 27 Oct 2004 14:48:27 -0000 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id D03F534946; Thu, 28 Oct 2004 03:24:21 +1300 (NZDT) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20005-10; Thu, 28 Oct 2004 03:24:21 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 229C534942; Thu, 28 Oct 2004 03:24:18 +1300 (NZDT) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3B3F637746; Thu, 28 Oct 2004 03:24:18 +1300 (NZDT) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CMoiy-0001p7-00; Thu, 28 Oct 2004 03:24:28 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@denisbider.com, jbailey@aol.net, jon@siliconcircus.com Subject: RE: future SFTP version question Cc: ietf-ssh@NetBSD.org In-Reply-To: <000001c4bc2c$6cdaad70$6402a8c0@nucleus> Message-Id: Date: Thu, 28 Oct 2004 03:24:28 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list "denis bider" writes: >Whether or not this is something for a separate Internet-Draft (documenting >the SFTP extension) or something that can be added to SFTP itself as an >optional feature is, I guess, up for the workgroup or the SFTP draft editor >to decide. If you're going to produce signed receipts as proof-of-delivery, you're well into S/MIME / PGP territory. This seems to be going way beyond what SSH should be doing (depending on how far you want to take this you'd need to reinvent significant chunks of PGP or S/MIME), it'd be better to just define a signed content type for one of those formats and use that. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 11:02:24 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11790 for ; Wed, 27 Oct 2004 11:02:24 -0400 (EDT) Received: (qmail 26962 invoked by uid 605); 27 Oct 2004 15:02:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26953 invoked from network); 27 Oct 2004 15:02:23 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 27 Oct 2004 15:02:23 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id CEFBE43433; Wed, 27 Oct 2004 17:02:20 +0200 (CEST) Message-ID: <417FBBD7.7040202@siliconcircus.com> Date: Wed, 27 Oct 2004 17:16:39 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: ietf-ssh@denisbider.com, jbailey@aol.net, ietf-ssh@NetBSD.org Subject: Re: future SFTP version question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > > If you're going to produce signed receipts as proof-of-delivery, you're well > into S/MIME / PGP territory. This seems to be going way beyond what SSH > should be doing (depending on how far you want to take this you'd need to > reinvent significant chunks of PGP or S/MIME), it'd be better to just define a > signed content type for one of those formats and use that. I agree that the spec for the signature itself belongs elsewhere - but I can see an argument for building the ability to ask the server to produce such a signature into SFTP. The signature standard need only be incorporated by reference. As I read it, Jason's only requirement is for the server to sign to say "file X (hash Y) was on this server at time T". This could use signature schemes already in existence, providing that SFTP were able to ask the server to produce the signature and transfer the produced signature back to the client. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 12:51:17 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21581 for ; Wed, 27 Oct 2004 12:51:16 -0400 (EDT) Received: (qmail 2351 invoked by uid 605); 27 Oct 2004 16:51:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2342 invoked from network); 27 Oct 2004 16:51:13 -0000 Received: from pix-fw.wan.aol.com (HELO wicked.office.aol.com) (152.163.190.1) by mail.netbsd.org with SMTP; 27 Oct 2004 16:51:13 -0000 Received: from [10.2.178.29] (wicked.office.aol.com [10.2.178.29]) by wicked.office.aol.com (8.12.11/8.12.11) with ESMTP id i9RGp7Qa003843 for ; Wed, 27 Oct 2004 12:51:09 -0400 Subject: RE: future SFTP version question From: jason bailey Cc: ietf-ssh@NetBSD.org In-Reply-To: <000001c4bc2c$6cdaad70$6402a8c0@nucleus> References: <000001c4bc2c$6cdaad70$6402a8c0@nucleus> Content-Type: text/plain Message-Id: <1098895866.3698.0.camel@wicked.office.aol.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 27 Oct 2004 12:51:07 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit You've made some very good points. Initially I had considered a flag for the transfer which would result in a returned RECEIPT rather then a STATUS. However, given your observations,and reviewing what I am looking for I see no problem with it being an extension to the protocol. I'm not certain that it is, as you put it, orthogonal to the current functionality. There already appears to be an existing extension to support a hashing of a file to verify the contents. In my mind I see this as very similar. We are merely verifying the contents and that it is on a particular server at a given time. Jason On Wed, 2004-10-27 at 09:54, denis bider wrote: > Technically speaking, an extension to the SFTP protocol could be implemented > in which the server would testify (with a digital signature) that a file of > a certain name, attributes and contents existed on the server at a certain > time. > > Whether or not this file was uploaded entirely by a certain user would be a > more complex challenge because SFTP has no such concept as "uploading" or > "downloading" a whole file. You have random access and you can pretty much > scratch anywhere you want in the remote filesystem. > > An extension that would produce a certificate of a file's existence at a > certain time would be fairly straightforward. Provide an extension request > type for requesting the certificate, and define the contents of a receipt. > > If providing a certificate of the file's existence on the server is > insufficient, and you must really provide a receipt which includes > information about the act of uploading, this could be done, too. For > example, a file for which you require an upload receipt must be opened with > a certain flag or set of flags which signal that you're going to do > receipted-uploading. When you open the file, you are allowed to append to > the file only (like uploading in TEXT mode). When you close it, the server > sends a RECEIPT message rather than STATUS. The format of the RECEIPT > message is what needs to be defined. > > Whether or not this is something for a separate Internet-Draft (documenting > the SFTP extension) or something that can be added to SFTP itself as an > optional feature is, I guess, up for the workgroup or the SFTP draft editor > to decide. In my view, the first solution type (certificate of file's > existence) would be more apt for a separate draft because it is fairly > orthogonal to existing functionality. The second solution type (certificate > of the upload act with special flags for opening the file) might be better > documented in SFTP itself because of the flag's definition. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 12:54:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22092 for ; Wed, 27 Oct 2004 12:54:11 -0400 (EDT) Received: (qmail 3922 invoked by uid 605); 27 Oct 2004 16:54:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3913 invoked from network); 27 Oct 2004 16:54:09 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 27 Oct 2004 16:54:09 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6802932; Wed, 27 Oct 2004 10:54:08 -0600 Message-ID: <417FD2B2.9070709@vandyke.com> Date: Wed, 27 Oct 2004 10:54:10 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jason bailey CC: ietf-ssh@NetBSD.org Subject: Re: future SFTP version question References: <000001c4bc2c$6cdaad70$6402a8c0@nucleus> <1098895866.3698.0.camel@wicked.office.aol.com> In-Reply-To: <1098895866.3698.0.camel@wicked.office.aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit This seems like a useful extension; I've got half of a proposal worked up... I just haven't quite managed to finish it yet. Hopefully I can post something to be shot down in a day or so. - Joseph (sftp draft editor) jason bailey wrote: > You've made some very good points. > > Initially I had considered a flag for the transfer which would result in > a returned RECEIPT rather then a STATUS. > > However, given your observations,and reviewing what I am looking for I > see no problem with it being an extension to the protocol. > > I'm not certain that it is, as you put it, orthogonal to the current > functionality. There already appears to be an existing extension to > support a hashing of a file to verify the contents. > > In my mind I see this as very similar. We are merely verifying the > contents and that it is on a particular server at a given time. > > Jason > > > On Wed, 2004-10-27 at 09:54, denis bider wrote: > >>Technically speaking, an extension to the SFTP protocol could be > > implemented > >>in which the server would testify (with a digital signature) that a > > file of > >>a certain name, attributes and contents existed on the server at a > > certain > >>time. >> >>Whether or not this file was uploaded entirely by a certain user would > > be a > >>more complex challenge because SFTP has no such concept as "uploading" > > or > >>"downloading" a whole file. You have random access and you can pretty > > much > >>scratch anywhere you want in the remote filesystem. >> >>An extension that would produce a certificate of a file's existence at > > a > >>certain time would be fairly straightforward. Provide an extension > > request > >>type for requesting the certificate, and define the contents of a > > receipt. > >>If providing a certificate of the file's existence on the server is >>insufficient, and you must really provide a receipt which includes >>information about the act of uploading, this could be done, too. For >>example, a file for which you require an upload receipt must be opened > > with > >>a certain flag or set of flags which signal that you're going to do >>receipted-uploading. When you open the file, you are allowed to append > > to > >>the file only (like uploading in TEXT mode). When you close it, the > > server > >>sends a RECEIPT message rather than STATUS. The format of the RECEIPT >>message is what needs to be defined. >> >>Whether or not this is something for a separate Internet-Draft > > (documenting > >>the SFTP extension) or something that can be added to SFTP itself as > > an > >>optional feature is, I guess, up for the workgroup or the SFTP draft > > editor > >>to decide. In my view, the first solution type (certificate of file's >>existence) would be more apt for a separate draft because it is fairly >>orthogonal to existing functionality. The second solution type > > (certificate > >>of the upload act with special flags for opening the file) might be > > better > >>documented in SFTP itself because of the flag's definition. > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 27 21:05:39 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05034 for ; Wed, 27 Oct 2004 21:05:38 -0400 (EDT) Received: (qmail 22860 invoked by uid 605); 28 Oct 2004 01:05:34 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20041028010534.22857.qmail@mail.netbsd.org> Received: (qmail 22851 invoked from network); 28 Oct 2004 01:05:33 -0000 Received: from 201009086197.user.veloxzone.com.br (HELO mail.com) (201.9.86.197) by mail.netbsd.org with SMTP; 28 Oct 2004 01:05:32 -0000 From: "Juliana Castro" To: Subject: LISTAS DE E-MAILS Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 27 Oct 2004 22:05:24 -0300 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Quer conseguir as melhores listas de e-mails do Brasil? Visite agora: http://www.divulgamail.mx.gs Mala direta por e-mail, E-mails de pessoas e empresas de São Paulo e de quase todos estados do Brasil. Listas emails, e-mail regiões, propaganda email, enviar email anônimo, envio mala direta, estados, campanha, cidade, envio, publicidade e-mails, São Paulo... Visite agora: http://www.divulgamail.mx.gs Divulgação da Home Page em Sites de Busca, Divulgação Sites Como divulgar home pages como divulgar sites como divulgar meu site, dicas de divulgação de sites. Otimização e posicionamento no Google. campanhas e-mail, São Paulo, lista e-mail, programas e-mails, e-mails estado, publicidade emails, marketing digital, cidade, divulgar, lista email, emails estados, propaganda digital e-mails, e-mail por regiões, e-mails por cidades, email cidades, São Paulo, campanha e-mail, e-mail estado, listas email, lista emails, propaganda por e-mails, mala direta email, publicidade, cidades, marketing emails, cidade, email por regiões, envio propaganda, listas e-mails. Visite agora: http://www.divulgamail.mx.gs From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 03:27:20 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13650 for ; Thu, 28 Oct 2004 03:27:19 -0400 (EDT) Received: (qmail 25182 invoked by uid 605); 28 Oct 2004 07:27:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25166 invoked from network); 28 Oct 2004 07:27:16 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 28 Oct 2004 07:27:16 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id CC892214A1A; Thu, 28 Oct 2004 09:22:37 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id B41ED218C8E; Thu, 28 Oct 2004 09:22:33 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9S7MXih015462; Thu, 28 Oct 2004 09:22:33 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9S7MQJv015459; Thu, 28 Oct 2004 09:22:26 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-ssh@denisbider.com, jbailey@aol.net, jon@siliconcircus.com, ietf-ssh@NetBSD.org Subject: Re: future SFTP version question References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 28 Oct 2004 09:22:26 +0200 In-Reply-To: Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > "denis bider" writes: > > >Whether or not this is something for a separate Internet-Draft (documenting > >the SFTP extension) or something that can be added to SFTP itself as an > >optional feature is, I guess, up for the workgroup or the SFTP draft editor > >to decide. > > If you're going to produce signed receipts as proof-of-delivery, you're well > into S/MIME / PGP territory. This seems to be going way beyond what SSH > should be doing [...] I agree this seems to be beyond what standard sftp is supposed to do. And I also don't see why sftp extensions are crucial for supporting the given use case. One could use plain sftp (or *any* file transfer mechanism, for that matter) and the following convention: * Client uploads the file "foo" into a particular directory or using some particular naming scheme. * When upload is complete (sftp close), the server processes the file using the signature mechanisms of its choice (pgp, s/mime, whatever), and writes a receipt as a new file "foo.receipt". * The client downloads "foo.receipt". Everyone is happy. Adding extensions to sftp to do this have the potential advantage of letting us standardize it, but I seriously doubt it's worth the effort; it seems too obscure and specialized. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 03:44:19 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15517 for ; Thu, 28 Oct 2004 03:44:19 -0400 (EDT) Received: (qmail 8416 invoked by uid 605); 28 Oct 2004 07:44:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8406 invoked from network); 28 Oct 2004 07:44:16 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 28 Oct 2004 07:44:16 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 786BE21A4FD; Thu, 28 Oct 2004 09:42:25 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 829C521A4A3; Thu, 28 Oct 2004 09:42:21 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9S7gLih015833; Thu, 28 Oct 2004 09:42:21 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9S7gGqj015830; Thu, 28 Oct 2004 09:42:16 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> <417D4DBC.4030606@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 28 Oct 2004 09:41:56 +0200 In-Reply-To: <417D4DBC.4030606@vandyke.com> Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > - Add 'versions' extension to allow server to express non-contigous > set of supported versions to client, and 'version' extension > from client-to-server for server to pick one. As I said before, I really don't think this is the right way to go. I can accept a "fancy version negotiation"-extension only if it is specified in such a way that implementations that don't care about disjunct version intervals (e.g. the common case of an implementation supporting only version x, or supporting only version x and version x+1) don't need to implement or otherwise care about the extension. I view the fancy-version-negotioation thing only as a temporary kludge needed for the unfortunate version 3 -> version 6+ upgrade. It will be totally unneeded bloat and uglyness once this is over and the protocol specification stabilizes. (I don't see any value whatsoever in fancy version negotiation in the longer run. Simply advertising the highest supported version number provides for adequate backwards compatibility for everybody else's protocols, and I think it really ought to work also for sftp). And I don't think it is appropriate at all to consider things like round-trip optimization for a temoprary kludge. Just solve the problem at hand in a simple a way as possible. Both the problem and the solution will be forgotten a few years from now. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 05:28:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23139 for ; Thu, 28 Oct 2004 05:28:07 -0400 (EDT) Received: (qmail 9321 invoked by uid 605); 28 Oct 2004 09:28:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8247 invoked from network); 28 Oct 2004 09:27:46 -0000 Received: from wellington.concentric.net (HELO wellington.cnchost.com) (207.155.252.14) by mail.netbsd.org with SMTP; 28 Oct 2004 09:27:46 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by wellington.cnchost.com id EAA14339; Thu, 28 Oct 2004 04:43:33 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: , "'Joseph Galbraith'" Cc: Subject: RE: SFTP v6? Date: Thu, 28 Oct 2004 10:42:41 +0200 Message-ID: <004601c4bcca$1752e220$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Niels, if the version extension scheme we're talking about is what I proposed, = it does seem to solve the problem at hand in the simplest complete way. If in the future the 3->6 problem indeed becomes forgotten and obsolete, clients will simply send "23" as their version (or whatever the highest version exists at that time) and will bomb out if the server responds = with anything lower than "17". Fine. If a client is concerned about the 3-6 problem though and wants to avoid = the chance that the server might reply to 6 with 4 or 5, I believe my = proposal is simple and complete. If you don't care to implement it, it won't burden your client implementation at all - you can continue to send the highest version you support and that will work just as fine. On the server side, this method will burden you only if you wish to = offer your highest version to clients which support non-contiguous version = ranges. But do you not wish your server to be well interoperable with such = clients? Is it not legitimate for clients to have a non-contiguous version requirement? Note that the solution has almost 0 impact on sessions where the client = is not one that supports non-contiguous version ranges. I don't know why you label it as "fancy", because fancy is not what it = is. It just solves the problem with the smallest possible negative impact. = The only alternative with even less burden is to ignore the problem exists = in the first place. I, for one, see myself implementing a client with non-contiguous version support. And I would appreciate if the new servers allowed my client to = do so. > -----Original Message----- > From: nisse@lysator.liu.se [mailto:nisse@lysator.liu.se]=20 > Sent: Thursday, October 28, 2004 09:42 > To: Joseph Galbraith > Cc: denis bider; ietf-ssh@NetBSD.org > Subject: Re: SFTP v6? >=20 >=20 > Joseph Galbraith writes: >=20 > > - Add 'versions' extension to allow server to express non-contigous > > set of supported versions to client, and 'version' extension > > from client-to-server for server to pick one. >=20 > As I said before, I really don't think this is the right way to go. >=20 > I can accept a "fancy version negotiation"-extension only if=20 > it is specified in such a way that implementations that don't=20 > care about disjunct version intervals (e.g. the common case=20 > of an implementation supporting only version x, or supporting=20 > only version x and version > x+1) don't need to implement or otherwise care about the extension. >=20 > I view the fancy-version-negotioation thing only as a=20 > temporary kludge needed for the unfortunate version 3 ->=20 > version 6+ upgrade. It will be totally unneeded bloat and=20 > uglyness once this is over and the protocol specification=20 > stabilizes. (I don't see any value whatsoever in fancy=20 > version negotiation in the longer run. Simply advertising the=20 > highest supported version number provides for adequate=20 > backwards compatibility for everybody else's protocols, and I=20 > think it really ought to work also for sftp). >=20 > And I don't think it is appropriate at all to consider things=20 > like round-trip optimization for a temoprary kludge. Just=20 > solve the problem at hand in a simple a way as possible. Both=20 > the problem and the solution will be forgotten a few years from now. >=20 > Regards, > /Niels >=20 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 11:55:26 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04873 for ; Thu, 28 Oct 2004 11:55:24 -0400 (EDT) Received: (qmail 16528 invoked by uid 605); 28 Oct 2004 15:55:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16492 invoked from network); 28 Oct 2004 15:55:15 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2004 15:55:15 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22912; Thu, 28 Oct 2004 11:09:04 -0400 (EDT) Message-Id: <200410281509.LAA22912@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-06.txt Date: Thu, 28 Oct 2004 11:09:04 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH File Transfer Protocol Author(s) : J. Galbraith:w Filename : draft-ietf-secsh-filexfer-06.txt Pages : 57 Date : 2004-10-27 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-06.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-06.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-06.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: <2004-10-28110307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110307.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 11:55:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04900 for ; Thu, 28 Oct 2004 11:55:31 -0400 (EDT) Received: (qmail 16719 invoked by uid 605); 28 Oct 2004 15:55:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16503 invoked from network); 28 Oct 2004 15:55:17 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2004 15:55:17 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22761; Thu, 28 Oct 2004 11:08:23 -0400 (EDT) Message-Id: <200410281508.LAA22761@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-20.txt Date: Thu, 28 Oct 2004 11:08:22 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-connect-20.txt Pages : 23 Date : 2004-10-27 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-20.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-connect-20.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-connect-20.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: <2004-10-28110300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110300.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 11:55:41 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04956 for ; Thu, 28 Oct 2004 11:55:41 -0400 (EDT) Received: (qmail 16774 invoked by uid 605); 28 Oct 2004 15:55:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16518 invoked from network); 28 Oct 2004 15:55:18 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2004 15:55:18 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22582; Thu, 28 Oct 2004 11:07:17 -0400 (EDT) Message-Id: <200410281507.LAA22582@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-22.txt Date: Thu, 28 Oct 2004 11:07:17 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen, C. Lonvick Filename : draft-ietf-secsh-userauth-22.txt Pages : 16 Date : 2004-10-27 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-22.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-userauth-22.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-userauth-22.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: <2004-10-28110255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110255.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 11:55:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05007 for ; Thu, 28 Oct 2004 11:55:54 -0400 (EDT) Received: (qmail 16983 invoked by uid 605); 28 Oct 2004 15:55:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16718 invoked from network); 28 Oct 2004 15:55:23 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2004 15:55:23 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23159; Thu, 28 Oct 2004 11:09:49 -0400 (EDT) Message-Id: <200410281509.LAA23159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-17.txt Date: Thu, 28 Oct 2004 11:09:49 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : C. Lonvick Filename : draft-ietf-secsh-architecture-17.txt Pages : 30 Date : 2004-10-27 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-17.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-architecture-17.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-architecture-17.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: <2004-10-28110312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110312.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 11:56:54 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05274 for ; Thu, 28 Oct 2004 11:56:53 -0400 (EDT) Received: (qmail 18538 invoked by uid 605); 28 Oct 2004 15:56:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18507 invoked from network); 28 Oct 2004 15:56:49 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2004 15:56:48 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23277; Thu, 28 Oct 2004 11:10:21 -0400 (EDT) Message-Id: <200410281510.LAA23277@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-07.txt Date: Thu, 28 Oct 2004 11:10:21 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : C. Lonvick Filename : draft-ietf-secsh-assignednumbers-07.txt Pages : 18 Date : 2004-10-27 This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for the initialization of the IANA registries referenced in the documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-07.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-assignednumbers-07.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-assignednumbers-07.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: <2004-10-28110317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110317.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 11:57:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05330 for ; Thu, 28 Oct 2004 11:57:00 -0400 (EDT) Received: (qmail 18540 invoked by uid 605); 28 Oct 2004 15:56:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18517 invoked from network); 28 Oct 2004 15:56:50 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2004 15:56:49 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23411; Thu, 28 Oct 2004 11:10:59 -0400 (EDT) Message-Id: <200410281510.LAA23411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-19.txt Date: Thu, 28 Oct 2004 11:10:59 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-transport-19.txt Pages : 29 Date : 2004-10-27 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-19.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-transport-19.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-transport-19.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: <2004-10-28110323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110323.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 12:51:07 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16996 for ; Thu, 28 Oct 2004 12:51:06 -0400 (EDT) Received: (qmail 25273 invoked by uid 605); 28 Oct 2004 16:51:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25264 invoked from network); 28 Oct 2004 16:51:05 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 28 Oct 2004 16:51:04 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA13816; Thu, 28 Oct 2004 12:51:03 -0400 (EDT) From: der Mouse Message-Id: <200410281651.MAA13816@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. Date: Thu, 28 Oct 2004 12:33:22 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: New drafts In-Reply-To: <200410281507.LAA22582@ietf.org> References: <200410281507.LAA22582@ietf.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Good to see all the new drafts. In architecture-17, I see new text It should be noted that these names resemble [RFC0822] email addresses. This is purely coincidental and actually has nothing to do with [RFC0822]. RFC 822 is long obsolete; shouldn't that refer to 2822? (Similar remarks apply to assignednumbers-07 4.6.1.) I also see (commonly known as the Rogaway attack [ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work, s/,)/)/ surely? In assignednumbers-07, 4.2.3, what about reason codes from ffffffea through ffffffef? Similar remarks apply to 4.3.3 and 4.4.3. userauth-22 contains (in the description of password authentication) more character set issues, similar to those raised by the recent discussion of filenames. Built into this text is the assumption that a password is a sequence of characters; on most systems, it is actually a sequence of octets, with any conversion between them and characters left undefined. /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 21:46:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14467 for ; Thu, 28 Oct 2004 21:46:00 -0400 (EDT) Received: (qmail 27843 invoked by uid 605); 29 Oct 2004 01:45:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27830 invoked from network); 29 Oct 2004 01:45:46 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 29 Oct 2004 01:45:45 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa29979; 28 Oct 2004 19:45 EDT Date: Thu, 28 Oct 2004 19:45:23 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: New drafts Message-ID: <1104220000.1099007123@minbar.fac.cs.cmu.edu> In-Reply-To: <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/3.0.3 (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 Thursday, October 28, 2004 12:33:22 -0400 der Mouse wrote: > Good to see all the new drafts. > > In architecture-17, I see new text > > It should be noted that these names resemble [RFC0822] email > addresses. This is purely coincidental and actually has > nothing to do with [RFC0822]. > > RFC 822 is long obsolete; shouldn't that refer to 2822? (Similar > remarks apply to assignednumbers-07 4.6.1.) Actually, RFC822 is not "obsolete"; it is an Internet Standard. It is entirely appropriate to refer to "RFC822 addresses", especially in a context like this where the reference is informative. > I also see > > (commonly known as the Rogaway attack > [ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work, > > s/,)/)/ surely? And s/][/],[/ > userauth-22 contains (in the description of password authentication) > more character set issues, similar to those raised by the recent > discussion of filenames. Built into this text is the assumption that a > password is a sequence of characters; on most systems, it is actually a > sequence of octets, with any conversion between them and characters > left undefined. Sorry; that's just not true. It wasn't true of filenames and it's not true of passwords, either. Kerberos treats passwords as character strings. Windows treats passwords as character strings. SASL treats passwords as character strings. MacOS X treats passwords as character strings. In fact, if you look, you can probably find a number of situations in which various UNIX systems treat passwords as character strings and not octet strings. Consider xdm. Consider the behaviour of 'passwd' with a UTF-8 locale. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 21:50:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16580 for ; Thu, 28 Oct 2004 21:50:36 -0400 (EDT) Received: (qmail 1183 invoked by uid 605); 29 Oct 2004 01:50:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1174 invoked from network); 29 Oct 2004 01:50:33 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 29 Oct 2004 01:50:33 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2004 19:02:13 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T1oSQ0018673; Thu, 28 Oct 2004 18:50:28 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA01775; Thu, 28 Oct 2004 18:50:30 -0700 (PDT) Date: Thu, 28 Oct 2004 18:50:30 -0700 (PDT) From: Chris Lonvick To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: New drafts In-Reply-To: <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 28 Oct 2004, der Mouse wrote: > Good to see all the new drafts. Sorry for the delay. I'll pick up the pace. > > In architecture-17, I see new text > > It should be noted that these names resemble [RFC0822] email > addresses. This is purely coincidental and actually has > nothing to do with [RFC0822]. > > RFC 822 is long obsolete; shouldn't that refer to 2822? (Similar > remarks apply to assignednumbers-07 4.6.1.) I was going from the IESG comments and the brief discussion we had on the mailing list. Does anyone disagree that we should be referencing RFC 2822? > > I also see > > (commonly known as the Rogaway attack > [ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work, > > s/,)/)/ surely? I just put that in there to see who was reading the drafts. ;) ..just kidding. Good catch, I'll fix that. > > In assignednumbers-07, 4.2.3, what about reason codes from ffffffea > through ffffffef? Similar remarks apply to 4.3.3 and 4.4.3. My apologies for that. I was distracted by a side issue during the last few weeks and hadn't realized that I had not completed my edits for that issue. The ranges are inconsistent throughout the documents and I will correct that when the ID Editors start accepting new documents again. Just to summarize the discussion, I am planning on the following: ===== For SSH_MSG_CHANNEL_OPEN_FAILURE we will have 0x0000 0000 - 0xFDFF FFFF IETF CONSENSUS 0xFE00 0000 - 0xFEFF FFFF PRIVATE USE - channel-type specific 0xFF00 0000 - 0xFFFF FFFF PRIVATE USE - (experimental stuff) with accompanying notes about - The range starting with 0xFE should be used when localized names are used for opening a channel (e.g. SSH_MSG_CHANNEL_OPEN message with a 'channel type' of "secure-net-hearts@example.com"). Interoperability is assumed by a "gentleman's agreement" that IF you accept the localized channel open type THEN you will understand the failure 'reason code' values associated with that localized name. Also, the IANA assigned 'reason code' values are still valid even when opening a channel using a localized name. - No restrictions or suggestions for the range starting with 0xFF. No interoperability is expected for anything used here - it's for experimentation. ===== For SSH_MSG_DISCONNECT we will have 0x0000 0000 - 0xFDFF FFFF IETF CONSENSUS 0xFE00 0000 - 0xFFFF FFFF PRIVATE USE ===== For SSH_MSG_CHANNEL_EXTENDED_DATA we will have 0x0000 0000 - 0xFDFF FFFF IETF CONSENSUS 0xFE00 0000 - 0xFFFF FFFF PRIVATE USE ===== > > userauth-22 contains (in the description of password authentication) > more character set issues, similar to those raised by the recent > discussion of filenames. Was that the discussion with the subject line of "SFTP and unicode file names..."? I wasn't paying close attention to that. > Built into this text is the assumption that a > password is a sequence of characters; on most systems, it is actually a > sequence of octets, with any conversion between them and characters > left undefined. Is that this paragraph: Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the password and validates it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords. If so, would anyone care to propose text as to how it can address this issue? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 22:14:43 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22307 for ; Thu, 28 Oct 2004 22:14:43 -0400 (EDT) Received: (qmail 12571 invoked by uid 605); 29 Oct 2004 02:14:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12553 invoked from network); 29 Oct 2004 02:14:41 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 29 Oct 2004 02:14:41 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2004 19:26:21 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T2EZQ0001013; Thu, 28 Oct 2004 19:14:36 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA19968; Thu, 28 Oct 2004 19:14:38 -0700 (PDT) Date: Thu, 28 Oct 2004 19:14:38 -0700 (PDT) From: Chris Lonvick To: Jeffrey Hutzelman cc: ietf-ssh@NetBSD.org Subject: Re: New drafts In-Reply-To: <1104220000.1099007123@minbar.fac.cs.cmu.edu> Message-ID: References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> <1104220000.1099007123@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 28 Oct 2004, Jeffrey Hutzelman wrote: > > > On Thursday, October 28, 2004 12:33:22 -0400 der Mouse > wrote: > > > Good to see all the new drafts. > > > > In architecture-17, I see new text > > > > It should be noted that these names resemble [RFC0822] email > > addresses. This is purely coincidental and actually has > > nothing to do with [RFC0822]. > > > > RFC 822 is long obsolete; shouldn't that refer to 2822? (Similar > > remarks apply to assignednumbers-07 4.6.1.) > > Actually, RFC822 is not "obsolete"; it is an Internet Standard. > > It is entirely appropriate to refer to "RFC822 addresses", especially in a > context like this where the reference is informative. OK, I should'a looked before my prior response. STD-11 still points to RFC-822. However, RFC-822 has been "Obsoleted by RFC-2822" and "Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156". Nonetheless, it's usually more appropriate to go with a STD so I'll keep the reference pointing to RFC-822. > > > > I also see > > > > (commonly known as the Rogaway attack > > [ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work, > > > > s/,)/)/ surely? > > And s/][/],[/ I used White Out. > > > > userauth-22 contains (in the description of password authentication) > > more character set issues, similar to those raised by the recent > > discussion of filenames. Built into this text is the assumption that a > > password is a sequence of characters; on most systems, it is actually a > > sequence of octets, with any conversion between them and characters > > left undefined. > > Sorry; that's just not true. It wasn't true of filenames and it's not true > of passwords, either. > > Kerberos treats passwords as character strings. > Windows treats passwords as character strings. > SASL treats passwords as character strings. > MacOS X treats passwords as character strings. > In fact, if you look, you can probably find a number of situations in which > various UNIX systems treat passwords as character strings and not octet > strings. Consider xdm. Consider the behaviour of 'passwd' with a UTF-8 > locale. OK. No changes planned unless we get some consensus. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 28 23:08:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00553 for ; Thu, 28 Oct 2004 23:08:55 -0400 (EDT) Received: (qmail 11001 invoked by uid 605); 29 Oct 2004 03:08:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10985 invoked from network); 29 Oct 2004 03:08:52 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 29 Oct 2004 03:08:52 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA17645; Thu, 28 Oct 2004 23:08:51 -0400 (EDT) From: der Mouse Message-Id: <200410290308.XAA17645@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. Date: Thu, 28 Oct 2004 22:03:52 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New drafts In-Reply-To: <1104220000.1099007123@minbar.fac.cs.cmu.edu> References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> <1104220000.1099007123@minbar.fac.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit [Jeffrey Hutzelman , replying to me] >> RFC 822 is long obsolete; shouldn't that refer to 2822? > Actually, RFC822 is not "obsolete"; it is an Internet Standard. The RFC index I fetched on 2004-10-19 says 0822 Standard for the format of ARPA Internet text messages. D. Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733) (Obsoleted by RFC2822) (Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (Also STD0011) (Status: STANDARD) I'm not sure what other construction to put on that "Obsolete by" bit. > It is entirely appropriate to refer to "RFC822 addresses", especially > in a context like this where the reference is informative. Perhaps, but to reference 822 rather than 2822 for them? >> (commonly known as the Rogaway attack >> [ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work, >> s/,)/)/ surely? > And s/][/],[/ Actually, I find I cut-and-pasted from the old version of that text rather than the new - both have the ,) problem, but the new text doesn't have the ][ problem. >> Built into [userauth-22] is the assumption that a password is a >> sequence of characters; on most systems, it is actually a sequence >> of octets, with any conversion between them and characters left >> undefined. > Sorry; that's just not true. It's true on every system I've ever used enough to know how passwords work on it - which admittedly is restricted to Unix variants. > In fact, if you look, you can probably find a number of situations in > which various UNIX systems treat passwords as character strings and > not octet strings. Consider xdm. xdm login windows treat passwords as character strings, yes - but it's the octet sequences behind them that matter: the password is actually the octet sequence, not the character sequence. If you set your password to "rÃë" using 8859-1 (ie, 0x72 0xc3 0xeb), I believe you'll find you can log in just fine to an xdm login window using 8859-7 by typing a password consisting of characters two of which I can't display here in 8859-1: r, capital gamma, lowercase lambda. (I phrase it that way because I can't try it; I can't tell how to set the locale for an arbitrary program, and my xdm (R6.4) doesn't seem to have any explicit options for it.) If the password truly were the sequence of characters rather than the sequence of octets, that wouldn't work. /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 00:41:04 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08116 for ; Fri, 29 Oct 2004 00:41:04 -0400 (EDT) Received: (qmail 7168 invoked by uid 605); 29 Oct 2004 04:41:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7156 invoked from network); 29 Oct 2004 04:41:02 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 29 Oct 2004 04:41:02 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA10814; Fri, 29 Oct 2004 00:41:01 -0400 (EDT) From: der Mouse Message-Id: <200410290441.AAA10814@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. Date: Thu, 28 Oct 2004 23:09:57 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New drafts In-Reply-To: References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> In assignednumbers-07, 4.2.3, what about reason codes from ffffffea >> through ffffffef? Similar remarks apply to 4.3.3 and 4.4.3. > I [...] hadn't realized that I had not completed my edits [...] > Just to summarize the discussion, I am planning on the following: Good. I thought it was odd to entirely omit six of the 2^32 possible values; I also thought it didn't look much like the consensus I remembered from the list. Your description of what you're planning looks much better on both counts. :) >> userauth-22 contains (in the description of password authentication) >> more character set issues, similar to those raised by the recent >> discussion of filenames. > Was that the discussion with the subject line of "SFTP and unicode > file names..."? I wasn't paying close attention to that. I think that was it. > Is that this paragraph: > Note that the 'plaintext password' value is encoded in ISO-10646 > UTF-8. It is up to the server how it interprets [...] Yes. > If so, would anyone care to propose text as to how it can address > this issue? I don't have a good fix. Basically, the problem is that passwords (or filenames, for the sftp issue) are, on some systems, octet sequences, with conversion between them and character sequences happening only when they need to be displayed or typed; whereas, on others, they are character sequences, with octet sequences involved only because of the need to store some representation of those character sequences. From the one point of view, character set conversion in the protocol is complete nonsense; from the other, it's reasonable even to the point of being necessary. Short of providing a character set tag field for which some distinguished value means "this is actually an octet sequence", I see no way to handle both with the same protocol. For example, on the system I'm using right now, passwords and filenames _are_ fundamentally octet sequences rather than character sequences. Given the edict > However, if the client reads the password in some other encoding > (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to > ISO-10646 UTF-8 before transmitting, then what should I do upon reading a password? I _don't know_, and in many cases finding out is not just difficult but impossible, what character set is being used for display; what characters the user is thinking of those octets, or the keystrokes behind them (if any), as corresponding to is even more difficult to determine. > and the server MUST convert the password to the encoding used on > that system for passwords. This appears to say that in order to implement password authentication in my server, I have to redesign and reimplement how passwords are handled and stored to make them character sequences rather than octet sequences. Is that really what we want the drafts to require? I for one would much rather simply not implement password authentication. /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 05:23:39 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10881 for ; Fri, 29 Oct 2004 05:23:39 -0400 (EDT) Received: (qmail 8647 invoked by uid 605); 29 Oct 2004 09:23:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8634 invoked from network); 29 Oct 2004 09:23:36 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 29 Oct 2004 09:23:36 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 2A60D21DEDF; Fri, 29 Oct 2004 11:23:34 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id F02F521DDFD; Fri, 29 Oct 2004 11:23:29 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9T9NTih000373; Fri, 29 Oct 2004 11:23:29 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9T9NLBT000364; Fri, 29 Oct 2004 11:23:21 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "denis bider" Cc: "'Joseph Galbraith'" , Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 29 Oct 2004 11:23:19 +0200 In-Reply-To: <004601c4bcca$1752e220$6402a8c0@nucleus> Message-ID: Lines: 125 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit "denis bider" writes: > if the version extension scheme we're talking about is what I proposed, it > does seem to solve the problem at hand in the simplest complete way. I think it is the need for completeness that I want to challenge. The sftp version negotiation mechanism was decided a long time ago, and it appears to be adequate for most other protocols. I believe it should work well to live with that decision and its limitations, and *not* try to retrofit a very different version negotiation scheme into the protocol. To make it a little more concrete, I'll make a counterproposal, and explain the assumptions that are behind it, to see if the rest of you will shoot it down. First, assumptions: * sftp version 3 is widely deployed now. * sftp version 6 will be (we hope) widely deployed soon. * current deployment of sftp version 4 and 5 is quite marginal. (If you want to correct me on this, please differentiate between server and client deployment, it makes a difference). The simple version negotiation scheme is V_S = max { version numbers supported by the server } V_C = max { version numbers supported by the client } V_U = min (V_S, V_C) # version to use If V_U is supported by both parties, negotiation is successful, and V_U is the version that is used on the wire. Otherwise, negotiation fails. This scheme is used in lots of protocols, including ssh and sftp (at least up to now). If both server and client supports a continuous set of version numbers, this negotiation scheme is perfect: if there is any version that both parties supports, V_U = max { version numbers supported by both parties }. The limitation of this scheme, is that if client or server supports a discontinuous set of version numbers, negotiation can fail even if there is some version that both sides support. Our problem case is: A supports versions { 3, 4 }, B supports { 3, 6 }. Then V_U = 4, which isn't supported by B, and hence negotiation fails. Hence, A are B not interoperatable, while a different negotiation scheme could come up with V_U = 3 and succeed. My first comment is that this can happen only if the client or server actually advertises 4 (or 5) as V_C/V_S. How much deployed code out there actually do that? My counterproposal is to keep the old version negotiation, and add the following note on version negotiation: The sftp protocol uses the traditional version negotiation mechanism where each side advertise the highest version number it supports, and the smallest of these two numbers are selected for use. Communication is possible if this selected version is supported by both sides. This mechanism is widely used in Internet protocols, but it also has some limitations. For example, if one side supports versions 3 and 4, and the other supports versions 3 and 6, the output of the version negotiation is that version 4 should be used. Communication fails, even though there is one protocol version, namely 3, that is supported by both sides. This is expected to be a rare problem in practice, since at any given time, deployment is usually dominated by at most two different versions. In order to make communication possible also in situations like the above example, where the version negotiation fails, implementations that support more than one version of the protocol SHOULD provide some mechanism to manually or automatically configure which of its supported versions it advertises. In the above example, if either side is configured to advertise version 3 as the highest supported version, i.e. to pretend that the support for the higher version protocol is non-existant, then the output from the version negotiation is version 3, which both sides support. This proposal sacrifices trivial out-of-the-box interoperability between implementations that support version 3 and 6, and implementations supporting version 3 and 4 (interoperability requires either manual configuration, or implementation kludges like sometimes reconnecting and trying a different version). I'm willing to do that sacrifice in order to keep the protocol nice and clean, and because the 3,4-vs-3,6-interoperability problem is rare and temporary. Am I alone in that? > If you don't care to implement it, it won't burden your client > implementation at all - you can continue to send the highest version you > support and that will work just as fine. Is that really correct? If I connect to a 3,6 server, that server will advertise version 3 (it *has* to, if it wants to interoperate with old 3,4 clients, and that is the entire point of the extended version negotion, right?). If I'm a version 6 only client, and I don't implement the proposal, my interpretation of this will be that the server is an old version 3 server, and that I can't communicate with it, so I will just display an error message and disconnect. > On the server side, this method will burden you only if you wish to offer > your highest version to clients which support non-contiguous version > ranges. As I understand it, a server or client that supports only version 6 still has to implement the proposal (i.e., advertise version 3, which it does *not* support at all, in the initial version exchange, and negotiate version 6 in the new second phase), or else it will not interoperate at all with clients that support version 3 and 6. That's why I find it so ugly. > I don't know why you label it as "fancy", because fancy is not what > it is. It's "fancy", i.e. different and more complicated, compared to the good old way of doing version negotiation. I didn't mean any more than that. Sorry for any confusion. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 08:16:19 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22983 for ; Fri, 29 Oct 2004 08:16:18 -0400 (EDT) Received: (qmail 11543 invoked by uid 605); 29 Oct 2004 12:16:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11529 invoked from network); 29 Oct 2004 12:16:13 -0000 Received: from agamemnon.cnchost.com (207.155.252.31) by mail.netbsd.org with SMTP; 29 Oct 2004 12:16:13 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by agamemnon.cnchost.com id HAA15054; Fri, 29 Oct 2004 07:28:40 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Cc: "'Joseph Galbraith'" , Subject: RE: SFTP v6? Date: Fri, 29 Oct 2004 13:28:37 +0200 Message-ID: <000001c4bdaa$707e4570$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Niels, I will reply with the technical aspects first. > > If you don't care to implement it, it won't burden your client=20 > > implementation at all - you can continue to send the=20 > > highest version you support and that will work just as fine. > > Is that really correct? If I connect to a 3,6 server, that=20 > server will advertise version 3 (it *has* to, if it wants to=20 > interoperate with old 3,4 clients, and that is the entire=20 > point of the extended version negotion, right?). If your client sends version 6 and the server supports version 6 it can respond with version 6. If the client supports a contiguous range of versions, we can make it OK = for the client to simply advertise the highest version it supports. It would work fine. > As I understand it, a server or client that supports only=20 > version 6 still has to implement the proposal (i.e.,=20 > advertise version 3, which it does *not* support at all, in=20 > the initial version exchange, and negotiate version 6 in the=20 > new second phase), or else it will not interoperate at all=20 > with clients that support version 3 and 6. That's why I find=20 > it so ugly. This can be fixed. If the client supports a contiguous range of = versions, it should send the highest version it supports in INIT. Otherwise it should = set the highest of the first contiguous set of versions it supports, e.g. if = it supports 3,4,6, it should send 4. The server should respond with min{advertisedClientVersion, highestServerVersion} in VERSION. However if advertisedClientVersion is lower than highestServerVersion, the server should include the "higher-versions" extension (or whatever it's called) enumerating the = higher versions it supports. In this case the server MUST then accept the subsequent "SELECTVERSION" packet from the client. I haven't yet had the chance to read Joseph's wording in the SFTP 6 = draft so I don't know if his wording supports this. If it doesn't we can fix. Now for the practical aspects of this. > This is expected to be a rare problem in practice, since at any given > time, deployment is usually dominated by at most two different = versions. I believe this to be too optimistic. A situation like 3-6 can reoccur = with a future set of versions. Could be several years from now if the need = arises for new features requiring an incremented version. It won't hurt to have this interoperability support in place then. Or if the past is any predictor, something like that could even happen again now. Suppose 6 is = a major thing, then a few people implement 7, and then 8 is the next major thing. Note that even in a few years' time we will still likely have SFTP = versions 3, 4, 5 around. Right now our SSH server still supports SFTP version 2 only. The = features of SFTP version 2 are all that's needed in a Windows server, so we didn't = yet upgrade. We will upgrade, but right now we have a fairly considerable = base of deployed installations featuring SFTP version 2. A good portion of = our users won't bother to upgrade to the next version and will continue to advertise SFTP version 2. That's for how long a deployed version can be expected to persist. I = expect SFTP version 3 will continue to be around for some time to come. > In order to make communication possible also in situations like the > above example, where the version negotiation fails, implementations > that support more than one version of the protocol SHOULD provide > some mechanism to manually or automatically configure which of its > supported versions it advertises. Niels - are any of your clients and servers graphical? Textual = configuration is easy. But providing good and well working graphical configuration for ANYTHING is much, much more difficult than extending the protocol for it = to work automatically. Adding a new option can even take more than a day = some times. It's an important consideration when implementing anything. In my experience, if the protocol doesn't provide an easy solution to a common problem, the result will be chaotic differences between implementations and haphazard interoperability. > This proposal sacrifices trivial out-of-the-box=20 > interoperability between implementations that support version=20 > 3 and 6, and implementations supporting version 3 and 4=20 > (interoperability requires either manual configuration, or=20 > implementation kludges like sometimes reconnecting and trying=20 > a different version). I'm willing to do that sacrifice in=20 > order to keep the protocol nice and clean, and because the=20 > 3,4-vs-3,6-interoperability problem is rare and temporary. I'm not willing to do that sacrifice because the burden of implementing = this non-contiguous version negotiation is in my view much smaller than application-specific remedies that will need to be implemented = otherwise, and the user frustration and loss of interoperability that will result. Besides - a client that supports a contiguous set of versions does not = need to be impacted in any way. Just the server needs to support this = extension to be interoperable at a higher version with clients implementing non-contiguous versions. > It's "fancy", i.e. different and more complicated, compared=20 > to the good old way of doing version negotiation. I didn't=20 > mean any more than that. Sorry for any confusion. Look at it this way. If we both spent the time we are spending to = discuss this implementing this extension, we both would have had a server and = client implementation already. :-) Best regards, denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 09:00:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26447 for ; Fri, 29 Oct 2004 09:00:35 -0400 (EDT) Received: (qmail 12567 invoked by uid 605); 29 Oct 2004 13:00:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12558 invoked from network); 29 Oct 2004 13:00:33 -0000 Received: from pix-fw.wan.aol.com (HELO wicked.office.aol.com) (152.163.190.1) by mail.netbsd.org with SMTP; 29 Oct 2004 13:00:33 -0000 Received: from [10.2.178.29] (wicked.office.aol.com [10.2.178.29]) by wicked.office.aol.com (8.12.11/8.12.11) with ESMTP id i9TCxZMb006524; Fri, 29 Oct 2004 08:59:38 -0400 Subject: Re: future SFTP version question From: jason bailey To: Niels =?ISO-8859-1?Q?M=F6ller?= Cc: Peter Gutmann , ietf-ssh@denisbider.com, jon@siliconcircus.com, ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Message-Id: <1099054775.5615.90.camel@wicked.office.aol.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 29 Oct 2004 08:59:35 -0400 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Allow me to clarify some of my terminology. When I first made the suggestion, I had in mind a possible change to the protocol where a receipt would be returned upon successful completion of a file transfer. Upon further thought and input I recognized that an extension would be more then suitable.To be accurate that is no longer a receipt, it would be a manifest. Proof of existence of a specific file on a particular server at a particular time, with no regard to how it got there. Whether it is a manifest file or a receipt, both provide similar functionality, which is an aspect of non-repudiation. The mechanism that you describe is technically correct. However it is a simplification of the issue and misses some of of the inherent problems. Yes, you can write a server (utilizing any protocol) that will accept a connection , receive a file, manifest the file and then return the manifest. In fact my current solution for this is done over https to a customized tomcat server. So if I have a solution in place why am I bringing this up? My answer relates in part to the last observation > but I seriously doubt it's worth the > effort; it seems too obscure and specialized. Non-repudiation is a growing demand in the corporate world. It is inextricably tied into secure file transfers. In a system which requires non-repudiation, sftp fulfills all the necessary requirements ( key handling, secure transmission, validation ) everything, except for the digitally signed receipt/manifest. There are standards that implement the necessary non-repudiation. EbXML and Rossetta are the two that come to my mind. However these are ugly, bloated, protocols. Completely unsuitable to do something as simple and as straight forward as moving a file from a to b. The reason I am bringing this up is because from my point of view having sftp adopt this as an extension would create a standard which would result in quicker deployments, better integration with other companies, happier customers, happier management, and costs savings that extend into the 10's of millions of american dollars for my company alone. I also see this as something that would be equally beneficial to the third party companies I work with as it is to ours. Is it obscure? Not from my perspective, nor the companies I work with. Is it specialized? possibly. Is it worth the effort. I really can't answer that from this groups perspective. I was surprised to realize that no one had brought this up before. I don't have a problem if, at this time, the working group doesn't believe that this is a suitable fit as an extension to the current protocol. However I do believe it deserves more critical consideration. -Jason On Thu, 2004-10-28 at 03:22, Niels Möller wrote: > I agree this seems to be beyond what standard sftp is supposed to do. > And I also don't see why sftp extensions are crucial for supporting > the given use case. One could use plain sftp (or *any* file transfer > mechanism, for that matter) and the following convention: > > * Client uploads the file "foo" into a particular directory or using some > particular naming scheme. > > * When upload is complete (sftp close), the server processes the > file using the signature mechanisms of its choice (pgp, s/mime, > whatever), and writes a receipt as a new file "foo.receipt". > > * The client downloads "foo.receipt". Everyone is happy. > > Adding extensions to sftp to do this have the potential advantage of > letting us standardize it, but I seriously doubt it's worth the > effort; it seems too obscure and specialized. > > Regards, > /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 16:06:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01683 for ; Fri, 29 Oct 2004 16:06:44 -0400 (EDT) Received: (qmail 21963 invoked by uid 605); 29 Oct 2004 20:06:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21289 invoked from network); 29 Oct 2004 20:06:08 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Oct 2004 20:06:08 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6810535; Fri, 29 Oct 2004 14:06:05 -0600 Message-ID: <4182A2B2.5060904@vandyke.com> Date: Fri, 29 Oct 2004 14:06:10 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > "denis bider" writes: > > >>if the version extension scheme we're talking about is what I proposed, it >>does seem to solve the problem at hand in the simplest complete way. > > > I think it is the need for completeness that I want to challenge. The > sftp version negotiation mechanism was decided a long time ago, and it > appears to be adequate for most other protocols. I believe it should > work well to live with that decision and its limitations, and *not* > try to retrofit a very different version negotiation scheme into the > protocol. > > To make it a little more concrete, I'll make a counterproposal, and > explain the assumptions that are behind it, to see if the rest of you > will shoot it down. First, assumptions: > > * sftp version 3 is widely deployed now. > > * sftp version 6 will be (we hope) widely deployed soon. > > * current deployment of sftp version 4 and 5 is quite marginal. (If > you want to correct me on this, please differentiate between > server and client deployment, it makes a difference). > > The simple version negotiation scheme is > > V_S = max { version numbers supported by the server } > V_C = max { version numbers supported by the client } > V_U = min (V_S, V_C) # version to use > > If V_U is supported by both parties, negotiation is successful, and > V_U is the version that is used on the wire. Otherwise, negotiation > fails. This is almost the way it works, but not quite. V_C = max { version numbers supported by the client } V_U = highest version supported by server <= V_C (V_S doesn't actually exist on the wire.) A minor difference... but... [...] >>If you don't care to implement it, it won't burden your client >>implementation at all - you can continue to send the highest version you >>support and that will work just as fine. > > Is that really correct? If I connect to a 3,6 server, that server will > advertise version 3 (it *has* to, if it wants to interoperate with old > 3,4 clients, and that is the entire point of the extended version > negotion, right?). If I'm a version 6 only client, and I don't > implement the proposal, my interpretation of this will be that the > server is an old version 3 server, and that I can't communicate with > it, so I will just display an error message and disconnect. No, this is not correct. There is actually no problem with the existing version scheme for _servers_ supporting discontigous protocol versions. This is because the _client_ MUST send it's version first. And the server doesn't actually send it's version, it sends the version to use. So, the server simply waits for the clients version, and picks the highest protocol version that it supports that is less than or equal to the clients version and sends that as V_U. >>On the server side, this method will burden you only if you wish to offer >>your highest version to clients which support non-contiguous version >>ranges. > > As I understand it, a server or client that supports only version 6 > still has to implement the proposal (i.e., advertise version 3, which > it does *not* support at all, in the initial version exchange, and > negotiate version 6 in the new second phase), or else it will not > interoperate at all with clients that support version 3 and 6. That's > why I find it so ugly. See above for client supporting only version 6. A client that wishes to support discontigous ranges will behave as follows: 1. It must send version 3 or higher during initial exchange, because if it doesn't the server can't send back an extension packet describing it's extended version options. This implies that in order to support server's that don't implement the new version scheme, which include v3,4, and 5 servers (of which I know of at least on of each), it MUST actually support the version 3 protocol variant. YUCK. 2. It will look for the 'version' extension in the servers SSH_FXP_VERSION packet. If the server doesn't send the packet, then the server doesn't support the protocol. This implies that a server that doesn't support the new protocol will interoperate with this client as if it only supported the clients lowest contiguous range of protocols. 3. If the 'version' packet is available, and contains a version higher than that which is currently negotiated, the client sends a 'version-select' (I like that name much better than what I used in the draft.) So, yes, if you implement a version 6 client, you'll need to be able to support enough version 3 to get through the extension. And I agree, that is gross. So I'll make an alternate proposal: SFTP (which stands for Secure File Transfer Protocol) is not a file transfer protocol. If it were a file transfer protocol, it would have operations like get and put. Instead it has operations like open, read, write, and close. Therefore, I suggest that we change the name of the subsystem to 'file-share' The 'file-share' protocol supports all versions of the 'sftp' protocol, with the minor exception that version exchange consists of: Server and client both send (without waiting to receive): FXP_INIT2 string version-list version-list is comma separated string of versions, in order of preference. For example. "6,2,1" The version to use is the first version on the clients list that is also on the server list. Now: - People with existing implementations only need a little bit of parameterization based on subsystem name to use the same piece of code to support 'sftp' and 'file-share'. Unix out-of-process implementations, might, for example, simply hard-link the sftp server binary to sftpd and fileshared. Or they might pass the subsystem name on the command line. In proc implementations have similar options available. In fact, implementors can (and SHOULD I think) make the switch to 'file-share' independent of implementing the latest protocol version. - Older clients continue to work without change (they talk to the older 'sftp' subsystem.) - Newer clients will have to attempt to start the 'file-share' subsystem, and if that fails, start the 'sftp' subsystem. This could cost one additional round trip when talking to a downlevel server, but, when talking to newer servers, it actually saves half a round trip because the server no longer waits for the clients version before sending it's own, and in addition, appropriate client extensions can be batched up and sent during init (something that couldn't be done before because of compatibility problems.) Which could save even more. - The new version negotiation scheme is: a. familiar to all ssh implementors. b. flexible enough to handle any future needs I can think of. c. more graceful than the old, especially in the way it fails. In particular, the client can now tell the user what versions the server _does_ support (which is really useful to me as an implementor or sys admin try to help a befuddled user.) I actually think the name change is a cleaner solution. Niels does raise a good point about a version 6 only server having to lie and support version 3 in order to work with discontigous clients. This does seem very ugly to me. However, I do think we need to do one or the other of these proposals. I don't think simple language change is sufficient with implementation advice is sufficient. The problem is indeed, temporary, for some definition of temporary. But, I suspect we will be seeing version 3 in use for another 5 years, at least. That definitely puts it on my mid to long range radar. My pessimistic evaluation is that it will be more like 5-7 years after we hit RFC status before we don't have customers that want to interoperate with a version client or server. I also suspect if we give people with existing implementations a way to get to the latest version with less pain the problem will be more temporary (i.e., newer versions will be out there sooner for people to start upgrading to, and the sooner they start the more temporary our problem.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 17:33:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15674 for ; Fri, 29 Oct 2004 17:33:30 -0400 (EDT) Received: (qmail 22995 invoked by uid 605); 29 Oct 2004 21:33:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22986 invoked from network); 29 Oct 2004 21:33:28 -0000 Received: from tonnant.concentric.net (HELO tonnant.cnchost.com) (207.155.248.72) by mail.netbsd.org with SMTP; 29 Oct 2004 21:33:27 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by tonnant.cnchost.com id RAA27663; Fri, 29 Oct 2004 17:33:25 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'jason bailey'" , "=?iso-8859-2?Q?'Niels_M=F6ller'?=" Cc: Subject: RE: future SFTP version question Date: Fri, 29 Oct 2004 23:33:21 +0200 Message-ID: <000001c4bdfe$ea976630$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1099054775.5615.90.camel@wicked.office.aol.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > > but I seriously doubt it's worth the > > effort; it seems too obscure and specialized. >=20 > Non-repudiation is a growing demand in the corporate world.=20 > It is inextricably tied into secure file transfers. In a=20 > system which requires non-repudiation, sftp fulfills all the=20 > necessary requirements ( key handling, secure transmission,=20 > validation ) everything, except for the digitally signed=20 > receipt/manifest.=20 I agree with Jason's assessment and disagree about this extension being = "too obscure and specialized". It is so simply because there is no simple way = of doing it. If we come up with an extension that provides a simple way of doing it, I believe there will be plenty demand. I would implement it in = our server. Someone needs to draft an extension though. That ought to be Jason = because he has background knowledge about the problem and can likely come up = with something that will be simple enough yet will work. I propose this be done here because we've had at least 2 positive = responses (I don't recall if there were more) and just one negative. If this is an optional extension, people who don't want to implement will not be = impacted by it, whether it's part of SFTP or a separate draft. What does Joseph as the SFTP draft editor think about making this an extension in the SFTP draft, one like MD5 hashes for instance? (which I think were an excellent idea btw) If this is too complex to be an extension in the same draft, I think = Jason can just go get xml2rfc or a similar utility and write up an = Internet-Draft for this - am I right? How would he submit it when he writes one? denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 18:05:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19302 for ; Fri, 29 Oct 2004 18:05:54 -0400 (EDT) Received: (qmail 10519 invoked by uid 605); 29 Oct 2004 22:05:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10508 invoked from network); 29 Oct 2004 22:05:52 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Oct 2004 22:05:52 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6810874; Fri, 29 Oct 2004 16:05:50 -0600 Message-ID: <4182BEC4.8080008@vandyke.com> Date: Fri, 29 Oct 2004 16:05:56 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <000701c4bdfc$69826ce0$6402a8c0@nucleus> In-Reply-To: <000701c4bdfc$69826ce0$6402a8c0@nucleus> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >>A client that wishes to support discontigous ranges >>will behave as follows: >> >> 1. It must send version 3 or higher during initial >> exchange, because if it doesn't the server can't >> send back an extension packet describing it's >> extended version options. >> >> This implies that in order to support server's >> that don't implement the new version scheme, which >> include v3,4, and 5 servers (of which I know of at >> least on of each), it MUST actually support the version >> 3 protocol variant. YUCK. > > > I proposed in my previous email to the list the following simple change > which solves this problem: > > If the client supports a contiguous range of versions, it should send the > highest version it supports in INIT. Otherwise it should send the highest of > the first contiguous set of versions it supports, e.g. if it supports 3,4,6, > it should send 4. > > This means that if the client supports 4,6 it can send 4 and does not need > to implement 3. No yuck here. :) But, if the server only support 6, it must still respond respond with 4, even though it does not support 4. Then, if the client doesn't send a 'version-select' the server must close the channel, because it can't speak the protocol. Rather than getting a nice error message about the server not supporting the version, the user will likely see strange behavior, because the version 4 client won't be expecting a channel after version exchange is complete to mean 'version unsupported.' It thought the version stuff was already sorted out. Ugh. On the other side of the coin, let's say we have a 4,6 client, which advertises 4 in it's INIT packet. Now, the server is a 3,6 server, so it responds 3. The client now needs to negotiate down to 3. That's not so bad, I guess. (I don't think I allowed it in the original language, but that could be fixed :-) The third problematic case is a a client that supports 1,2,6. Such a client can not send 2, because 2 doesn't support extensions. So it must send 3. Now, what if that client actually meets a version 3 server? (A highly likely event.) It is now stuck. It can't jump to six, nor can it fall back to 2 where it could actually interoperate. So a client really must support, at a minimum, version 3. Ugh. >>So I'll make an alternate proposal: > > > The SFTP module can be implemented separately from the SSH server, as we do. > This proposal requires the SSH server to know about complexities of the SFTP > protocol and to invoke the SFTP module differently depending on what verb > was used to start it. Not really; it just requires the SSH server to pass the name of the subsystem being started to the subsystem. This could be as simple as invoking the sftp-server module by a different name, or having the config file setup in a way such that the 'file-share' subsystem invokes 'sftp-server -file-share' and the 'sftp' subsystem invokes 'sftp-server' ... or it might be more complicated in some implementations. But it shouldn't require your SSH server to know anything about the SFTP protocol... it just has to support a new subsystem, and the subsystem has to know it's name (or you have to have separate modules.) In all honesty, I think that the new version exchange is how it should have been done originally. And I think that it solves a number of outstanding problems in the protocol that we've been reluctant to address because of backwards compatibility issues, including: - the version problem we've been discussing - extensions from the client on startup (these have been very useful on the server side... originally they were there for the client to, but had to be removed for backwards compatibility.) - Better failure mode when there isn't a compatible version. (In fact the draft is currently silent on how to deal with this and there isn't a great way to do so with the current scheme. With the new scheme, both sides know that the version exchange has failed, and which versions the other supports.) We've actually tried to make some changes for better failure mode before too. > This also violates independence of SFTP from the SSH protocol. Each > underlying protocol must now think up its own rules for starting old versus > new versions of SFTP. I'm not sure I follow this argument. Since any hypothetical non-SSH implementation doesn't actually have subsystems, it already had to think up its own rules for starting the protocol. I don't know of any actual non-SSH implementations. Any new non-SSH implementation should just always use the new version exchange, or in other words, the 'file-share' version semantics. It should also probably just use the latest protocol version and not have any of this mess, since it is new and doesn't have to worry about interoperating with old. > I think that's much uglier. > > Doesn't my proposal above solve all of the gripes about people having to > advertise versions they don't actually support? It's a straightforward > change and if that's the only real problem thus far identified we have a > good solution I think (if Niels agrees). Unfortunately, no, it really doesn't. At least I don't see how yet. I was initially in favor of the version re-negotiate scheme (it was basically the solution I had in the back of mind if I ever got a chance to solve this problem.) But as I've thought about the possible interoperability interactions, I've become convinced that it would actually be pretty fragile, and could lead to non-obvious failures (like the one I described at the top.) Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 18:16:09 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20543 for ; Fri, 29 Oct 2004 18:16:08 -0400 (EDT) Received: (qmail 15393 invoked by uid 605); 29 Oct 2004 22:16:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15382 invoked from network); 29 Oct 2004 22:16:07 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Oct 2004 22:16:07 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6810901; Fri, 29 Oct 2004 16:16:00 -0600 Message-ID: <4182C125.6030300@vandyke.com> Date: Fri, 29 Oct 2004 16:16:05 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: denis bider CC: "'jason bailey'" , =?ISO-8859-2?Q?=27Niels_M=F6ller=27?= , ietf-ssh@NetBSD.org Subject: Re: future SFTP version question References: <000001c4bdfe$ea976630$6402a8c0@nucleus> In-Reply-To: <000001c4bdfe$ea976630$6402a8c0@nucleus> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >>>but I seriously doubt it's worth the >>>effort; it seems too obscure and specialized. >> >>Non-repudiation is a growing demand in the corporate world. >>It is inextricably tied into secure file transfers. In a >>system which requires non-repudiation, sftp fulfills all the >>necessary requirements ( key handling, secure transmission, >>validation ) everything, except for the digitally signed >>receipt/manifest. > > > I agree with Jason's assessment and disagree about this extension being "too > obscure and specialized". It is so simply because there is no simple way of > doing it. If we come up with an extension that provides a simple way of > doing it, I believe there will be plenty demand. I would implement it in our > server. > > Someone needs to draft an extension though. That ought to be Jason because > he has background knowledge about the problem and can likely come up with > something that will be simple enough yet will work. > > I propose this be done here because we've had at least 2 positive responses > (I don't recall if there were more) and just one negative. If this is an > optional extension, people who don't want to implement will not be impacted > by it, whether it's part of SFTP or a separate draft. > > What does Joseph as the SFTP draft editor think about making this an > extension in the SFTP draft, one like MD5 hashes for instance? (which I > think were an excellent idea btw) > > If this is too complex to be an extension in the same draft, I think Jason > can just go get xml2rfc or a similar utility and write up an Internet-Draft > for this - am I right? How would he submit it when he writes one? Well, below is a _very_ rough version of an extension. I'd be more than happy to have Jason's expertise to help get this fleshed out where it will work for him (and us.) And since non-repudiation has recently whacked me over the head, I'd agree that I suspect for most of us implementing sftp, it will probably become non-obscure and not-so-specialized soon, if it hasn't already. (One alternate proposal I had was to put together a AS profile for running of sftp, AS4... but I think that might be _really_ heavy weight, and what Jason seems to be saying is we already have most of what we need anyway.) - Joseph --- 9.2 File Signing This extension allows a client to request that the server provide a signature proving that it has recieve a correct copy of the data. byte SSH_FXP_EXTENDED uint32 request-id string "sign-filename" / "sign-handle" string filename [UTF-8] / file-handle string pubkey-algorithm-list [from transport draft] byte SSH_FXP_EXTENDED_REPLY uint32 request-id string filename-used-in-signature [UTF8] int64 time-of-request attrib file-attrib string public-key [from transport draft] string signature [from transport draft] filename Used if 'sign-filename' is specified; indicates the name of the file to use. The hash will be of the file contents as it would appear on the wire if the file were opened with no special flags. file-handle Used if 'sign-handle' is specified; specifies a file handle to read the data from. The handle MUST be a file handle, and ACE4_READ_DATA MUST have been included in the desired-access when Galbraith Expires April 29, 2005 [Page 46] Internet-Draft SSH File Transfer Protocol October 2004 the file was opened. If this file handle was opened in TEXT mode, the signature must be made of the data as it would be sent on the wire. pubkey-algorithm-list The algorithm list of publickeys the client is capable of supporting. If the server cannot provide a signature using any of the algorithm requested, it should respond with a STATUS response, with UNSUPPORTED error code. In the case of x509v3 (see below), no attempt is made to negotiate which algorithms are supported within the certificate chain. filename-used-in-signature time-of-request file-attrib The filename actually used, time-of-request, and file attribute structure which were used to make the signature. The filename, in particular, may be difference from that specified if the server applied some sort of canonicalization, or may be empty if the request was a sign-handle and the server couldn't map from a handle to a filename. public-key The public-key the server used to sign the filename. This is a data structure as specified in the secsh transport specification [2]. This draft specifies an additional public format, x509v3@filexfer.secsh.ietf.org. The key data in this case is the x509v3 certificate DER encoded. The signature algorithm used for this key type is one of three types: ssh-dss Encoded as per the secsh transport specification [2]. ssh-rsa Encoded as per the secsh transport specification [2]. pkcs7@filexfer.secsh.ietf.org A DER encoded pkcs #7 signature with detached data, as specified by . The prefered signature algorithm is pkcs7. Galbraith Expires April 29, 2005 [Page 47] Internet-Draft SSH File Transfer Protocol October 2004 signature The signature over the following data, formatted as specified in the secsh transport specification [2] or as above. string filename [UTF-8] string username-of-signature-requestor [UTF-8] int64 time-of-request attrib file-attrib string file-data filename The filename of the file being signed. If this is a 'sign-filename' request, the filename MUST be included, although it MAY be canonicalized. If this is a sign-handle, the filename SHOULD be included; however, if the server can not map backwards from a handle to a filename, the filename may be zero length. username-of-signature-requestor This is the username by which the client authenticated to the system. time-of-request This is the time that the signature request was made, format as described by file attributes. (Section 6.7) file-attrib File attribute structure describing the attributes of the file. The server SHOULD include any fields that it can, even if it would not normally retrieve the data. In particular, the server SHOULD include owner, group, acl, permissions, and mime-type data if it can support these field. The size and attrib-bits fields SHOULD also be included. file-data The file data as an SSH string. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 29 19:35:30 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26195 for ; Fri, 29 Oct 2004 19:35:30 -0400 (EDT) Received: (qmail 28736 invoked by uid 605); 29 Oct 2004 23:35:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28717 invoked from network); 29 Oct 2004 23:35:29 -0000 Received: from tonnant.concentric.net (HELO tonnant.cnchost.com) (207.155.248.72) by mail.netbsd.org with SMTP; 29 Oct 2004 23:35:29 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by tonnant.cnchost.com id RAA16868; Fri, 29 Oct 2004 17:15:30 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Joseph Galbraith'" Cc: Subject: RE: SFTP v6? Date: Fri, 29 Oct 2004 23:15:25 +0200 Message-ID: <000701c4bdfc$69826ce0$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <4182A2B2.5060904@vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > A client that wishes to support discontigous ranges > will behave as follows: >=20 > 1. It must send version 3 or higher during initial > exchange, because if it doesn't the server can't > send back an extension packet describing it's > extended version options. >=20 > This implies that in order to support server's > that don't implement the new version scheme, which > include v3,4, and 5 servers (of which I know of at > least on of each), it MUST actually support the version > 3 protocol variant. YUCK. I proposed in my previous email to the list the following simple change which solves this problem: If the client supports a contiguous range of versions, it should send = the highest version it supports in INIT. Otherwise it should send the = highest of the first contiguous set of versions it supports, e.g. if it supports = 3,4,6, it should send 4. This means that if the client supports 4,6 it can send 4 and does not = need to implement 3. No yuck here. :) > So I'll make an alternate proposal: The SFTP module can be implemented separately from the SSH server, as we = do. This proposal requires the SSH server to know about complexities of the = SFTP protocol and to invoke the SFTP module differently depending on what = verb was used to start it. This also violates independence of SFTP from the SSH protocol. Each underlying protocol must now think up its own rules for starting old = versus new versions of SFTP. I think that's much uglier. Doesn't my proposal above solve all of the gripes about people having to advertise versions they don't actually support? It's a straightforward change and if that's the only real problem thus far identified we have a good solution I think (if Niels agrees). denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 30 12:40:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04089 for ; Sat, 30 Oct 2004 12:40:29 -0400 (EDT) Received: (qmail 2332 invoked by uid 605); 30 Oct 2004 16:40:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2323 invoked from network); 30 Oct 2004 16:40:20 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Oct 2004 16:40:20 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id C42A721F738; Sat, 30 Oct 2004 18:40:18 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 3E79721F2A2; Sat, 30 Oct 2004 18:40:14 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9UGeDih014250; Sat, 30 Oct 2004 18:40:13 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9UGe4qJ014244; Sat, 30 Oct 2004 18:40:04 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: jason bailey Cc: Peter Gutmann , ietf-ssh@denisbider.com, jon@siliconcircus.com, ietf-ssh@NetBSD.org Subject: Re: future SFTP version question References: <1099054775.5615.90.camel@wicked.office.aol.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 30 Oct 2004 18:40:01 +0200 In-Reply-To: <1099054775.5615.90.camel@wicked.office.aol.com> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit jason bailey writes: > Allow me to clarify some of my terminology. [...] > Non-repudiation is a growing demand in the corporate world. It is > inextricably tied into secure file transfers. In a system which requires > non-repudiation, sftp fulfills all the necessary requirements ( key > handling, secure transmission, validation ) everything, except for the > digitally signed receipt/manifest. I'm afraid, I'm not really familiar with the non-repudiation area. > Is it obscure? Not from my perspective, nor the companies I work with. > Is it specialized? possibly. > Is it worth the effort. I really can't answer that from this groups > perspective. > > I was surprised to realize that no one had brought this up before. I > don't have a problem if, at this time, the working group doesn't believe > that this is a suitable fit as an extension to the current protocol. > However I do believe it deserves more critical consideration. Then I think the first thing you have to do is to write up the requirements. "Non-repudiation" is a very fuzzy concept to me, and I'll have a hard time participating in discussion of details in a non-repudiation mechanism. I don't know if the others in the secsh wg are familiar with non-repudiation, but perhaps you have to seek feedback elsewhere in order to get the requirements right. When the requirements are clear, we'll have a better foundation for designing or evaluating extensions to sftp. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 30 13:01:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05165 for ; Sat, 30 Oct 2004 13:01:13 -0400 (EDT) Received: (qmail 14416 invoked by uid 605); 30 Oct 2004 17:01:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14405 invoked from network); 30 Oct 2004 17:01:13 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Oct 2004 17:01:12 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id ABDD021C28E; Sat, 30 Oct 2004 19:01:11 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id A300F21E6DA; Sat, 30 Oct 2004 19:01:07 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i9UH17ih014370; Sat, 30 Oct 2004 19:01:07 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i9UH0xvu014367; Sat, 30 Oct 2004 19:00:59 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "denis bider" Cc: "'Joseph Galbraith'" , Subject: Re: SFTP v6? References: <000001c4bdaa$707e4570$6402a8c0@nucleus> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 30 Oct 2004 19:00:58 +0200 In-Reply-To: <000001c4bdaa$707e4570$6402a8c0@nucleus> Message-ID: Lines: 71 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit "denis bider" writes: > I will reply with the technical aspects first. Thanks. > > > If you don't care to implement it, it won't burden your client > > > implementation at all - you can continue to send the > > > highest version you support and that will work just as fine. > > > > Is that really correct? If I connect to a 3,6 server, that > > server will advertise version 3 (it *has* to, if it wants to > > interoperate with old 3,4 clients, and that is the entire > > point of the extended version negotion, right?). > > If your client sends version 6 and the server supports version 6 it can > respond with version 6. I'm afraid that makes absolutely no sense to me. It is possible that I have misunderstood the vesrion extension in some fundamental way, so I should probably shut up until I've reread the proposal (which may take a long time, since I'm pretty busy with work for the rest of this year). Anyway, I'll summarize my current understanding of the proposal. Given: Server S, that supports version 3 and version 6 of the protocol. Client O (old), supporting version 3 and version 4. Client N (new), supporting only version 6. S wants to interoperate with O. Using the traditional version negotiation will fail (server advertises version 6, O advertises version 4, which leads to version 4 being selected, which S doesn't support). Hence S *must* implement the proposed extension. It always advertises version 3, and intends to use the proposed extension to negotiate version 6 in the second phase. Now N connects to S. If N uses the traditional version exchange only, communication will fail (N advertises 6, S advertises 3, which leads to version 3 being selected, which N doesn't support. So if N wants to interoperate with S, it too *must* implement the extension. > Right now our SSH server still supports SFTP version 2 only. The features of > SFTP version 2 are all that's needed in a Windows server, so we didn't yet > upgrade. When you upgrade, you will have a server that supports version 2 and 6, or version 2,3 and 6, right? I don't see why that should pose a problem. The problem is only implementations that *advertice version 4 and 5*. Any body who knows about deployment of such versions, please speak up. I'd like to see some evidence for the existence of the problem the extension is trying to solve. > Niels - are any of your clients and servers graphical? Textual configuration > is easy. But providing good and well working graphical configuration for > ANYTHING is much, much more difficult than extending the protocol for it to > work automatically. Adding a new option can even take more than a day some > times. It's an important consideration when implementing anything. I don't usually to GUI programming. From my limited experience, if you have some kind of options dialog or menu, adding one more checkbox to that dialog is about the same amount of work as adding one more command line option to a command line tool. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 30 17:30:04 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19370 for ; Sat, 30 Oct 2004 17:30:03 -0400 (EDT) Received: (qmail 20410 invoked by uid 605); 30 Oct 2004 21:30:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20401 invoked from network); 30 Oct 2004 21:29:59 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 30 Oct 2004 21:29:58 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA27516; Sat, 30 Oct 2004 17:29:56 -0400 (EDT) From: der Mouse Message-Id: <200410302129.RAA27516@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. Date: Sat, 30 Oct 2004 17:22:13 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: future SFTP version question In-Reply-To: References: <1099054775.5615.90.camel@wicked.office.aol.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Non-repudiation is a growing demand in the corporate world. [...] > I'm afraid, I'm not really familiar with the non-repudiation area. Non-repudiation is a way of arranging that it is impossible (well, infeasible - about as impossible as anything gets in cryptography) to later claim "no I didn't do that". (As a non-crypto example, for example, my signature on a document gives some non-repudiable assurance I've read the document.) It's not clear how it's being used here: is the client trying to protect itself against a server saying "no I never received that file" or is the server trying to protect itself against a client saying "no I didn't send that file"? (The mechanisms sketched appear to be designed for the former, but that strikes me as an unlikely desire.) When I first saw the mechanisms outlined, it appeared to me that they were designed to give the client a certificate which could demonstrate to a third party that the server did indeed receive the file; while this does have non-repudiation uses, it seemed to me more designed to allow the client to prove the fact of transmission to a third paty without requiring the proof to involve contacting the receiving host or its admins. /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 30 21:15:45 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03454 for ; Sat, 30 Oct 2004 21:15:45 -0400 (EDT) Received: (qmail 24465 invoked by uid 605); 31 Oct 2004 01:15:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24402 invoked from network); 31 Oct 2004 01:15:41 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 31 Oct 2004 01:15:41 -0000 Received: from baragon.mindrot.org (unknown [IPv6:3ffe:8001:22:1:202:6fff:fe34:51fd]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 7CC8127C187; Sun, 31 Oct 2004 11:48:05 +1100 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 7E3731BB8C3; Sun, 31 Oct 2004 11:53:21 +1100 (EST) Message-ID: <41843780.2090603@mindrot.org> Date: Sun, 31 Oct 2004 11:53:20 +1100 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20041003) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jason bailey Cc: ietf-ssh@NetBSD.org Subject: Re: future SFTP version question References: <000b01c4b8a4$24558bf0$6402a8c0@nucleus> <417D4DBC.4030606@vandyke.com> <1098804707.16258.9.camel@wicked.office.aol.com> In-Reply-To: <1098804707.16258.9.camel@wicked.office.aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit jason bailey wrote: > Would it be within scope to suggest that a future version of the SFTP > server provide a signed receipt of the file transfer(on request)? > > This feature, would do much to alleviate a lot of our issues with secure > file transfers. I don't think that this is within the scope of sftp at all. It would more appropriately be done by a higher-level protocol, e.g. one that uses sftp for the file transfer and something else (OpenPGP, S/MIME) for the signed receipts. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 31 00:42:19 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12697 for ; Sun, 31 Oct 2004 00:42:19 -0400 (EDT) Received: (qmail 20895 invoked by uid 605); 31 Oct 2004 04:42:19 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20041031044219.20891.qmail@mail.netbsd.org> Received: (qmail 20872 invoked from network); 31 Oct 2004 04:42:18 -0000 Received: from 201009086119.user.veloxzone.com.br (HELO mail.com) (201.9.86.119) by mail.netbsd.org with SMTP; 31 Oct 2004 04:42:17 -0000 From: "Juliana Castro" To: Subject: Listas de emails Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 31 Oct 2004 01:41:45 -0300 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit As melhores listas de e-mails do Brasil. Dividida por estado, pessoas físicas, empresas, por atividades... Visite agora: http://www.gueb.de/divulgamail Mala direta por e-mail, E-mails de pessoas e empresas de São Paulo e de quase todos estados do Brasil. Listas emails, e-mail regiões, propaganda email, enviar email anônimo, envio mala direta, estados, campanha, cidade, envio, publicidade e-mails, São Paulo... Visite agora: http://www.gueb.de/divulgamail From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 31 12:02:48 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13128 for ; Sun, 31 Oct 2004 12:02:48 -0500 (EST) Received: (qmail 16836 invoked by uid 605); 31 Oct 2004 17:02:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16827 invoked from network); 31 Oct 2004 17:02:43 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 31 Oct 2004 17:02:43 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6813378; Sun, 31 Oct 2004 10:02:41 -0700 Message-ID: <41851ABA.4000101@vandyke.com> Date: Sun, 31 Oct 2004 10:02:50 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <000001c4bdaa$707e4570$6402a8c0@nucleus> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > The problem is only implementations that *advertice version 4 and 5*. > Any body who knows about deployment of such versions, please speak up. > I'd like to see some evidence for the existence of the problem the > extension is trying to solve. I have a version 4 deployment. I'm pretty sure Richard Walen (process software) has a version 4 deployment. And Henrick Hellström says that he and others he knows of have a v5 deployments. So yes, the problem does exist in the wild and we aren't just talking about the hypothetical problem. There are known, currently shipping implementations of every version of sftp from 2-5. I'm mildly surprised about the 2, by the way. I would have thought that no one was currently shipping version 2, though I suspected there was still a number of v2 implementations in use. That is one of the reasons I claim this problem isn't quite as 'temporary' as you and I would wish. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 31 22:58:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01318 for ; Sun, 31 Oct 2004 22:58:14 -0500 (EST) Received: (qmail 26006 invoked by uid 605); 1 Nov 2004 03:58:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25997 invoked from network); 1 Nov 2004 03:58:13 -0000 Received: from zeppo.itss.auckland.ac.nz (HELO smtpd.itss.auckland.ac.nz) (130.216.190.14) by mail.netbsd.org with SMTP; 1 Nov 2004 03:58:13 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 5EB153401E; Mon, 1 Nov 2004 16:39:24 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01627-11; Mon, 1 Nov 2004 16:39:24 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 6591F3449D; Mon, 1 Nov 2004 16:39:22 +1300 (NZDT) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8844837744; Mon, 1 Nov 2004 16:39:22 +1300 (NZDT) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1COT2V-0006oC-00; Mon, 01 Nov 2004 16:39:27 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jbailey@aol.net, nisse@lysator.liu.se Subject: Re: future SFTP version question Cc: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org, jon@siliconcircus.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Mon, 01 Nov 2004 16:39:27 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: >Then I think the first thing you have to do is to write up the requirements. >"Non-repudiation" is a very fuzzy concept to me, and I'll have a hard time >participating in discussion of details in a non-repudiation mechanism. It's a fuzzy concept to everyone, so much so that after 20-odd years of trying the X.509 guys gave up and renamed the nonRepudiation flag in certs to something that actually had a meaning. Calling it a "delivery receipt" would be better, that's what S/MIME (which is the only major standard to specifically address this) calls it. In fact you could probably lift a lot of the S/MIME stuff, since they've looked at it in some detail. Peter.